Support Custom Parameters within OAuth Token Request

[andersonkyle]

Summary

When using a 3rd party OAuth provider such as Auth0 or Okta it would be very useful to allow developers to hook into the Token Request build process in order to add custom parameters. This is because the providers mentioned above have added additional parameters on top of the specification to allow for more functionality.

Examples

---

Auth0

audience: The unique identifier of the target API you want to access.

This parameter impacts the format of the access token

realm: String value of the realm the user belongs.

This parameter instructs Auth0 to use a particular Identity Provider.

---

A simple hook into the building of the request should provide sufficient flexibility for these custom parameters and any others that are introduced in the future.

NOTE: In addition to the custom parameters mentioned above, some providers use custom headers to facilitate a token request. Auth0 uses an auth0-forwarded-for header for brute-force protection. This is mentioned in the documentation link above.

This issue is very similar to #4911 which focuses on the Authorization Request.

[mhyeon-lee]

facebook oauth2 supports a custom parameter called auth_type for reauthorizing users who have been denied permission.

https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow?locale=en#reaskperms

[jgrandja]

@mhyeon-lee It looks like the auth_type parameter is supported for the Authorization Request. However, this ticket is addressing the support for custom parameters in the Token Request.

Am I misunderstanding your comment?

[mhyeon-lee]

@jgrandja
You are right. I misunderstood. Thank you.

[jgrandja]

Related #5547

[jgrandja]

@andersonkyle I just submitted #5656 which should resolve this issue. When you have a moment please take a look at the PR and let me know if this will fulfill your use case.

The PR provides DefaultAuthorizationCodeTokenResponseClient and AbstractOAuth2AccessTokenResponseClient, which you can extend from and override the necessary methods. You have the ability to customize headers and/or request parameters and even modify the request completely. Also, you don't need to extend/override and can instead provide a new instance of RestOperations via AbstractOAuth2AccessTokenResponseClient.setRestOperations() and modify the outgoing request however you like using a ClientHttpRequestInterceptor.

I think this will give you the flexibility you need?

[andersonkyle]

@jgrandja Wonderful. This fits the bill nicely. Thanks again!

[jgrandja]

@andersonkyle PR #5656 has been re-worked a bit. However, it still provides the flexibility to customize the Access Token Request via DefaultAuthorizationCodeTokenResponseClient.setRequestEntityConverter(Converter<OAuth2AuthorizationCodeGrantRequest, RequestEntity<?>> requestEntityConverter).

This is now in master so please give it a try at your earliest convenience.

[jgrandja]

Close via 229b69d

[forgo]

@jgrandja

I am looking at the docs for what you previously described about OAuth2AccessTokenResponseClient. However, I'm having difficulty without an explicit example of how to extend the standard token request from OAuth2AuthorizationCodeGrantRequestEntityConverter

I tried to override this method by simply copying it from OAuth2AuthorizationCodeGrantRequestEntityConverter, but, for one, I am unable to import the OAuth2AuthorizationGrantRequestEntityUtils used in the original.

Furthermore, if I instead call super on the converter, I don't see a clear way in the documentation for modifying a RequestEntity body once it's already been formed. Any suggestions?

@Override
	public RequestEntity<?> convert(OAuth2AuthorizationCodeGrantRequest authorizationCodeGrantRequest) {
		ClientRegistration clientRegistration = authorizationCodeGrantRequest.getClientRegistration();

		HttpHeaders headers = OAuth2AuthorizationGrantRequestEntityUtils.getTokenRequestHeaders(clientRegistration);
		MultiValueMap<String, String> formParameters = this.buildFormParameters(authorizationCodeGrantRequest);
		URI uri = UriComponentsBuilder.fromUriString(clientRegistration.getProviderDetails().getTokenUri())
				.build()
				.toUri();

		return new RequestEntity<>(formParameters, headers, HttpMethod.POST, uri);
	}

UPDATE:

It appears I can accomplish this, but it seems a bit silly to have to deconstruct the RequestEntity body, headers, and url, change the params, then reconstruct a new RequestEntity. Surely this isn't the best approach?

        val originalRequestEntity = super.convert(authorizationCodeGrantRequest)
        val headers = originalRequestEntity?.headers
        @Suppress("UNCHECKED_CAST")
        val formParameters: MultiValueMap<String, String> = originalRequestEntity?.body as MultiValueMap<String, String>
        val uri = originalRequestEntity.url
        
        formParameters.add("client_assertion", jwt)
        formParameters.add("client_assertion_type", "urn:ietf:params:oauth:client-assertion-type:jwt-bearer")
        
        return RequestEntity(formParameters, headers, HttpMethod.POST, uri)

[jgrandja]

@forgo In order to customize the Token Request, you need to provide an implementation of Converter<OAuth2AuthorizationCodeGrantRequest, RequestEntity<?>> and set it via DefaultAuthorizationCodeTokenResponseClient.setRequestEntityConverter. Whether it's a new implementation or an extension of OAuth2AuthorizationCodeGrantRequestEntityConverter, it's your choice.

So your latest update is one way of doing that - extending OAuth2AuthorizationCodeGrantRequestEntityConverter. Based on your last comment, do you feel there is a more efficient way of doing this? If so, I'd be open to suggestions.

Also, just as a reminder, it's best not to comment on closed issues. If you have an issue/question please either search on Stack Overflow first and if you don't find the answer there log a new issue so we can track this better.