OAuth 2.1とOpenID Connect実践ガイド：セキュアな認証・認可の最新動向【2025年版】

はじめに：認証と認可 - OAuthとOIDCの役割分担

Webサービスを開発する上で、「ログイン機能」や「外部サービス連携機能」は不可欠です。これらをセキュアに実現するための標準プロトコルがOAuthとOpenID Connect (OIDC) ですが、両者の役割は明確に異なります。

• 認証 (Authentication): 「あなたが誰であるか」を確認するプロセスです。IDとパスワードの入力などがこれにあたります。OIDCは、この認証を行うためのプロトコルです。
• 認可 (Authorization): 「あなたが何をできるか」を許可するプロセスです。例えば、「あるアプリケーションが、あなたの代わりにGoogleカレンダーの予定を読み取ることを許可する」といった制御がこれにあたります。OAuthは、この認可を行うためのプロトコルです。

簡単に言えば、OIDCはOAuthの上になりたつ認証レイヤーです。「OIDC = OAuth + IDトークン」と理解すると分かりやすいでしょう。

近年、セキュリティのベストプラクティスは急速に進化しており、それに伴いプロトコル自体もアップデートされています。本記事では、最新のOAuth 2.1で推奨されるフローと、OIDCを使った認証の実装方法について、その「なぜ」を重視しながら解説します。

OAuth 2.1の主要な登場人物とフロー

OAuthのフローを理解するために、まず登場人物を整理しましょう。

• リソースオーナー: あなた（ユーザー）。データ（リソース）の所有者。
• クライアント: あなたが利用するWebアプリケーションやスマートフォンアプリ。
• 認可サーバー: Google, GitHub, Auth0など、ユーザーの認証を行い、クライアントにアクセスの許可を与えるサーバー。
• リソースサーバー: Google Calendar APIなど、保護されたリソースを管理するAPIサーバー。

OAuth 2.1で最も重要かつ唯一推奨されるフローがPKCE (Proof Key for Code Exchange) 付き認可コードフロー (Authorization Code Flow) です。このフローの目的は、クライアントが安全にアクセストークンを取得することです。

なぜImplicit Flowは非推奨になったのか？ PKCEの重要性

かつて、ブラウザ上で動作するSPA（Single Page Application）では、認可コードの交換ステップを省略し、認可サーバーから直接アクセストークンを受け取るImplicit Flowが使われていました。しかし、このフローには、アクセストークンがブラウザの履歴などに漏洩するリスクがあり、現在では完全に非推奨となっています。

これに代わるのがPKCEです。PKCEは「ピクシー」と読み、認可コードの横取り攻撃を防ぐための仕組みです。

1. クライアント: code_verifierというランダムな文字列を生成します。
2. クライアント: code_verifierをハッシュ化（SHA256）し、code_challengeを作成します。
3. クライアント: 認可リクエスト時に、このcode_challengeを認可サーバーに送ります。
4. 認可サーバー: code_challengeを認可コードと紐付けて保存します。
5. クライアント: トークンリクエスト時に、ハッシュ化する前のcode_verifierを認可サーバーに送ります。
6. 認可サーバー: 受け取ったcode_verifierをハッシュ化し、保存しておいたcode_challengeと一致するか検証します。一致した場合のみ、アクセストークンを発行します。

これにより、もし悪意のあるアプリが認可コードを横取りしたとしても、元のcode_verifierを知らないため、アクセストークンを取得することができません。OAuth 2.1では、このPKCEの使用が必須となりました。

ステップ1：認可リクエスト

フローの開始点です。クライアントは、ユーザーを認可サーバーの認可エンドポイントにリダイレクトさせます。このとき、いくつかのパラメータをクエリ文字列として渡します。

GET https://authorization-server.com/authorize?
  response_type=code&
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://client-app.com/callback&
  scope=read:calendar&
  state=xyzABC123&
  code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&
  code_challenge_method=S256

• response_type=code: 認可コードフローを使用することを示します。
• client_id: クライアントのID。
• redirect_uri: 認可後にユーザーがリダイレクトされるURL。
• scope: クライアントが要求する権限の範囲（スコープ）。
• state: CSRF攻撃を防ぐためのランダムな文字列。クライアントはリダイレクト時にこの値が一致するか検証します。
• code_challenge / code_challenge_method: PKCEのためのパラメータ。

ユーザーは認可サーバーの画面でログインし、クライアントに要求された権限を与えることに同意します。

ステップ2：トークンリクエスト

ユーザーが同意すると、認可サーバーはユーザーをredirect_uriにリダイレクトさせます。このとき、URLのクエリパラメータに認可コードが付与されています。

https://client-app.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyzABC123

次に、クライアントはバックエンドから、この認可コードを使って認可サーバーのトークンエンドポイントにリクエストを送信します。

POST https://authorization-server.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=SplxlOBeZQQYbYS6WxSbIA&
redirect_uri=https://client-app.com/callback&
client_id=YOUR_CLIENT_ID&
client_secret=YOUR_CLIENT_SECRET&  <-- Confidential Clientの場合
code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

• grant_type=authorization_code: 認可コードをアクセストークンに交換することを示します。
• code: 受け取った認可コード。
• code_verifier: PKCEのための元のランダムな文字列。

認可サーバーはcode_verifierを検証し、問題がなければアクセストークンを返します。

ステップ3：リソースアクセス

クライアントは、取得したアクセストークンを使って、保護されたリソースサーバーのAPIにアクセスします。アクセストークンは、HTTPリクエストのAuthorizationヘッダーに含めるのが一般的です。

GET https://resource-server.com/api/calendar/events
Authorization: Bearer <ACCESS_TOKEN>

リソースサーバーは、このアクセストークンを検証し、有効であればリソースを返します。

OpenID Connectによる認証の実装

ここまでのフローは「認可」のためのものでした。では、「認証」つまり「誰がログインしたか」を知るにはどうすればよいでしょうか。ここでOIDCが登場します。

OIDCを利用するには、認可リクエストのscopeにopenidを追加するだけです。

scope=openid profile email

openidスコープが含まれていると、認可サーバーはアクセストークンと一緒にIDトークンを返します。IDトークンはJWT (JSON Web Token) 形式の文字列で、中には以下の様なユーザー情報（クレーム）が含まれています。

• sub: ユーザーの一意な識別子
• iss: IDトークンの発行者（認可サーバー）
• aud: IDトークンの対象者（クライアントID）
• exp: IDトークンの有効期限
• name, emailなど（profileやemailスコープを要求した場合）

クライアントは、このIDトークンの署名を検証することで、ユーザーが確かに認可サーバーによって認証されたことを確認し、ユーザーの身元情報を安全に取得できます。

まとめ：セキュアなWebアプリケーションのための必須知識

OAuth 2.1とOIDCは、現代のWebアプリケーションにおけるセキュリティの根幹をなす技術です。

• 認可にはOAuth: 外部サービスのリソースへのアクセス許可を得るために使います。
• 認証にはOIDC: ユーザーが誰であるかを確認するために使います。
• PKCE付き認可コードフローが標準: SPAを含むすべてのクライアントタイプで、このフローを使用することが強く推奨されます。
• Implicit Flowは使用しない: セキュリティリスクのため、完全に過去のものとなりました。

これらのプロトコルを正しく理解し、実装することは、ユーザーのデータを保護し、信頼性の高いサービスを提供するための開発者の責務と言えるでしょう。