内包型アクセストークン、典型例としては JWT アクセストークンは、関連するデータを自身の内部に持っています。下記の条件が成り立つと、論理的な帰結として、そのようなアクセストークンから直接個人情報が漏洩します。
- 個人情報が含まれている
- 暗号化されていない
- ステートレス
- 意図しない者に盗まれる
ここで「ステートレス」とは、「個人情報を保存するためのデータベースレコードを認可サーバー側に持たない」ことを意味しています。
もしもアクセストークンの実装が「内包型／暗号化されていない／ステートレス」であり、また、システムがクライアントアプリケーションに個人情報を提供する必要があるなら、当該システムは、アクセストークンに情報を埋め込むことを避け、個人情報を問い合わせるための Web API を提供すべきです。
ユーザー情報エンドポイント (OIDC Core Section 5.3) はそのような API ですが、認可サーバーが claims リクエストパラメーター (OIDC Core Section 5.5) をサポートしたければ内包型ステートレスアクセストークンは「ユーザー情報エンドポイントでどのクレーム（ユーザー属性）が要求されているか」に関する情報を含む必要があること、および、医療記録関連のクレームなどクレームによってはクレーム名の存在そのものが個人情報になりうること、について頭にとどめておいてください。
もう一つの比較的新しい懸念事項はアクセストークン内の authorization_details です。
OAuth 2.0 Rich Authorization Requests (RAR) は authorization_details パラメーターを定義しています。このパラメーターは、認可リクエスト、トークンレスポンス、イントロスペクションレスポンス、JWT アクセストークンなど、さまざまな場所で使うことができます。
しかし、暗号化されていない JWT アクセストークンに埋め込むには、authorization_details の内容はあまりに詳細過ぎます。下記は RAR 仕様書から抜粋した JWT アクセストークンのペイロードの例です。この例内の authorization_details は購入履歴レコードの詳細情報を含んでいます。
プライバシーの観点から言えば、内包型アクセストークンよりもハンドル型アクセストークンの方がはるかに良いです。しかし、なんらかの理由により、あなたのシステムでは内包型アクセストークンを使わざるをえないかもしれません。そのような場合、(a) アクセストークンを暗号化する、(b) 個人情報をアクセストークンに埋め込まない、のどちらか、もしくは両方を実施することが強く推奨されます。
アクセストークンの暗号化は想像するほど単純ではありません。詳細な議論に興味があれば『OAuth アクセストークンの実装に関する考察』をご覧ください。
本記事の英語版はこちらです→ Leakage of Personal Information via JWT Access Token