OAuth 2.0とOpenID Connectでセキュアな認証システムを構築する

2025年11年21日カテゴリー: 技術記事

タグ:OAuth2OpenID Connect認証認可セキュリティ

現代のWebサービス開発において、ユーザーの認証と認可は最も重要な要素の一つです。本記事では、業界標準であるOAuth 2.0とOpenID Connectを組み合わせ、セキュアでスケーラブルな認証システムを構築する方法と、その主要な概念、実装のベストプラクティスを解説します。

なぜセキュアな認証・認可が必要なのか？

今日のデジタル環境では、ユーザーは様々なWebサービスやアプリケーションを利用しています。これらのサービスが連携する際、ユーザーのプライバシーとセキュリティは最優先事項です。ユーザー名とパスワードをサービスごとに管理するのは非効率的であり、セキュリティリスクも伴います。そこで登場するのが、標準化された認証・認可フレームワークであるOAuth 2.0とOpenID Connectです。

OAuth 2.0の基本を理解する：アクセストークンによる「認可」

OAuth 2.0は、リソースオーナー（ユーザー）が自身の情報をサードパーティのアプリケーション（クライアント）に共有する際の「認可」を安全に行うためのフレームワークです。ユーザーはパスワードをクライアントに教えることなく、特定の情報へのアクセス権限をクライアントに付与できます。

OAuth 2.0の主要なロール

リソースオーナー (Resource Owner): 情報の所有者。通常はエンドユーザーです。 クライアント (Client): ユーザーに代わってリソースにアクセスしたいアプリケーション（Webサイト、モバイルアプリなど）。 認可サーバー (Authorization Server): リソースオーナーの認証を行い、クライアントにアクセストークンを発行します。 リソースサーバー (Resource Server): 保護されたリソース（ユーザー情報、APIなど）をホストし、アクセストークンを用いてリクエストを検証します。

認可コードフローの概要

最も一般的で推奨される認可フローは「認可コードフロー」です。これは、クライアントが直接ユーザーの認証情報を受け取らず、認可サーバーを介してセキュアにアクセストークンを取得する仕組みです。

クライアントが認可リクエスト: クライアントはユーザーを認可サーバーのリクエストURLへリダイレクトします。このURLにはclient_id、redirect_uri、scopeなどが含まれます。 ユーザー認証と認可: 認可サーバーはユーザーを認証し、クライアントが要求するスコープ（アクセス権限）の許可をユーザーに求めます。 認可コードの発行: ユーザーが認可を承認すると、認可サーバーはクライアントのredirect_uriに「認可コード」を渡してリダイレクトします。 アクセストークンの要求: クライアントは受け取った認可コードとその他の情報（client_id、client_secret、redirect_uri、code_verifier）を添えて、認可サーバーのトークンエンドポイントに直接リクエストします。 アクセストークンの発行: 認可サーバーは認可コードを検証し、有効であれば「アクセストークン」と、場合によっては「リフレッシュトークン」をクライアントに発行します。 リソースへのアクセス: クライアントは取得したアクセストークンを提示して、リソースサーバーの保護されたリソースにアクセスします。

OpenID Connect (OIDC) で「認証」を強化する

OAuth 2.0が「認可」のフレームワークであるのに対し、OpenID Connect (OIDC) はOAuth 2.0の認可レイヤーの上に構築された「認証」プロトコルです。OIDCは、ユーザーが誰であるか（アイデンティティ）をクライアントが安全に検証する方法を提供します。

IDトークンとクレーム

OIDCの核となるのは「IDトークン」です。IDトークンはJWT (JSON Web Token) 形式で、ユーザーの認証に関する情報（クレーム）を含んでいます。これにより、クライアントはユーザーの身元を信頼できる形で確認できます。 IDトークンに含まれる代表的なクレーム:

iss (Issuer): IDトークンを発行した認可サーバーのURL。 sub (Subject): 認可サーバー内での一意のユーザー識別子。 aud (Audience): このIDトークンを受け取るクライアントのID。 exp (Expiration Time): IDトークンの有効期限。 iat (Issued At): IDトークンが発行された時刻。 name, email, picture: ユーザーの氏名、メールアドレス、プロフィール画像などの情報（スコープに応じて）。

IDトークンの構造例 (ペイロード部)

{ "iss": "https://accounts.google.com", "azp": "{your_client_id}.apps.googleusercontent.com", "aud": "{your_client_id}.apps.googleusercontent.com", "sub": "101234567890123456789", "email": "user@example.com", "email_verified": true, "at_hash": "aBcDeF1gH2iJ3kL4mN5oP", "name": "Test User", "picture": "https://lh3.googleusercontent.com/a/AAcHTtfZ...", "given_name": "Test", "family_name": "User", "locale": "ja", "iat": 1678886400, "exp": 1678890000 }

OAuth 2.0とOIDCを連携させた認証フロー

OIDCはOAuth 2.0の拡張であるため、両者は同じ認可サーバーを共有し、密接に連携します。一般的なフローでは、認可サーバーはユーザーの認証が成功した後に、クライアントにIDトークンとアクセストークンの両方を発行します。

統合認証・認可フローの例

クライアントがユーザーの認証と同時に、特定のリソースへの認可も要求する場合、認可リクエストのscopeにopenidと、要求するリソースのスコープ（例: email profile）を含めます。 GET /authorize?response_type=code&client_id={client_id}&scope=openid%20profile%20email&redirect_uri=https://client.example.com/cb&state={state}&code_challenge={code_challenge}&code_challenge_method=S256 HTTP/1.1 Host: auth.example.com

認可サーバーは、ユーザーの認証と認可を経て、クライアントのredirect_uriに認可コードを発行します。 HTTP/1.1 302 Found Location: https://client.example.com/cb?code={authorization_code}&state={state}

次に、クライアントはこの認可コードを使用して、認可サーバーのトークンエンドポイントにアクセストークンとIDトークンの両方を要求します。 POST /token HTTP/1.1 Host: auth.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code={authorization_code} &redirect_uri=https://client.example.com/cb &client_id={client_id} &code_verifier={code_verifier}

認可サーバーは以下のようなレスポンスを返します。 { "access_token": "{access_token}", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "{refresh_token}", "id_token": "{id_token_jwt}" }

クライアントはid_tokenを検証し、ユーザーの認証情報を確認します。また、access_tokenを使用して、ユーザーのリソースにアクセスできるようになります。

実装におけるベストプラクティスとセキュリティ

PKCE (Proof Key for Code Exchange) の利用: 公開クライアント（モバイルアプリなど）では、認可コードを盗聴されるリスクを軽減するためにPKCEを必ず使用してください。 HTTPSの徹底: 全ての通信はHTTPSで行い、中間者攻撃を防ぎます。 スコープの最小権限原則: クライアントが必要とする最小限のアクセス権限（スコープ）のみを要求・付与するようにします。 トークンの安全な管理: アクセストークンやリフレッシュトークンは、クライアント側で安全に保管し、クロスサイトスクリプティング (XSS) やクロスサイトリクエストフォージェリ (CSRF) 対策を講じてください。 IDトークンの検証: クライアントは受け取ったIDトークンの署名検証、有効期限、発行者、対象クライアントなどを必ず検証する必要があります。 エラーハンドリング: 認可サーバーからのエラーレスポンスを適切に処理し、ユーザーに分かりやすいメッセージを提供します。 シークレットの保護: クライアントシークレットは、クライアント（Webアプリケーションのバックエンドなど）でのみ安全に管理し、クライアントサイドのJavaScriptなどには絶対に含めないでください。

まとめ

OAuth 2.0とOpenID Connectは、現代のWebサービスにおいて安全で効率的な認証・認可システムを構築するための強力な基盤を提供します。OAuth 2.0が「誰が何にアクセスできるか」という認可を扱い、OpenID Connectが「ユーザーは誰か」という認証を扱います。これらのプロトコルを正しく理解し、ベストプラクティスに従って実装することで、ユーザーのセキュリティと利便性を両立させたサービスを提供することができます。