OpenID Connect（OIDC）は、OAuth 2.0の上に構築された認証プロトコルで、ユーザーが認証されたことを信頼できる方法で確認するための標準的なフローを提供します。OIDCの処理フローは、ユーザーがIDプロバイダー（IdP）に認証され、クライアント（アプリケーション）がそのユーザーのID情報を取得するための手順に従います。以下がその一般的なフローです。
1. 認可リクエスト
クライアント（アプリケーション）は、認可エンドポイントにリクエストを送信します。リクエストには、OIDCで必要な情報が含まれています。
- レスポンスタイプ：たとえば「code」など（認可コードフローの場合）。
- クライアントID：クライアントの識別子。
- リダイレクトURI：認可が完了した後に、認可コードを送信するURI。
- スコープ：リクエストされた情報の範囲。OIDCの場合、通常「openid」が含まれます。
- 状態（state）：CSRF（クロスサイトリクエストフォージェリ）攻撃を防ぐために使用されます。
2. ユーザー認証
ユーザーは、認可サーバー（IDプロバイダー）でログインを行います。ログイン方法は、ユーザー名/パスワード、2要素認証など、プロバイダーの設定に依存します。
3. 認可コードの発行（認可コードフローの場合）
ユーザーが正常に認証されると、IDプロバイダーは指定されたリダイレクトURIにユーザーをリダイレクトし、その際にクエリパラメータとして認可コードを送信します。クライアントはこの認可コードを使ってトークンを取得します。
4. トークンリクエスト
クライアントは認可コードを用いてトークンエンドポイントにリクエストを送信します。このリクエストには以下が含まれます。
- 認可コード：IDプロバイダーから受け取ったコード。
- リダイレクトURI：認可リクエストで指定したものと同じ。
- クライアントIDおよびクライアントシークレット：クライアントの認証情報。
5. トークンレスポンス
IDプロバイダーは、以下を含むトークンレスポンスを返します。
- IDトークン：JWT形式のトークンで、ユーザーの認証情報（サブジェクト、発行者、発行時間、期限など）が含まれます。
- アクセストークン：保護されたリソースにアクセスするためのトークン。
- リフレッシュトークン（オプション）：アクセストークンの有効期限が切れたときに新しいアクセストークンを取得するためのトークン。
6. IDトークンの検証
クライアントは、IDトークンの署名と内容を検証します。検証プロセスには以下が含まれます。
- 署名の検証：IDトークンがIDプロバイダーによって署名されたことを確認します。
- クレームの検証：例えば「aud」（受信者）がクライアントIDと一致しているか、「exp」（有効期限）が現在の時間を過ぎていないかなどを確認します。
7. ユーザー情報の取得（オプション）
アクセストークンを使ってユーザー情報エンドポイントにリクエストを送信し、追加のユーザー情報（名前、メールアドレスなど）を取得することができます。
OIDCの主なフロー
OIDCにはいくつかの異なるフローが存在し、利用するシナリオに応じて使い分けられます。
- 認可コードフロー：サーバー側アプリケーションが認証情報を取得する標準的なフローです。
- インプリシットフロー：クライアントがトークンを直接受け取るフローで、主にクライアント側（ブラウザ）で処理が行われる場合に使用されます。
- ハイブリッドフロー：認可コードフローとインプリシットフローの組み合わせで、途中でアクセストークンを受け取ることができます。
まとめ
OpenID Connectのフローは、クライアントがユーザーの認証情報を取得し、IDプロバイダーがそれを信頼できる方法でクライアントに提供する仕組みです。主に認可コードフローが使われ、セキュリティと柔軟性が高く、多くのWebアプリケーションやモバイルアプリケーションで利用されています。