OAuth がリダイレクトで運ぶのは、アクセストークンではなくコード

『セキュリティとAIの仕組み』の「「本人である」の作り方 — 認証と認可は別物」で、RFC 6750 の Bearer トークンの定義を見ました。持っているだけで使える、という定義です。

リダイレクトで運ばれる値は、URL としてあちこちに残ります。RFC 6819 §3.4 は、トークンの代わりに認可コードを送る目的を2つ挙げています。

1. Browser-based flows expose protocol parameters to potential attackers via URI query parameters (HTTP referrer), the browser cache, or log file entries, and could be replayed. In order to reduce this threat, short-lived authorization "codes" are passed instead of tokens and exchanged for tokens over a more secure direct connection between the client and the authorization server.
2. It is much simpler to authenticate clients during the direct request between the client and the authorization server than in the context of the indirect authorization request. The latter would require digital signatures.

要は2つ目、クライアントを確かめる場所を直接の要求に移す点です。RFC 6749 §1.3.1 も同じ2点を挙げています(the ability to authenticate the client と、アクセストークンを without passing it through the resource owner's user-agent で渡せること)。

表経路を通る以上、認可コードは見られることがあります。そこで仕様は、コードの価値を絞っています。RFC 6749 §4.1.2 の code の定義です。

The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI.

義務には主語と強さがあります。表の機密クライアントは、資格情報の秘密を保てるクライアントです(RFC 6749 §2.1 Clients capable of maintaining the confidentiality of their credentials)。

主語          強さ          内容
認可サーバ    MUST          発行後すぐに失効させる
(上限の目安)  RECOMMENDED   最大10分
クライアント  MUST NOT      同じコードを2回使う
認可サーバ    MUST          2回目の要求を拒否する
認可サーバ    SHOULD        そのコードから出したトークンを取り消す
クライアント  MUST          機密クライアントならクライアント認証を行う
クライアント  MUST          redirect_uri を認可要求に含めた場合は同じ値を送る

加えて RFC 9700 §2.1 は、登録済みのリダイレクト URI との比較に exact string matching を MUST としています(ネイティブアプリの localhost のポート番号は例外)。

おもちゃの認可サーバはこれらを実装しています。

### [4] same code a 2nd time (with the correct client secret)
< HTTP/1.1 400 Bad Request
{"error":"invalid_grant","error_description":"code already used"}
### [5] resource with the earlier token after the reuse attempt
{"error":"invalid_token"}
### [6] fresh code, redeemed WITHOUT the client secret
{"error":"invalid_client"}
HTTP 401
### [7] authorize with a redirect_uri that differs by one trailing slash
{"error":"invalid_request"}
HTTP 400

同じコードの2回目([4])、シークレット無しの交換([6])、末尾スラッシュ1文字違い([7])がすべて拒否されました。2回実行して結果は同じでした。

[5] で1回目のアクセストークンまで無効になったのは、SHOULD revoke を実装したからです。SHOULD なので、実在のサーバが必ずこう動くとは限りません。 10分の失効は、この実演では試していません。