Do NOT forward login_hint to identity provider

I have a requirement to customize the universal login page based on input from clients applications. As suggested here, I’m reusing the login_hint OIDC parameter to pass a value indicating how the login page should be rendered. As a result the value in login_hint is not an email address, but simply a number.
Unfortunately, the universal login page is forwarding the login_hint parameter to the identity provider. Since the value is not an email, the identity provider (Azure AD in my case) is confused.

I’m using the following code in the universal login page to redirect to the identity priovider:

var url = webAuth.client.buildAuthorizeUrl({
          connection: 'xxx-waad',
          state: state,
          login_hint : ''

If I populate login_hint with any value this is correctly passed on to the identity provider, but I have no value to pass on, so I would like to prevent login_hint from being passed at all or pass it with a blank value. However, if I set login_hint to empty string or null, the original value is passed instead.
How do I make sure login_hint is NOT passed?

Hey there @andreas.brustad! Have you experienced any success leveraging the Management API to set the upstream_params to null or set the login_hints to null?!/Connections/patch_connections_by_id

Please let me know if this helps or if you any other questions.

Thank you for your suggestion, @James.Morrison. Unfortunately, I have already tried this and the result is the same as if setting it pr request from auth0.js. If I configure the connection to pass any non-empty value, this value is forwarded to the identity provider as expected. However, if I pass null or empty string, the empty value is not passed along, but instead the login_hint value is copied from the request to the login-page and forwarded to the identity provider.

I’m afraid that’s not possible as of now. If the hosted login page flow (whether it’s Lock or Auth0.js) does not provide a new login_hint the server will pick up the one originally provided in the /authorize request from the application.
If you are getting an email address or user name from the user in the HLP you can use that value for the new login_hint to be sent upstream, otherwise it might be better to use a non-standard parameter instead to pass the message from the application to the HLP.

1 Like

Our best practice recommendations from Auth0 have been changed to discontinue using login_hint as a way to pass this data, and instead recommend doing a namespaced parameter.

e.g. mycompany_showsignup=1 or mycompany_initialscreen=signup

This will help avoid any conflicts with the appropriate use of those parameters.

Thanks to all of you for your help. I have changed my code accordingly and can confirm that it is working.

1 Like

Glad to hear that @andreas.brustad!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.