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!