Follow RFC for self-contained JWT access token

[tnorimat]

RFC for self-contained JWT access token has been published.

RFC 9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Token

The current keycloak's access token (and refresh token) is self-contained JWT access token.
It might be good for keycloak's access token to follow this RFC. WDYT?

[stianst]

Do you know what the state of it is beyond "proposed standard"?

[tnorimat]

The next state is Internet Standard.

The standardization process of RFC in standard track is described by RFC 2026 The Internet Standards Process -- Revision 3 . It states that there are three maturity level, Proposed Standard, Draft Standard and Internet Standard at the highest maturity level.

Draft Standard is merged into Proposed Standard by RFC 6410 Reducing the Standards Track to Two Maturity Levels . The current characteristics of Proposed Standard is described by RFC 7127 Characterization of Proposed Standards .

Even if RFC 6749 The OAuth 2.0 Authorization Framework, its state is Proposed Standard.

[stianst]

If this specification gets real traction and not push-back I'm all for following this RFC, but would like to make sure it is on the road to becoming an official standard.

Wondering also a bit on how we could do it, and how much it conflicts with existing claims we have. A basic approach could just be to have a client-scope for it, which is for example what we did for the Microprofile JWT standard.

[tnorimat]

I've not yet investigate the difference between the current keycloak's access token and this RFC completely, but I've found the following points.

• JOSE header's "typ" field : RFC states that should be "application/at+jwt" or "at+jwt". The latter is recommended. The current keycloak access token set "JWT" to it.
• The fields for meaning group : RFC states that such the field's name should be "groups".
• The fields for meaning role: RFC states that such the field's name should be "roles".

[stianst]

Quite a few breaking changes, which obviously makes it harder to handle. The groups/roles can be solved by having different "RFC" compliant client scopes, while the typ may be harder.

[jbman]

Note: JSON Web Token RFC 5.2 states that default "typ" of a JSON web token should be "JWT", but Keycloak sets "Bearer", which is only meant to be used in the JSON response but not inside the JWT.
See https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L757

[lmm-git]

The RFC does also state that a client_id attribute is required. As far as I know it is not possible to add such an attribute to all clients beside of configuring a hardcoded claim for each client.

[tnorimat]

@stianst I see, IMO, we need not to follow this specification in a hurry. If it is needed in the future, we would resume this discussion.

[lmm-git]

Just stumbled on this discussion as we are currently looking for a standardized way to interpret access tokens and RFC 9068 seems to be the only standard documenting a layout, some attributes and verification steps so far. So maybe we could get the adoption going again?

[jstale]

Hi @stianst, is this now officially supported in v25? I saw a change merged that addresses access token type but didn't notice RFC mentioned in release notes.

[laurids]

Hi @tnorimat and @stianst.

According to rfc9068#section-2.1:

JWT access tokens MUST include this media type in the "typ" header parameter

It then says:

it is RECOMMENDED that the "application/" prefix be omitted. Therefore, the "typ" value used SHOULD be "at+jwt".

Therefore, it is not just a recommendation, but a requirement that the typ header is either application/at+jwt or at+jwt.
From these two choices, the recommended one is at+jwt.

There is already a switch in DefaultTokenManager.java#L239 on the token category to set a specific type for logout tokens.

Could we extend this with a case for the ACCESS category? There is already a constant defined for at+jwt in TokenUtil.java#L46.

I realize that this is a breaking change, but without such a change, Keycloak is not compatible with OAuth2 resource servers that verify the typ header according to rfc9068.
In case the ACCESS category is used for other types of tokens than OAuth2, is there any way to only do this for OAuth2 tokens? I would argue that such a solution could be done in a patch version, and not necessarily require a major version bump, but I understand if you think it should still be done in a major version.
I am looking forward to hearing your thoughts.