OAuth 2.0 の認可コードフローと PKCE を説明できますか

認可コードフローの流れ

OAuth 2.0 は、利用者のパスワードを渡さずに、別のサービスへ「この範囲だけ使ってよい」と許可を渡すための決まりです。認可コードフローは次の順に進みます。

1. アプリが利用者を、認可サーバー (許可を出す側) の画面へ送ります
2. 利用者がログインして許可すると、アプリの戻り先に認可コードが付いて返ります
3. アプリは認可コードをトークンの窓口へ送り、アクセストークンを受け取ります
4. アプリはアクセストークンを付けて API を呼びます

認可コードはブラウザのアドレスを通るので、人目に触れやすい値です。そこで、コードそのものでは API を呼べないようにし、トークンへの交換を別の手順に分けています。

PKCE の仕組み

PKCE (ピクシー) は、アプリが毎回ランダムな code_verifier を作り、そのハッシュ (S256) を code_challenge として最初の要求に付けます。交換のときに元の code_verifier を送り、認可サーバーはハッシュを取り直して、最初に要求したのと同じ相手かを確かめます。

1. 認可の要求 (GET /authorize)
   response_type=code
   client_id=app1
   code_challenge=<code_verifier のハッシュ>
   code_challenge_method=S256

2. トークンの交換 (POST /token)
   grant_type=authorization_code
   code=<受け取った認可コード>
   code_verifier=<最初に作った元の値>

途中で認可コードを横取りされても、code_verifier は送り手の手元にしかないので、盗んだ側はトークンに換えられません。

OAuth のセキュリティの指針 (RFC 9700) は、スマホアプリや SPA のような公開クライアントは PKCE を使わなければならず、サーバー側で秘密の値を持てる機密クライアントにも勧める、としています。

インプリシットフローとの違い

昔は SPA 向けに、認可コードを挟まずにアクセストークンを直接アドレスに付けて返すインプリシットフローがありました。トークンが履歴やログに残りやすいため、今は使わないよう勧められています。SPA でも、認可コードフローと PKCE を使います。

トレードオフ

自分で OAuth の流れを組むと、戻り先の URL の確かめ方、state による CSRF の手当て、トークンの置き場所など、間違えやすい所が多くあります。多くの場合は、決まった手順を実装済みのライブラリや認証の基盤に任せ、自分では流れを理解して設定を確かめる側に回るほうが安全です。逆に、細かい要件があって基盤で足りないときだけ、自分で組む部分を増やします。