OpenID Connect まとめ

仕事でOpenID Connectを使うことがあって、いい機会なので、備忘録としてまとめておく。

まず、OpenID connectとは、Oatuh2.0を拡張し、認証を可能にしたもの。Oatuh2.0は、認可のプロトコルであり、ユーザーがアプリに対して認可を与えるもの。認証と認可は違う。
認証:相手が本人であるか確認する行為
認可:相手がアクセスするコンテンツに対して、アクセスの可否を制御する。

Oatuh2.0は、認証のプロコトルとして使用する場合、下記の欠点があり、そこで、OpenID Connect(以下、OICDと略す)の登場となる。

認証時の情報(認証の日時や手段など)や、ユーザの情報(ユーザのIDや名前やメールアドレスなど)を取得するための仕様が定められてないこと。
https://zenn.dev/bonvoyage/articles/5dda6a1effd022

OAuthとOIDC - Qiita

つまり、OIDCでは、Oatuh2.0で取得できるトークンに加えて、IDトークンを取得できこのIDトークンを検証することで、ユーザー正当性が確保でき、ユーザーが誰なのかを知ることができるものだ。

OIDCの登場人物は、3種類あり、

• End User:アプリケーションを使うユーザー

• OpenID Provider:トークン発行サーバー

• Relaying Party:アクセストークンを発行してもらうアプリケーション

OIDCのClientは、下記が想定できる。

• SPA

• MPA

• ネイティブアプリ

そして、OIDCの決められたエンドポイントは、3種類あり、

• 認可エンドポイント

• トークンエンドポイント

• リライレクションエンドポイント

それぞれの使い方と認証フローが定められている。

• 認可コードフロー(一般的)

  • Clientに関係なく利用可能(SPA MPA ネイティブアプリ)

• インプリシットフロー

  • SPAを想定している。

  • リダイレクト時にIDトークンを含んだURLが帰るため、履歴に残り、漏洩リスクがある。

  • 同一生成元ポリシーによる制限は、CORSで回避できるため、非推奨

  • どうしても使いたい場合は、fragment指定で、経路にトークンが残らないようにして対応する。

• ハイブリッドフロー

  • 認可レスポンスの中に、認可コードだけでなく、IDトークンやアクセストークンも含む。

  • Clientが複数のAuthorization Serverと連携する場合に、IDトークンから発行元を識別できるメリットがある。

  • 一般的に使われていない。

• クライアントクレデンシャルフロー

  • Client IDとClient Sercretを使って、Authorization Serverからアクセストークンを取得する。(認証は、Client自身なので、IDトークンはない)

• リソースオーナーパスワードクレデンシャルフロー

  • ユーザーのID/パスワードをClientが使って、Authorization Serverに認証をかける。(グループ内システムとかを想定)

  • 使ってはいけない