`TokenExchangeGrantRequest` sends an `OidcIdToken` subject token as `...:access_token`

[shin1488]

Describe the bug

TokenExchangeGrantRequest.tokenType() derives subject_token_type (and actor_token_type) from the Java type of the token:

private static String tokenType(OAuth2Token token) {
    return (token instanceof Jwt) ? JWT_TOKEN_TYPE_VALUE : ACCESS_TOKEN_TYPE_VALUE;
}

OidcIdToken and Jwt are siblings, not parent and child — both extend AbstractOAuth2Token:

// oauth2-core
public class OidcIdToken extends AbstractOAuth2Token implements IdTokenClaimAccessor { ... }

// oauth2-jose  (depends on oauth2-core)
public class Jwt extends AbstractOAuth2Token implements JwtClaimAccessor { ... }

An OidcIdToken is therefore an OAuth2Token but not a Jwt, so it takes the ACCESS_TOKEN_TYPE_VALUE branch. An ID token is labelled an access token, and there is no scenario in which that is the correct identifier.

RFC 8693 section 3 defines urn:ietf:params:oauth:token-type:access_token as indicating "an OAuth 2.0 access token issued by the given authorization server", and defines urn:ietf:params:oauth:token-type:id_token separately for an ID token.

This is not an oversight that a subclass would fix. OidcIdToken lives in oauth2-core and Jwt lives in oauth2-jose, which depends on oauth2-core; the dependency direction means OidcIdToken cannot extend Jwt. So instanceof Jwt has never been — and can never be — true for an ID token, even though an ID token is by definition a JWT.

The behaviour has been present since the grant was introduced in 6.3. The logic moved from TokenExchangeGrantRequestEntityConverter to TokenExchangeGrantRequest.defaultParameters() in 6.4; the method itself is unchanged. Confirmed on main.

To Reproduce

Public API only — no external project or custom resolver needed:

ClientRegistration registration = ClientRegistration.withRegistrationId("exchange")
        .clientId("client")
        .authorizationGrantType(AuthorizationGrantType.TOKEN_EXCHANGE)
        .tokenUri("https://example.com/oauth2/token")
        .build();

OidcIdToken idToken = OidcIdToken.withTokenValue("id-token").claim("sub", "user").build();

MultiValueMap<String, String> parameters =
        new DefaultOAuth2TokenRequestParametersConverter<TokenExchangeGrantRequest>()
                .convert(new TokenExchangeGrantRequest(registration, idToken, null));

parameters.getFirst("subject_token_type");
// -> "urn:ietf:params:oauth:token-type:access_token"

Expected behavior

subject_token_type should be urn:ietf:params:oauth:token-type:id_token.

How this is reached in practice

An OidcIdToken reaches the grant request through a custom subject token resolver — for example one returning oidcUser.getIdToken(). No Authentication shipped with Spring Security carries an OidcIdToken as its principal, so the default resolver never produces one.

That is the "Federated Identity" and "Backend-to-Backend with User Context" use cases raised in gh-19048 and acknowledged there as "solid use cases for id_token exchange" — in both, a Spring application is the client of the exchange and the subject token is an ID token. gh-19076 is implementing the server half now: an OidcIdTokenSubjectTokenResolver reading the IdP's JWKS URL from ClientSettings.idTokenJwkSetUrl(), whose first test scenario exchanges a valid ID token and expects an access token with the correct sub.

Relationship to #19436

#19436 asks that the RFC 8693 type identifiers be stated rather than inferred. That ask stands whatever happens here: no better mapping resolves any of its three defects — a mapping can only infer an identifier, and what is missing is the ability to state one.

This one is separable: gh-19436 stands without it, and a mapping change resolves this while leaving gh-19436's three defects untouched. And whatever resolver strategy eventually lands, tokenType() remains the default — an application that does not state an identifier still gets one from this method, and for an OidcIdToken it will still be wrong.

Mapping OidcIdToken to ...:id_token is not a behaviour change for anyone who is correct today, because labelling an ID token as an access token is never right.

I am happy to submit the PR.

[janderik]

OidcIdToken Misclassified as access_token Type

Summary: When returning an OidcIdToken through the token exchange/transfer mechanism, it is currently mapped to access_token type instead of id_token, violating RFC 8693.

Recommendation: Check instanceof OidcIdToken before instanceof Jwt and return the correct type identifier:

public String resolveTokenType(OAuth2Authorization authorization) {
    var token = authorization.getPrincipal();

    // CRITICAL: Check OidcIdToken BEFORE Jwt (since OidcIdToken extends Jwt)
    if (token instanceof OidcIdToken) {
        return "urn:ietf:params:oauth:token-type:id_token";
    }
    if (token instanceof Jwt) {
        // Generic JWT that isn't an ID token
        return "urn:ietf:params:oauth:token-type:access_token";
    }
    if (token instanceof OAuth2AccessToken) {
        return "urn:ietf:params:oauth:token-type:access_token";
    }
    if (token instanceof OAuth2RefreshToken) {
        return "urn:ietf:params:oauth:token-type:refresh_token";
    }
    // Default fallback
    return "urn:ietf:params:oauth:token-type:access_token";
}

References:

• RFC 8693 Section 3 defines the token type identifiers: access_token, id_token, and refresh_token. Returning an ID token with the access_token type is non-compliant.
• The class hierarchy (OidcIdToken extends AbstractOAuth2Token implements Serializable) means instanceof Jwt will also match OidcIdToken (via JwtAuthenticationToken), so ordering matters.
• Misclassifying an ID token as an access token may cause downstream relying parties to skip signature validation or apply incorrect claims policies.

[shin1488]

OidcIdToken does not extend Jwt — both extend AbstractOAuth2Token, in different modules (OidcIdToken in oauth2-core, Jwt in oauth2-jose, which depends on oauth2-core). instanceof Jwt is therefore never true for an OidcIdToken, and the fall-through reaches ...:access_token, not ...:jwt. Ordering is not the issue, and no ordering changes it.

The snippet is also from the other side of the exchange: OAuth2Authorization is an authorization server type in oauth2-authorization-server, representing an authorization issued by that server, and it has no getPrincipal(). The method here is TokenExchangeGrantRequest.tokenType(OAuth2Token) in oauth2-client, which builds the request a client sends.

Separately, the Jwt branch in that snippet returns ...:access_token, which is not the current behaviour (...:jwt). Whether that should change is gh-19436, not this issue.