[Openid-specs-fapi] Issue #617: Security issue in the JWT Response for OAuth Token Introspection specification (openid/fapi)

[Takahiko Kawasaki]

New issue 617: Security issue in the JWT Response for OAuth Token Introspection specification
https://bitbucket.org/openid/fapi/issues/617/security-issue-in-the-jwt-response-for

Takahiko Kawasaki:

One concern about the adoption of the “[JWT Response for OAuth Token Introspection](https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/)” specification as a part of FAPI 2 Message Signing is that the current draft of the specification might lead to insecure implementations, which could potentially cause personal information leakage.

The specification attempts to register some metadata as “**client** metadata” instead of “**resource server** metadata” \([draft-jones-oauth-resource-metadata](https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/)\). Treating resource servers as clients could possibly **enable a client application to obtain information about access tokens of other client applications** \(see the attached diagram\). If the implementation of the introspection endpoint embeds `username` \(RFC 7662\) and `verified_claims` \(OIDC4IDA\), it may lead to personal information leakage to unintended client applications. Additionally, rich authorization information tied to access tokens through the `authorization_details` parameter \([RFC 9396](https://www.rfc-editor.org/rfc/rfc9396.html)\) could be a potential source of personal information leackage.

This security issue could occur unless the authorization server can detect whether the client credential presented at the introspection endpoint belongs to a resource server. Therefore, it is crucial for the authorization server to distinguish between resource servers and normal client applications. If that is the case, it is not advisable to mix metadata about the resource server into client metadata.

FAPI 2 Message Signing should refrain from adopting the “JWT Response for OAuth Token Introspection” specification until the specification properly segregates the concepts of resource server and client application and makes the necessary modifications accordingly. At the very least, if metadata registration is necessary, the `introspection_signed_response_alg`, `introspection_encrypted_response_alg` and `introspection_encrypted_response_enc` metadata, which the “JWT Response for OAuth Token Introspection” specification attempts to register as client metadata, should be registered as resource server metadata.