OAuth ― パスワードを渡さず、アクセスを委ねる

写真を読ませたい。パスワードは渡したくない

アオイさんは、写真サービスの写真を印刷アプリで使いたいと考えています。印刷アプリへ写真サービスのパスワードを渡すと、必要以上の力を与えてしまいます。

OAuthは、アプリへ限定したアクセスを委ねるための仕組みです。利用者、アクセスを必要とするクライアント、許可を扱う認可サーバー、データを返すリソースサーバーが登場します。RFC 6749

この教材はOAuth 2.0のAuthorization Code FlowにPKCEを組み合わせた例です。すべてのOAuthフローで人が同意画面を操作するわけではありません。

印刷アプリはブラウザを認可サーバーへ向けます。主な情報は、アプリの識別子 client_id、戻り先 redirect_uri、求める範囲 scope、response_type=code です。

この例では scope=photos:read を求めます。スコープ名は教材用の独自例で、すべてのサービスで共通の名前ではありません。

PKCEでは、アプリがランダムな code_verifier を保持し、そこから作った code_challenge をこのリクエストに付けます。図のchallengeのカードは、後で照合するための値です。PKCE

アオイさんは認可サーバー側でログインし、この例では写真の読み取りを許可します。パスワードを入力する先は写真サービス側であり、印刷アプリではありません。

認可サーバーは利用者やポリシーに基づいて許可を判断します。既存の同意などにより、毎回同意画面が出るとは限りません。

図ではアオイさんの許可が認可サーバーへ届きます。この段階では、印刷アプリが自由に使えるアクセストークンはまだ受け取っていません。

認可サーバーは、登録・検証された戻り先へブラウザを戻し、認可コードを渡します。コードは短命で一度だけ交換するための値です。APIを呼ぶアクセストークンとは別物です。

図の紫のコードが印刷アプリへ戻ってきます。クライアントは、開始したリクエストとの対応も確認します。state などによるCSRF対策を、採用する仕様に従って実施します。

戻り先の厳密な検査やPKCEなどは現在の重要な防御策です。OAuthのセキュリティ指針

印刷アプリは認可コードと code_verifier を、TLSで保護されたトークンエンドポイントへ送ります。認可サーバーは、最初の code_challenge と対応するかなどを確認します。

S256では、verifierのSHA-256をBase64urlで表現した値がchallengeになります。コードだけを盗んだ者が、verifierなしで交換するのを防ぐ仕組みです。

PKCEはクライアント認証の代わりではありません。 サーバーアプリなどの機密クライアントでは、必要なクライアント認証も行います。RFC 7636

検証を通過すると、印刷アプリはアクセストークンを受け取ります。今度はこのトークンを写真APIへ提示します。図では緑のカードが認可サーバーからアプリへ、次のページでAPIへ移動します。

アクセストークンの見た目はJWTとは限りません。受け手が内容を直接読む形式も、サーバーに照会して意味を得る不透明な値もあります。

リフレッシュトークンが発行される場合は、新しいアクセストークンを得るために使います。写真APIへ持っていくものではありません。トークンの役割

写真APIはトークンの有効性・対象・許可範囲などを確認し、許される写真を返します。「読み取り」は許可しても、「削除」まで許可したことにはなりません。

GET /photos       → photos:read の範囲で判定
DELETE /photos/42 → 読み取り権限だけでは拒否

これは説明用のAPIです。実際の権限モデルは提供元の仕様に従います。ユーザーの所有物や組織の境界など、対象単位の認可も必要です。

アクセストークンを得たことで、アプリが任意の操作をできるわけではありません。

答えはOAuthだけからは、アプリ向けの標準的な認証結果が決まらないです。OAuthの中心はアクセスの委譲で、利用者の認証結果を標準の形で受け取る仕事はOIDCが補います。

図の三種類を振り返りましょう。認可コードは交換用、アクセストークンはAPIへのアクセス用、リフレッシュトークンは再発行用です。

新しい利用者向けフローを考えるときは、PKCEを備えたコードフローと現在のセキュリティ指針を出発点にします。パスワードをアプリへ預ける方式は使いません。RFC 9700