6. Privacy Considerations (プライバシーに関する考慮事項)

JWTアクセストークンは値によって情報を保持するため、クライアントおよび場合によってはエンドユーザーでさえ、暗号化されていないトークンのクレームコレクション内を直接覗くことが可能になりました。

クライアントはアクセストークンの内容を検査してはなりません (MUST NOT)。認可サーバーとリソースサーバーは、いつでもトークン形式を変更することを決定する可能性があります (たとえば、このプロファイルから不透明トークンに切り替えることによって)。したがって、アクセストークンの内容を読み取る能力に依存するクライアント内のロジックは、手段なく破損します。OAuth 2.0フレームワークは、アクセストークンがクライアントによって不透明なものとして扱われることを前提としています。認可サーバーの管理者は、アクセストークンの内容がクライアントに見えることも考慮に入れるべきです。特定のシナリオでアクセストークンの内容へのクライアントアクセスがプライバシー問題を提示する場合、認可サーバーはそれらを防ぐための明示的な手順を取る必要があります。

JWTアクセストークンがエンドユーザーにアクセス可能なシナリオでは、情報がプライバシー侵害なしにアクセスできるか (たとえば、エンドユーザーが単に自分自身の個人情報にアクセスする場合) 、または機密性を強制するための手順を取る必要があるかを評価すべきです。

クライアントとエンドユーザーへの情報漏洩を防ぐための可能な措置には、アクセストークンの暗号化、機密クレームの暗号化、機密クレームの省略またはこのプロファイルを使用せず不透明アクセストークンにフォールバックすることが含まれます。

すべてのシナリオにおいて、JWTアクセストークンの内容は最終的にリソースサーバーにアクセス可能になります。リソースサーバーが、たとえば何らかの形式のユーザーの同意、認可サーバーを運営する組織とのポリシーや契約などを通じて、クレームの形式で受け取る任意の内容へのアクセスに対する適切な権利を取得したかどうかを評価することが重要です。たとえば、ユーザーは、セクション2 (およびそのサブセクション) に列挙されている非必須クレームのいずれかについて、特定のリソースサーバーに情報を付与することに同意したくない場合があります。

このプロファイルは、すべてのJWTアクセストークンに "sub" クレームの存在を義務付けており、リソースサーバーが認証されたプリンシパルのためにローカルに保存されたデータと受信要求を関連付けるためにその情報に依存することを可能にします。要求を関連付ける能力は多くのシナリオで設計上必要とされる可能性がありますが、認可サーバーが関連付けを防ぎたいシナリオもあります。"sub" クレームは、プライバシー影響評価 (Privacy Impact Assessment) に従って認可サーバーによって設定されるべきです。たとえば、ソリューションが複数のリソースサーバー間でプリンシパルのアクティビティの追跡を防ぐ必要がある場合、認可サーバーは、異なるリソースサーバー向けのJWTアクセストークンが、リソースサーバーの共謀の場合に関連付けできない異なる "sub" 値を持つことを確保すべきです。同様に、ソリューションがリソースサーバーがリソース自体内でプリンシパルのアクティビティを関連付けることを防ぐ必要がある場合、認可サーバーは、発行されるすべてのJWTアクセストークンに異なる "sub" 値を割り当てるべきです。次に、クライアントは、リソースサーバーがすべての呼び出しで異なる "sub" および "jti" 値を受け取ることを確保するために、リソースサーバーへのすべての呼び出しに対して新しいJWTアクセストークンを取得し、異なる要求間の関連付けを防ぐべきです。