ritouです。
今回はこの話です。
こまけぇ話は置いておいて、BearerとSender-Constrainedの話がHTTP Cookieのところでも出てきたよというお話なのですが、ここを少し補足します。このBearer vs Sender-Constrainedという用語が一番出てくるのがOAuthの文脈です。
概念はこんな感じですが、実装方法は色々なものがあります。
APIアクセスの際のアクセストークンの例だと
Bearer Token
Authorization Header にトークン文字列を指定するだけで使える
Sender-Constrained Token
MTLS: アクセストークンがクライアント証明書と紐づけられているので、HTTPリクエストとの検証が必要だよ
DPoP: 鍵ペアと紐づけられているので、その秘密鍵で生成したJWTと一緒に送られてきたことの検証が必要だよ
と言ったように、送信者の制限部分にはバリエーションがあるんですよというのを認識しておいてもらえたらおkです。
今回のCookieの話もそう考えると理解しやすいのではないでしょうか。HTTP Cookieというのは発行されたものをブラウザが保持して対象ドメインへのリクエストに付与するわけですが、その文字列自体を盗まれるとそこに紐づけられたログインセッションまで奪われてしまうリスクがあります。
Goals
Reduce session theft by offering an alternative to long-lived cookie bearer tokens, that allows session authentication that is bound to the user's device. This makes the internet safer for users in that it is less likely their identity is abused, since malware is forced to act locally and thus becomes easier to detect and mitigate. At the same time the goal is to disrupt the cookie theft ecosystem and force it to adapt to new protections.
先ほどのDPoPのように、デバイスで保持している鍵ペア(の公開鍵)とCookieを紐付け、Cookie利用時にそれを検証できるようにすることでSender-Constrained Tokenを実現します。そうなるとCookieを利用してセッション奪取を狙うマルウェアはデバイス上で動作せざるを得ないため、検知などが容易になるでしょうと。まぁそんな感じです。
細かい仕様にも触れたいところですが今回はSender-Constrained Tokenについて覚えてくださいというのが主旨なので別途Zennにでも書きます。
最後に、アクセストークンやCookie以外でもSender-Constrained Tokenというものは既にたくさんあるんだよという話をします。
OAuth 2.0のConfidential Clientが利用する認可コード: 認可コードを用いてアクセストークンを要求する際に認可リクエストに指定されたClientのクレデンシャルを確認するClient認証を必要とする
OAuth 2.0のConfidential Clientが利用するRefreshToken: リフレッシュトークンを用いてアクセストークンを要求する際に、リフレッシュトークンと紐づけられたClientのクレデンシャルを確認するClient認証を必要とする
RFC7636 PKCEを利用した認可レスポンスに含まれる認可コード: 認可コードを用いてアクセストークンを要求する際に認可リクエストに指定されたCode Challengeの元になったCode Verifierの指定が必要となる
いかがでしょうか？特に認可コードについてはクロスドメインのデータのやりとりで使われるものですが利用時にリクエストの送信者が正しい対象であることを確認できるようになっています。一時的にやり取りされる文字列、これもトークンと呼べるわけですがSender-Constrained Tokenにすることでセキュアな実装に繋がるわけです。
このようなSender-Constrained TokenはOAuthにとどまらず、様々なユースケースで利用可能な概念です。もしかしたら気づかずにこの仕組みを使っていることもあるかもしれません。覚えておいて活用してみましょう。
ではまた。