OAuth2.0について

OAuth2.0についてざっくりとまとめました。

OAuth2.0はサービスのユーザーが、サービス上の自分のデータへのアクセスを認証情報を渡すことなく別のアプリケーションに許可するためのプロトコルで認証の仕様ではなく、認可の仕様。

OAuth2.0は保護されたリソースへのアクセスを得るためにアクセストークンを使用します。アクセストークンとは許可された権限を表す文字列になっており、アクセストークンのフォーマットの中でJWTがよく使われています。JWTはヘッダー、ペイロード、署名の3つの部分から構成されます。
ヘッダーにはトークンの種類と内容を保護するために使用される暗号アルゴリズムに関するメタデータが含まれています。
ペイロードにはクレーム（認証対象に関する情報）が含まれており、具体的にはオーディエンスや有効期限などが入っています。
署名はトークンが信頼できるものであり、改ざんされていないことを検証するために使用されます。

OAuth2.0には4種類の登場人物がいます。
リソースオーナー：サービスを利用するエンドユーザー
リソースサーバー：リソースへアクセスするためのAPI
クライアント：リソースオーナーの代わりにリソースへアクセスする（アプリケーション）
認可サーバー：リソースオーナーを認可し、アクセストークンを発行するサーバー

この4つがやり取りを行いリソースへのアクセスが行われます。
認可のタイプにはさらに4種類ありますが、一般的なフローは以下となります。
- クライアント（アプリケーション）がリソースオーナーへリソースへアクセスを行っていいかの確認を行う。
- リソースオーナーから許可が出るとクライアントは認可グラント（リソースオーナーの認可を表す情報）が行われます。
- クライアントは認証サーバーで認証を行い、認可グラントを渡します。
- 認証サーバーではクライアントが正常に認証され、認証グラントが有効であればアクセストークンを発行してクライアントへ送信します。
- クライアントはリソースサーバーへ保護されたリソースへのアクセスを要求し、アクセストークンを提示することで認証を行います。
- アクセストークンが有効であれば、リソースサーバーはクライアントのリクエストを処理します。

OAuth2.0では以上のフローを実現するために2種類のエンドポイントが存在します。

認可エンドポイント
リソースの所有者に対して、保護されたリソースにアクセスするための権限を取得するために使用される。（Googleアカウントを使用して他サービスにログインする場合にGoogleにリダイレクトし認証を行い同意画面が表示される）。このエンドポイントは認可コード方式とImplicit方式で使用されます。これは認可サーバーがクライアントがどのグラントタイプを使用したいかを知る必要があるためです。認証コード方式の場合は、response_type=codeを設定することにより、レスポンスに認可コードが含まれます。IDトークンはログインしているユーザー情報についてのJWTでOIDCの仕組みの中で提供されるものです。

トークンエンドポイント
クライアントがアクセストークンやリフレッシュトークンを取得するために使用します。認可コード方式ではクライアントは認可エンドポイントから取得した認証コードをアクセストークンと交換します。