OpenID 接続 (OIDC) は、OAuth 2.0 認可プロトコルの上に構築されたアイデンティティレイヤーです。これにより、サードパーティのアプリケーション（クライアント）がユーザーの認証および基本的な権限情報へのアクセスを行うことができます。

次に、OIDC の仕組みを理解する前に、いくつかの用語について確認しましょう。

Relying PartyはOpenIDプロバイダーのAuthorizationエンドポイントにリクエストを送り、ユーザー認証および特定のユーザー情報へのアクセス権限を取得します。ユーザーの認証および認可が完了すると、AuthorizationエンドポイントはIDトークンとアクセストークンをRelying Partyに送信します。

これらのアプリケーションはサーバー上で動作し、各操作ごとに新しいページリクエストをサーバーへ送信します。クライアントシークレットを安全に保存できるため、「Confidential Clients」とも呼ばれます。MPAに推奨される最適な認証フローはAuthorizationコードフローです。

SPAは、ユーザーの操作に応じて必要なセクションのみを読み込むモダンなWebアプリケーションです。これらのアプリケーションは通常クライアントサイドで動作し、初回に必要なすべてのリソースをサーバーから取得します。また、「公開クライアント」とも呼ばれ、クライアントシークレットを安全に保存できません。なぜなら、すべてのデータソースがブラウザー内に含まれるためです。SPAに推奨される認証フローはインプリシットコードフローです。

このフローでは、クライアント（RP）がOPのAuthorizationエンドポイントに対してユーザー認証および特定のユーザー情報へのアクセス許可をリクエストします。ユーザーの認証と認可取得後、Authorizationエンドポイントから直接クライアントにIDトークンが送信されます。リクエストされている場合は、アクセストークンや更新トークンも送信されます。クライアントはIDトークンから必要なユーザー情報を取得します。このフローでは、トークンエンドポイントは使用されません。

ネイティブアプリケーションは特定のデバイスに直接インストールされます。これらも「公開クライアント」と呼ばれます。直接デバイスにインストールされるため、シークレットを安全に保持できず、アプリケーションが誰でもデコンパイル可能でクライアントシークレットにアクセスできてしまいます。ネイティブアプリに推奨されるフローは、AuthorizationコードフローとProofキーによるコード交換（PKCE）です。

このフローでは、クライアント（RP）がコードベリファイア（ランダムな文字列）とコードチャレンジ（任意のハッシュ方式でコードベリファイアをハッシュ化したバージョン）を生成します。クライアントは、認可リクエストをOPの認可エンドポイントに送信する際、コードベリファイアも一緒に送ります。ユーザーが認証され、認可が取得された後、認可エンドポイントはクライアントに認可コードを送信します。OPのトークンエンドポイントでは、クライアントがこの認可コードとコードチャレンジ、さらにコードベリファイアをハッシュ化する際に使用したハッシュ方式を提供します。トークンエンドポイントは、指定されたハッシュ方式でコードチャレンジをデハッシュし、その結果がコードベリファイアと一致するかを確認することで、認可コードが同じクライアントから送信されたことを認証します。その後、トークンエンドポイントはIDトークンとアクセストークン（要求があれば更新トークンも）を発行します。クライアントはIDトークンから必要なユーザー情報を取得します。