メインコンテンツまでスキップ

その他のOAuth 2.0フロータイプ（PKCE, Client Credentials, Implicit など）

概要​

OAuth 2.0には、Authorization Code Flow以外にも多様な認可フローが存在します。
サービスやクライアントの種類、セキュリティ要件に応じて適切なフローを選択することが重要です。

1. PKCE（Proof Key for Code Exchange）​

特徴​

  • 「認可コードグラント」をスマートフォンアプリなどの“パブリッククライアント”でも安全に使うための拡張
  • クライアントシークレットを持たない環境でも、コード横取り攻撃を防止

フロー概要​

  1. クライアントが「code_verifier（ランダム文字列）」を生成し、「code_challenge（ハッシュ値）」として認可リクエストに含める
  2. 認可サーバーはcode_challengeを記録
  3. トークン取得時、code_verifierを送信し、認可サーバーが一致を確認
  4. 一致した場合のみアクセストークン発行

利用シーン​

  • スマホアプリやSPA（Single Page Application）など、クライアントシークレットを安全に保持できないケース

2. Client Credentials Flow（クライアントクレデンシャルズ）​

特徴​

  • サービスやAPI同士の連携で「ユーザー本人」の関与が不要なケース
  • クライアント自身の権限でトークン取得

フロー概要​

  1. クライアントが認可サーバーに自身のIDとシークレットを送信
  2. 認可サーバーがアクセストークンを発行
  3. クライアントはトークンでAPIを利用

利用シーン​

  • バックエンドサービス間連携
  • バッチ処理、サーバーtoサーバーAPI連携

3. Implicit Flow（インプリシットフロー）※非推奨​

特徴​

  • ブラウザ上のJavaScriptアプリ（SPA）など、即座にトークンが必要な場合に利用されてきた
  • トークンが直接フロントに返却される

フロー概要​

  1. クライアントが認可リクエストを送信
  2. 認可サーバーがアクセストークンを「即座に」redirect_uriへ返却

注意点​

  • トークンがURLフラグメントで渡るため、盗聴・漏洩リスクが高い
  • PKCE対応のAuthorization Code Flowが推奨され、現在は非推奨

4. Resource Owner Password Credentials Flow（ROPC）​

特徴​

  • クライアントがユーザーのID・パスワードを直接受け取り、トークン取得
  • 今はセキュリティ上の理由から、原則非推奨

利用シーン​

  • レガシーなシステムとの連携など、どうしても必要な場合のみ

5. Device Authorization Flow（デバイス認可フロー）​

特徴​

  • スマートテレビやIoTデバイスなど、キーボード入力が難しい機器向け
  • 別の端末（PCやスマホ）で認証・認可を行う

フロー概要​

  1. デバイスがユーザーに「コード」や「URL」を表示
  2. ユーザーがPCやスマホで認証・同意
  3. デバイスにトークンが返却される

まとめ​

  • OAuth 2.0は多様なフロータイプを持ち、利用シーンやセキュリティ要件に応じて選択できる
  • 現在は「PKCE付きAuthorization Code Flow」がWeb・モバイルの標準
  • ImplicitやROPCは非推奨。新規実装では避けることが推奨される

適切なフロー選択が、セキュアで便利なID連携の基盤となります。
仕様やセキュリティ動向も常にアップデートしていきましょう！