Security issue in the JWT Response for OAuth Token Introspection specification

[Takahiko Kawasaki]

One concern about the adoption of the “JWT Response for OAuth Token Introspection” 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). 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) 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.

[Takahiko Kawasaki]

If spec authors want to embed user claims in the introspection response, introspection needs to be defined as a top-level property of the value of the claims request parameter (OIDC Core 1.0 Section 5.5) like below.

{
  "id_token": {
    "given_name": {} 
  },
  "userinfo": {
    "given_name": {}
  },
  "introspection": {
    "given_name": {}
  }
}

And user consent on “embedding user claims in introspection responses” must be obtained during the authorization process.

I myself do not agree with the idea itself to embed user claims in introspection responses because (1) information about the access token itself and (2) information obtained by using the access token are different. (Relevant discussion → eKYC-IDA Issue 1175 created on Feb 25, 2020)

RFC 7662 (OAuth 2.0 Token Introspection) defines username as a property in the introspection response. However, I don’t think it is a good practice and I personally regard username is just an exceptional compromise. On the other hand, the sub property in the introspection response is not a compromise. It is necessary as a piece of information that associates the access token with the resource owner.

How many people have noticed that an example in the JWT Response for OAuth Token Introspection specification contains user claims such as birthdate, family_name and given_name like below?

{
  "iss":"https://as.example.com/",
  "aud":"https://rs.example.com/resource",
  "iat":1514797892,
  "token_introspection":
     {
        "active":true,
        "iss":"https://as.example.com/",
        "aud":"https://rs.example.com/resource",
        "iat":1514797822,
        "exp":1514797942,
        "client_id":"paiB2goo0a",
        "scope":"read write dolphin",
        "sub":"Z5O3upPC88QrAjx00dis",
        "birthdate":"1982-02-01",
        "given_name":"John",
        "family_name":"Doe",
        "jti":"t1FoCCaZd4Xv4ORJUWVUeTZfsKhW30CQCrWDDjwXy6w"
     }
}

The specification will practically make the introspection endpoint function as “the userinfo endpoint for resource servers.” Actually, it was the initial motivation of the development of the specification, if my memory works correctly.

If the introspection endpoint returns user claims even when the access token has not been granted the openid scope, and if normal client applications can access the introspection endpoint with their client credentials, client applications will be able to bypass the security requirements imposed on the userinfo endpoint by calling the introspection endpoint instead.

[Takahiko Kawasaki]

I was taught that the specification is on the RFC track and will not be changed…

[Brian Campbell]

Yeah, sorry for the very brief message at the end of the call. I was hoping we’d get to discuss. But, yes, the JWT Response for OAuth Token Introspection draft is currently in the RFC Editors' Publication Queue https://www.rfc-editor.org/cluster_info.php?cid=C444 so isn’t going to be changed. For better or worse considering the RS as a client in the context of doing Introspection is a pretty typical thing. draft-ietf-oauth-jwt-introspection-response does have specific metadata confiding it but regular introspection https://www.rfc-editor.org/rfc/rfc7662.html suggests it too.

‌

[Takahiko Kawasaki]

Years ago, I discussed "introspection endpoint caller authentication" directly with the author of RFC 7662. The agreed consensus was that although RFC 7662 uses the term "client authentication," it is not actually referring to "client authentication." RFC 7662 should have insisted on using the term "resource server authentication," even if it was cumbersome…

I'm worried that there might be implementations that allow a client application to introspect access tokens of other client applications because neither the Security Considerations nor the Privacy Considerations of the "JWT Response for OAuth Token Introspection" specification mention this pitfall.

[Daniel Fett]

Proposal to fix Issue #617

→ <<cset c59fba1ffb14>>

[Daniel Fett]

Re-opening because Bitbucket is stupid.

[Brian Campbell]

That does make some sense in retrospect @Takahiko Kawasaki . But note that RFC 7662 uses the term in text like, “the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749]” and “the protected resource uses a client identifier and client secret to authenticate itself to the introspection endpoint” which does strongly suggest that it is OAuth client auth and I think is part of why JWT Introspection Response treats the RS as a client the way it does.

‌

And more text RFC 7662 FWIW:

“protected resource uses OAuth 2.0 client credentials to authenticate to the introspection endpoint“

“commonly these credentials could take the form of any valid client authentication mechanism used with the token endpoint”

[Joseph Heenan]

PR is here: https://bitbucket.org/openid/fapi/pull-requests/431

[Nat Sakimura]

Merged in danielfett/fix-617 (pull request #431)

Proposal to fix Issue #617

Approved-by: Dima Postnikov Approved-by: Dave Tonge Approved-by: Takahiko Kawasaki Approved-by: Nat Sakimura

→ <<cset b3528ed2e887>>