OAuth2AuthenticationProviderUtils.accessToken not respecting token_type

[lacebal]

Describe the bug
OAuth2AuthorizationCodeAuthenticationProvider does not respect the generated OAuth2AccessToken.TokenType and set it always to Bearer.

The internal class method OAuth2AuthenticationProviderUtils.accessToken.accessToken used by OAuth2AuthorizationCodeAuthenticationProvider do not respect the TokenType generated by the OAuth2TokenGenerator even if this is creating an OAuth2AccessToken that contains a TokenType

Access token token_type field should be able to store custom values per spec:

• https://datatracker.ietf.org/doc/html/rfc6749#section-5.1
• https://datatracker.ietf.org/doc/html/rfc6749#section-7.1

To Reproduce

Create a custom generator that returns an OAuth2AccessToken with a custom TokenType

public class CustomGenerator implements OAuth2TokenGenerator<OAuth2AccessToken> {

    public CustomGenerator() {
    }

    @Override
    public OAuth2AccessToken generate(OAuth2TokenContext context) {
        if (!OAuth2TokenType.ACCESS_TOKEN.equals(context.getTokenType())) {            
            return null;
        }
        
        OAuth2AccessToken.TokenType tokenType = new OAuth2AccessToken.TokenType("custom-type");
		String tokenValue = "TEST"
		Instant issuedAt = Instant.now();
		Instant expiresAt = issuedAt.plus(1, HOUR);

        // Return JWT as OAuth2AccessToken with configured token type
        return new OAuth2AccessToken(
                tokenType,
                tokenValue,
                issuedAt,
                expiresAt
        );
    }
}

Setup the authorization server filter chain with the custom token generator

@Bean
@Order(1)
public SecurityFilterChain authorizationServerSecurityFilterChain(
		HttpSecurity http,				
) throws Exception {

	OAuth2AuthorizationServerConfigurer authorizationServerConfigurer =
			OAuth2AuthorizationServerConfigurer.authorizationServer();

	var tokenGenerator = new CustomGenerator();
	http
		.securityMatcher(authorizationServerConfigurer.getEndpointsMatcher())
		.with(authorizationServerConfigurer, (authorizationServer) ->
			authorizationServer
				.tokenGenerator(tokenGenerator)      // Configure custom token generator				
		)
		.authorizeHttpRequests((authorize) ->
			authorize.anyRequest().authenticated()
		)
		.exceptionHandling((exceptions) -> exceptions
			.defaultAuthenticationEntryPointFor(
				new LoginUrlAuthenticationEntryPoint("/login"),
				new MediaTypeRequestMatcher(MediaType.TEXT_HTML)
			)
		);

	return http.build();
}

Define the default security chain with login

@Bean 
@Order(2)
public SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http)
		throws Exception {
	http
		.authorizeHttpRequests((authorize) -> authorize
			.anyRequest().authenticated()
		)
		// Form login handles the redirect to the login page from the
		// authorization server filter chain
		.formLogin(Customizer.withDefaults());

	return http.build();
}

Expected behavior
The token sent to the caller and saved to the OAuth2AuthorizationService contains the custom TokenType

Sample

[jgrandja]

@lacebal The currently supported access token OAuth2AccessToken.TokenType are BEARER and DPOP. Custom access token types are not supported.

Please provide more details on the custom access token type that you are generating so I can understand your use case.

[lacebal]

Hi @jgrandja what I'm trying to accomplish is basically to to have support for the /token endpoint to deliver Personal Access Tokens (PAT) stored in the Auth Server (Custom development required to contact some Resource Servers). This simplify the integration as the client only needs to know about the OAuth2 flows and get the resulting Resource Server auth information. The context is MCP servers with their standard OAuth2 authorization mechanism whether the MCP Server upstream API does not understand OAuth2 flows.

So depending on some configuration the /token endpoint would return something like the following to the client (MCP Client).

{
	"token_type": "pat",
	"access_token": "<PAT>",
	"pat_header": "x-<custom-auth-header>",
	"pat_prefix": "Token"
}

The client would take the access token information to enrich the request depending on token_type. From previous example it would
enrich the request headers with:
x-<custom-auth-header>: Token <PAT>

For the standard Bearer token type it would do the standard Authorization: Bearer <access token>

So far I have accomplished the same with a regular Bearer access token with a custom claim pat that stores the relevant information. With this approach the client is required to decode the JWT token and I would argue is less "standard" even if what we are doing is exactly non-standard

[jgrandja]

@lacebal Are you using a custom OAuth2TokenGenerator to generate the PAT?

The default AuthenticationSuccessHandler for OAuth2TokenEndpointFilter is OAuth2AccessTokenResponseAuthenticationSuccessHandler, which provides a hook to customize the access token response via OAuth2AccessTokenResponseAuthenticationSuccessHandler.setAccessTokenResponseCustomizer(). You can change the token_type and add the additional parameters via this customization. Does that help? ... or do you prefer that OAuth2AuthenticationProviderUtils.accessToken() use the token_type from the passed in OAuth2Token ?

[lacebal]

Hi @jgrandja . Yes, I'm using a OAuth2TokenGenerator to generate the PAT inside a DelegatingOAuth2TokenGenerator.

Thanks for the suggestion but I already considered that approach. I discarded as there is a mismatch between the returned token and the stored token inside the OAuth2AuthorizationService so I find that solution not convincing to me.

[jgrandja]

@lacebal

there is a mismatch between the returned token and the stored token inside the OAuth2AuthorizationService

The returned token and the stored token should be OAuth2AccessToken so I'm not seeing any difference here? Can you clarify?

Either way, I would be open to enhancing OAuth2AuthenticationProviderUtils.accessToken() to use the token_type from the passed in OAuth2Token. This would be considered an enhancement and would need to be added in Spring Security (see gh-2195). Would you be interested in submitting a PR for this?