Support OIDC login_hint for clients

[tnwang]

Summary

Support applications acting as clients providing their arbitrary values for OIDC login hint. This is passed along via the login_hint parameter during the OpenID Authentication Request.

It is standard to represent the user you want to use to login, but as per spec this can be customized for use by the identity provider (spec later mentions it as a string value parameter). As such, applications could be passing dynamic values (e.g. username provided by user to client, or in the case of UAA the application may choose to perform custom logic to determine which identity provider should be used).

http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

login_hint

OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.

[jgrandja]

Related #4911

[jgrandja]

Hi @tnwang. I'm currently looking at implementing this feature. This is what I'm thinking.

The simplest solution to allow for custom authentication 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 login_hint in the Authentication Request, you would configure it as follows:

spring:
  security:
    oauth2:
      client:
        registration:
          uaa:
            client-id: client-id
            client-secret: secret
	    ...
	    ...
        provider:
          uaa:
            authorization-uri: https://tenant1.uaa.com/oauth2/v2/auth?login_hint=thehint
	   ...
	   ...

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

Would this strategy meet your requirement?

[tnwang]

I think long term the use case of the login hint would be that applications collect information up front (the basic example given in OIDC spec is the username) so that the OIDC provider doesn't need to prompt for it again. With UAA, since we support multiple identity providers, an app may implement this for selecting among different identity providers (for example, I might have a Consumer Facing SAML provider vs. an Enterprise facing SAML provider, and the user is specifying whether they are a customer or an employee logging into a support app, where login hint helps the app use the right identity provider).

I'm not sure how flexible the login_hint parameter as part of the URI in the ClientRegistration is if we wanted to update the value later when making the per-user call out to the identity provider.

[jgrandja]

@tnwang Thanks for the detailed use case. This helps. And agreed a static login_hint provided in the authorization-uri would not suffice for your requirement. Let me give this some more thought.

[jgrandja]

Closed via 779597a

[jgrandja]

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

spring-security/oauth2/oauth2-client/src/test/java/org/springframework/security/oauth2/client/web/OAuth2AuthorizationRequestRedirectFilterTests.java

Line 306 in 779597a

public void doFilterWhenAuthorizationRequestAndAdditionalParametersProvidedThenAuthorizationRequestIncludesAdditionalParameters() throws Exception {

spring-security/oauth2/oauth2-client/src/test/java/org/springframework/security/oauth2/client/web/OAuth2AuthorizationRequestRedirectFilterTests.java

Line 337 in 779597a

public void doFilterWhenAuthorizationRequestAndCustomAuthorizationRequestUriSetThenCustomAuthorizationRequestUriUsed() throws Exception {

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.

[tnwang]

Looks good to me at a glance, especially the added ability for arbitrary request parameters. Looping in @aashah as well in case he has any thoughts.