Spring-security: Add OAuth2AuthorizationRequestResolver

[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 Authorization Request URI build process in order to add custom query 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

---

Okta

idp: The Identity provider used to do the authentication.

This parameter instructs Okta to either use itself as the Identity Provider or to use another identity provider connected to the Okta Authorization Server.

---

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

[jgrandja]

@andersonkyle Makes sense. We'll aim to add this for 5.1

[jgrandja]

@andersonkyle I'm finally circling back to address this requirement.

The simplest solution to allow for custom authorization request parameters would be to allow the user to provide the request parameters via the ClientRegistration configuration.

For example, if you would like to provide the audience and idp in the Authorization Request, you would configure it as follows:

spring:
  security:
    oauth2:
      client:
        registration:
          okta:
            client-id: client-id
            client-secret: secret
        ...
        ...
        provider:
          okta:
            authorization-uri: https://tenant1.okta.com/oauth2/v2/auth?audience=resource1&idp=https://provider2.com
       ...
       ...

We would ensure that any request parameters supplied in the authorization-uri are preserved when building the Authorization Request.

Would this strategy meet your requirement?

[andersonkyle]

Yeah, that should do the trick. Thanks!

The same flexibility is needed for the token request:

{
    "grant_type":"http://auth0.com/oauth/grant-type/password-realm",
    "username": "[email protected]",
    "password": "password",
    "realm": "UserDatabase5",
    "audience": "https://api.example.com",
    "scope": "openid email profile",
    "client_id": "1234",
    "client_secret": "5678"
}

^ the above example POST /oauth/token body for a Resource Owner Password Credentials grant includes 2 additional parameters: audience, realm as well as a custom value for grant_type.

This may be worthy of a separate ticket but thought I'd mention it while you're looking at this.

Both of these improvements will make working with 3rd party providers (who love to add functionality on top of the spec) much easier!

[jgrandja]

@andersonkyle Yes, please add a new ticket for the custom token request parameters. I'll keep this in mind.

[andersonkyle]

@jgrandja Thought about the proposal a little more and while it works for simple use cases, it doesn't allow the values to be dynamic.

Here's an example:

A Client has access to multiple identity providers (Active Directory, Google and Okta's Universal Directory). The additional idp parameter allows a Client to switch between them dynamically. If we bake it into the properties file it essentially becomes static.

Perhaps a callback mechanism would work a little better?

[jgrandja]

@andersonkyle Ok. I'll ensure a hook is provided that will allow for dynamic parameters.

[thiagotgo90]

Hi,

Maybe I shouldn't be using Security OAauth to do this (as the API say that they use a "variant of OAuth2") but:

I'm trying to use the Pocket API and they request just requires the "consumer_key" and "redirect_url" to get the token.

As pointed out by @andersonkyle would be good to customize the URI and add parameters, but also remove unnecessary. When I'm creating a ClientRegistration the builder forces me to set some parameters that are not mandatory to this specific API.

If I did not provide enough information, please just let me know.
Tks

[jgrandja]

@andersonkyle This feature has been merged. Take a look at the following tests for usage:

https://github.com/spring-projects/spring-security/blob/779597af2a6ed777707f08ae8106818e0b8e299e/oauth2/oauth2-client/src/test/java/org/springframework/security/oauth2/client/web/OAuth2AuthorizationRequestRedirectFilterTests.java#L306

https://github.com/spring-projects/spring-security/blob/779597af2a6ed777707f08ae8106818e0b8e299e/oauth2/oauth2-client/src/test/java/org/springframework/security/oauth2/client/web/OAuth2AuthorizationRequestRedirectFilterTests.java#L337

Also, I'm planning on merging #5521 shortly as this is required in order to configure a custom OAuth2AuthorizationRequestResolver.

Please let me know how this goes and if it suits your requirements.

[andersonkyle]

@jgrandja This looks great. This additional flexibility makes it simple to satisfy any OAuth provider's specific requirements. 👍

[jgrandja]

Yeah I'm pretty happy how it turned out. The OAuth2AuthorizationRequestResolver is simple yet provides the flexibility to fulfill various use cases.

[rwinch]

@jgrandja @andersonkyle I put some polish on this code to remove a tangle. See 938dbbf