Do NOT forward login_hint to identity provider

Help
, ,
1

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.

image
image1025×581 154 KB

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?

2

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?

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

3

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.

5

Hi!
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
6

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.

7

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

1 Like
8

Glad to hear that @andreas.brustad!

9

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