え？ OAuth 2.0 の Access Token も JWT じゃなかったの？と思っている皆さん

OAuth Security AccessToken JWT

こんばんは、ritou です。

パスキーの記事ばっかり書いてないでたまにはOAuthのことも取り上げましょう。

OAuthのAccess Tokenについて少し復習してみましょう。

OAuthのAccess Token ってJWTじゃないの？

これについては、我らが Auth屋さん がお話しする会みたいなので自分の方でもいくつか勝手に質問に答えた中にありました。

www.rfc-editor.org

1.4. Access Token

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.

と言うように、ここでは opaque = 不透明？ぐらいしか定義されていません。

www.rfc-editor.org

This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.

JWTのフォーマットを決めたらRSとASが異なるサービスの場合でも互換性取りやすいと言うところです。

Access Tokenの設計については、素晴らしい解説記事があります。

qiita.com

JWTかどうかわからないならClientはデコードできないのでは？

ClientはOAuthのAccess Tokenをデコードする必要はありません。

この思い込みはどこから来るのでしょうか？

いわゆる OAuth認証 においてリスクを回避するためにアクセストークンの発行対象が正しいかどうかを検証すべきみたいな話がありました。そのために、Clientはアクセストークンが自分に対して発行されたものであることを確認できるべき、JWTなら署名検証してPayloadを見たら確認できるじゃんと言うところから来ているのではないかと思っています。

OAuthにおける各種トークンのAudienceとは誰でしょうか？

  • Authorization Code: Token Endpoint
  • Refresh Token: Token Endpoint
  • Access Token: Protected Resources

となります。素晴らしい解説動画があります。

www.youtube.com

Clientはこのトークンを使ってRSにアクセスしろ、と言うだけの話なので中身を知る必要はありません。 上記のように、ClientがATの中身を気にする必要があるケースは、何かしら設計が間違っている可能性があります。

ちなみに、OIDCのIDTokenはClient(RP)ですよ。

最後に

JWT な Access Token と言えばこの人ですね。

RFC 9068 の Author

R.I.P.