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

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

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

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

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

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

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

このフローでは、クライアント（RP）がコードベリファイア（ランダムな文字列）とコードチャレンジ（任意のハッシュアルゴリズムでコードベリファイアをハッシュ化したもの）を生成します。認可リクエストをOPの認可エンドポイントに送信する際、クライアントはコードベリファイアも送ります。ユーザーが認証・認可された後、認可エンドポイントはクライアントに認可コードを送信します。OPのトークンエンドポイントでは、クライアントがこの認可コードとともにコードチャレンジおよび使用中のハッシュ方式を指定してコードベリファイアをハッシュ化します。トークンエンドポイントは、指定されたハッシュ方式でコードチャレンジを復元し、その結果とコードベリファイアを照合して、認可コードを受け取ったクライアントが認可リクエストを送信したクライアントと同一であることを認証します。その後、トークンエンドポイントはIDトークンとアクセストークン（リクエストがあれば、更新用トークンも）を発行します。クライアントはIDトークンから必要なユーザー情報を取得します。