『OAuth は認可、OIDC は認証』の使い分けが基本
OAuth 2.0 は認可(権限委譲)、OIDC は認証(ID提供) のプロトコルです。両者を区別せず実装すると脆弱性の温床になります。本記事では編集部の視点で、実装の要点を公開情報をもとに整理します。認証・認可実践 もご参考に。
主要な登場人物
(1) Resource Owner：ユーザー本人。(2) Client：あなたのアプリ。(3) Authorization Server：認証認可サーバ(Google等)。(4) Resource Server：API 提供側。(5) Identity Provider (IdP)：OIDC でユーザー情報を提供。
主要なフロー
(1) Authorization Code + PKCE：現代の標準。SPA/モバイル/Web 全対応。(2) Client Credentials：マシン間認証(M2M)。(3) Device Authorization：TV/IoT 等の入力制約端末。(4) Refresh Token：アクセストークン更新。(5) Implicit / Password Grant は非推奨：使わない。最新の推奨は OAuth 2.1 仕様をご確認ください。
PKCE の使い方
(1) code_verifier：高エントロピー乱数を生成。(2) code_challenge：S256 でハッシュ化して送信。(3) 認可コード返却：通常通り。(4) トークン交換時に code_verifier も送る。(5) クライアントが秘密を持てない環境で必須。SPA/モバイル/CLI 等で必須化が進んでいます。
OIDC のID トークン
(1) JWT 形式：自己完結したID情報。(2) クレーム：sub/iss/aud/exp 等を必ず検証。(3) 署名検証：JWKS から公開鍵を取得。(4) nonce 検証：リプレイ攻撃対策。(5) userinfo エンドポイント：追加情報の取得。
SSO 設計
(1) 社内 IdP：Auth0 / Okta / Microsoft Entra ID / Keycloak。(2) SAML との併用：エンタープライズ要件で多い。(3) セッション管理：シングルログアウト対応。(4) 監査ログ：誰がいつログインしたか。(5) MFA：必須化を推奨。Web セキュリティ実践 も合わせて。
セキュリティ落とし穴
(1) state パラメータ忘れ：CSRF 攻撃を許す。(2) リダイレクトURI の検証緩い：オープンリダイレクト。(3) トークンを localStorage：XSS で奪取される。(4) 長期有効なアクセストークン：失効ロジックなし。(5) scopes 過剰要求：ユーザー不信。対策は、(1)state必須、(2)完全一致リダイレクト、(3)HttpOnly cookie、(4)短期+refresh、(5)最小スコープ、です。
失敗しがちなパターン
(1) 自前実装：仕様の落とし穴で脆弱性。(2) 古いフロー使用：Implicit/Password。(3) PKCE 未適用：SPA で必須。(4) JWT 検証を省略：偽トークンを通す。(5) リフレッシュトークンの永続化：盗難被害が長期化。対策は、(1)既存実装(Auth.js/Auth0等)活用、(2)Authorization Code+PKCE、(3)PKCE 標準化、(4)JWKS 検証、(5)Refresh ローテーション、です。