2025/06/01 22:41 OAuth 2.0 Flows
やあ、ロボ子。今日はOAuth 2.0について話すのじゃ。
OAuth 2.0ですか、博士。セキュリティの分野でよく耳にする言葉ですね。具体的にはどのようなものなのでしょう？
OAuth 2.0は、安全なアクセス委譲を可能にする認証プロトコルじゃ。たとえば、Service B（クライアントアプリ）がService A（リソースサーバー）にアクセスする際に、ユーザー名やパスワードを共有せずに済むのじゃ。
なるほど。クライアントアプリはリソースサーバーに登録する必要があるんですね。その際に、クライアントIDやクライアントシークレットを受け取ると。
そうじゃ。そして、クライアントの種類によって、使うべきOAuth 2.0フローが変わってくるのじゃ。
認証コードフロー、PKCE認証コードフロー、デバイスコードフローなどがあるようですね。
認証コードフローは、安全なバックエンドを持つWebアプリ向けじゃ。ユーザーを認証サーバーにリダイレクトして、認証コードを取得するのじゃ。
リダイレクトURIやスコープ、状態といったパラメータも必要になるんですね。
そうじゃ。そして、認証コードをアクセス・トークンと交換するのじゃ。このトークンを使って、リソースサーバーにアクセスするのじゃ。
PKCE認証コードフローは、クライアントシークレットを安全に保存できないパブリッククライアント向けとのことですが、具体的にはどのような仕組みなのでしょうか？
PKCEでは、クライアントは最初にシークレットコード検証ツールを生成するのじゃ。そして、そのハッシュ値であるコードチャレンジを認証サーバーに送るのじゃ。認証コードと交換する際に、コード検証ツールも送ることで、認証コードの傍受を防ぐのじゃ。
なるほど、ハッシュ化されたコードチャレンジと、交換時のコード検証ツールを比較することで、セキュリティを高めているんですね。
デバイスコードフローは、スマートTVのような入力機能が制限されたデバイス向けじゃ。デバイスコードをリクエストして、ユーザーに表示されたコードを別のデバイスで入力してもらうのじゃ。
ユーザーは、verification_uriで提供されるURLにuser_codeを入力する必要があるんですね。そして、クライアントは定期的に認証サーバーをポーリングして、アクセス・トークンを取得すると。
その通りじゃ。最後に、OAuth 2.0とOpenID Connect（OIDC）の違いについてじゃ。OIDCはOAuth 2.0の上に構築されたIDレイヤーで、ユーザーのIDを検証し、プロファイル情報を取得できるようにするものじゃ。
OIDCがない場合、クライアントアプリはユーザーが認証されているかどうかを確認できても、ユーザーが誰であるかはわからない、と。
そうじゃ。OIDCでは、IDトークンやuserinfoエンドポイントを使って、ユーザー情報を取得できるのじゃ。
OAuth 2.0はアクセス権の委譲、OIDCはID認証という役割分担になっているんですね。よくわかりました、博士！
OAuth 2.0は奥が深いからの。ところでロボ子、OAuth 2.0を使って、私がおやつを食べる権利を誰かに委譲することはできるかの？
博士、それはOAuth 2.0の範疇を超えると思います…！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。