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

ここでは、OIDC の動作を理解する前に、いくつかの用語について確認しておきましょう。

Relying Party は、OpenID Provider の Authorization Endpoint に対して、ユーザーの認証と、特定のユーザー情報へのアクセス権限の付与を要求します。ユーザーの認証と認可が完了すると、Authorization Endpoint は Relying Party に ID トークンとアクセストークンを送信します。

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

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

このフローでは、クライアント（RP）が OP の Authorization Endpoint に対して、ユーザーの認証と特定のユーザー情報へのアクセス権限を要求します。ユーザーの認証と認可が完了すると、Authorization Endpoint は ID トークンを直接クライアントに送信します。要求されている場合は、アクセストークンやリフレッシュトークンも送信されます。クライアントは ID トークンから必要なユーザー情報を取得します。このフローでは Token Endpoint は使用されません。

ネイティブアプリケーションは、特定のデバイスに直接インストールされるアプリケーションです。Public Client（公開クライアント）とも呼ばれます。デバイスに直接インストールされ、アプリケーションがデコンパイルされてクライアントシークレットにアクセスされる可能性があるため、シークレットを安全に保存できません。ネイティブアプリに推奨されるフローは、Proof Key for Code Exchange (PKCE) を用いた Authorization コード フローです。

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