Multiple Login Failures Causing User Frustration with LinkedIn Sign-In

[nelson2]

Hello,

I hope someone can help me.

I’ve had many log records with the following message because users (seemingly anxious) double or more click on the “Sign In” button when Linkedin asks for the username and password.

“You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn’t find your session. Try logging in again from the application and if the problem persists please contact the administrator.”

I’ve followed the recommendations from the following link Users occasionally see an error "You may have pressed the back button..." but I think it doesn’t work correctly when organizations are enabled, custom domain (auth.acme.com previously was https://acme.eu.auth0.com/) and Linkedin.

I’m aware that I should define Application Login URI in the application and in the tenant configuration the Tenant Login URI, but I don’t know what URL to enter since when using Organizations I must define the organization ID somewhere.

This is my configuration in Organizations:

Organization A - ID: org_QJYs… - URL: https://a.acme.com
Organization B - ID: org_2dv1… - URL: https://b.acme.com

When I enter any of the organization URLs, it logs me in correctly in case the user only clicks the sign-in button once.

It’s worth mentioning that when I enter, for example, https://a.acme.com, it redirects me to https://auth.acme.com/u/login?state=hKFo2SBmc2RtVExuc0MyQ1h… and from there it redirects me to the Linkedin page and I can log in correctly.

I’ve been thinking of using

https://{organization_name}.acme.com/login since it allows me in the section of Allowed Callback URLs and I also tried with http://acme.com/login?organization=org_4QM...&organization_name=a and with http://auth.acme.com/login?organization=org_4QM...&organization_name=a

What URL should I enter in Application Login URI?

Thank you very much!

[marcelina.barycka]

Hey there @nelson2 ,

The error often happens when a user bookmarks the login page (the LinkedIn login page, for example), and over time, when the state parameter is invalidated on our side (removed from the internal database), we lose the context of login.

How currently does your /authorize request look when a user initiates login from within your application? Does it contain organization and client id parameters? It would be helpful if you could paste it (after removing sensitive data).

[marcelina.barycka]

We also seem to have some gaps in our docs regarding Login URI and organization usage. Your idea of using:

@nelson2

https://{organization_name}.acme.com/login since it allows me in the section of Allowed Callback URLs

is very logical to me, but our docs on where the {organization_name} placeholder can be used don’t mention the Login URI.

Thus, I will try to learn more from our Organizations team and will update you soon.

[nelson2]

Hello @marcelina.barycka , thank you very much for responding!

I am aware that the most common use case that triggers this error is the expiration of the state variable when saving the URL in bookmarks, but this is not the case.

This happens when the person double-clicks the signin button when registering with Linkedin.

Regarding your question:

For example, I have the organization called “ocean,” which is a real client with the organization id: org_4QMnxxxxxxxxxxxx.

The tenant I am using is in production and with a custom domain:

• acme.eu.auth0.com changed to auth.acme.com.

Each client has a subdomain associated with it; in this case, it would be ocean.acme.com. I’m using Nextjs 14 with app router to serve as context.

This is the flow of requests when accessing ocean.acme.com:

Request URL: https://ocean.acme.com/
Request Method: GET
Status Code: 307 Temporary Redirect

Request URL: https://ocean.acme.com/api/auth/login?returnTo=/
Request Method: GET
Status Code: 302 Found

Request URL: https://auth.acme.com/authorize?client_id=Pe0Lb5br9lnxxxxxxxxxxlrwbX14spUX&scope=openid profile email&response_type=code&redirect_uri=https://ocean.acme.com/api/auth/callback&organization=org_4QMnixxxxxxxxxx&prompt=login&nonce=sZWd0Mnkj_PO48SlTk4gX1wb0xxxxxxxxxxK-rOFaY8&state=eyJyZXR1cm5UbyI6Imh0dHBzOi8vb2NlYW4ucGF0dHJuexxxxxxxxxx&code_challenge_method=S256&code_challenge=yqkIkOuHQiZHzfYFxe3W1nMPlcUL-KuQf-mW2Gxxxxx
Request Method: GET
Status Code: 302 Found

Request URL: https://auth.acme.com/u/login?state=hKFo2SA3Mk1TSnFrVjBhUEZZVExKUVNSZ0E5MEJwNTBrUUFmY6Fur3VuaXZlcnNhbC1sb2dpbqN0aWTZIEs4NG9rxxxxxxxxxxFFeXYyWXBVYXJkU0N2dGwtRW5Oo2NpZNkgUGUwTGI1YnI5bG5SdTQ5UUpGM0Z5bHJ3Yxxxxxxxxxx
Request Method: GET
Status Code: 200 OK

In this last stage, it shows me the following:

Once I click on advance with Linkedin, it redirects me to the Linkedin page where I must enter my username and password.

Which generates the following requests:

Request URL: https://auth.acme.com/u/login?state=hKFo2SBiZGl6dXhsclB0dnM0LWE2cUNwLVhaSnU0ZllCUnZSbKFur3VuaXZlcnNhbC1sb2dpbqN0aWTZIGl6TTVuQ2VMWXlHbkVLa1cxYW9MbTFrblZycVB6WUFKo2NpZNkgUGUwTGI1YnI5bG5SdTQ5UUpGM0Z5bHJ3Yxxxxxxxxxx
Request Method: POST
Status Code: 302 Found

Request URL: https://www.linkedin.com/oauth/v2/authorization?login_hint=&prompt=login&response_type=code&redirect_uri=https://auth.acme.com/login/callback&scope=email profile openid&state=3jCnyShh6d42Jnle5VzoRgxxxxxxxxxx&client_id=78k3xxxxxxxxxx
Request Method: GET
Status Code: 303 See Other

Request URL: https://www.linkedin.com/uas/login?session_redirect=/oauth/v2/login-success?app_id=215xxxxxx&auth_type=AC&flow={"state":"3jCnyShh6d42Jnle5VzoRgxxxxxxx","scope":"email+profile+openid","redirectUri":"https://auth.acme.com/login/callback","currentStage":"LOGIN_SUCCESS","appId":21xxxxxx,"authorizationType":"OAUTH2_AUTHORIZATION_CODE","currentSubStage":0,"authFlowName":"generic-permission-list","creationTime":1715595371954}&fromSignIn=1&trk=oauth&cancel_redirect=/oauth/v2/login-cancel?app_id=215xxxxxx&auth_type=AC&flow={"state":"3jCnyShh6d42Jnle5VzoRgxxxxxxxxxx","scope":"email+profile+openid","redirectUri":"https://auth.acme.com/login/callback","currentStage":"LOGIN_SUCCESS","appId":215xxxxxx,"authorizationType":"OAUTH2_AUTHORIZATION_CODE","currentSubStage":0,"authFlowName":"generic-permission-list","creationTime":1715595371954}
Request Method: GET
Status Code: 200 OK

After this stage, I have already been redirected and authenticated to https://ocean.acme.com without problems.

I also have the HAR file with this entire flow. If you need it, I can send it to you via private message if you find it convenient.

Thanks you!

[nelson2]

This has been one of my major problems because currently, I can’t enter a URL in the Application Login URI since I must identify which organization it comes from. I don’t have a generic URL; for example, https://acme.com/login, all of them are https://client-name.acme.com/login.

As a company, we are aware that there isn’t much we can do with the LinkedIn UI to prevent the request from being resent multiple times when entering the username and password.

And we can only redirect to the login page after the error to try again. But currently, I don’t have a way to redirect them to the login page of their own organization.

I hope you can help me since we have several people asking us about the same thing every day.

Thank you very much! @marcelina.barycka

[marcelina.barycka]

Hey @nelson2 ,

Appreciate the detailed behavior description a lot! Let’s see what we can do.

I’m still waiting for internal feedback, but to the best of my knowledge, organizations don’t really get along with Application Login URI (organizations have been implemented later ).

My tentative thought is to have one common for the application login URL that further redirects to an organization (subdomain)-specific login flow. This would require logic for adding the client_id and organization parameters to the /authorize on behalf of the user (or asking a user for their organization in this specific use-case when they end up with the error).

Just a heads up for HAR file sharing - we have stopped accepting HAR files via the community for some time now.

Please let me know your thoughts or follow-up questions - I will also update you with internal insight once I receive it.

[nelson2]

Hello @marcelina.barycka , thank you very much for your response.

I will try the idea you suggest, but we have some doubts:

When you mention:

“My tentative thought is to have one common application login URL that further redirects to an organization (subdomain)-specific login flow.”

If we create, for example, a common page for the Application Login URI, such as https://acme.com/login, how can I detect from which organization it originates? Does Auth0 add any headers or parameters to the URL entered in the Application Login URI to help detect the source?

For example, if I enter: https://acme.com/login, will Auth0 make a call to this URL with https://acme.com/login?organization=org_4QMnxxxxxxxxxxxx? Is this correct?

In reality, it would involve converting https://acme.com/login into a webhook to redirect depending on the parameters that arrive at that URL.

Lastly, in the case where I have the organization ID or the name of the organization, you mention that we need to construct the /authorize URL:

https://www.linkedin.com/oauth/v2/authorization?login_hint=&prompt=login&response_type=code&redirect_uri=https://auth.acme.com/login/callback&scope=email profile openid&state=3jCnyShh6d42Jnle5VzoRgxxxxxxxxxx&client_id=78k3xxxxxxxxxx

So, we would have the following parameters:

URL: https://www.linkedin.com/oauth/v2/authorization

Params:

• login_hint:
• prompt: login
• response_type: code
• redirect_uri: https://auth.acme.com/login/callback (here I define my subdomain related to the client)
• scope: email profile openid
• state: 3jCnyShh6d42Jnle5VzoRgxxxxxxxxxx
• client_id: 78k3xxxxxxxxxx (I know this value doesn’t change as it is fixed)

My question is, where do I obtain the state?

And again, thank you very much for the help. We are launching a new feature and some users are unable to use the platform.

[nelson2]

Hello @marcelina.barycka

Any updates on this situation?

Also, could you help me address the questions in my last comment to generate a solution while the Auth0 team works on a more definitive solution?

I’ve submitted a ticket to the LinkedIn support team to disable the sign-in button once it’s been pressed, to prevent this issue from occurring in the first place.

Cheers.
Nelson.

[marcelina.barycka]

Hey there @nelson2 ,

Thank you for your patience - I’m still awaiting internal feedback.

In my previous message, I meant that this common Login URI should point to a route in the application that ends up redirecting to the Auth0’s /authorize request (in your case: https://auth.acme.com/authorize?client_id=Pe0L...) with the client_id (as in your Auth0 Applications → Application) and so on.

Auth0 also uses cookies and a set-cookie header to track the login flow (but please inspect it as it can vary depending on the implementation).

I’m not sure about this specific situation with the Linkedin users, but looking at our doc:

If you are using Organizations and the end-user bookmarks the organization login prompt, Auth0 also includes the organization parameter when it redirects the user to the default login route.

This would mean that when the login flow is reinvoked with this common Login URI scenario, you do not have to provide the organization parameter yourself. But again, this is not an officially supported solution, and you would have to test it extensively.

Also, I’m thinking out loud here: Even though the user would start the new login flow this way, they may again double-click the LinkedId Sign in button—and again and again.

Thus, maybe it would be better, in this specific case, to customize the error page returned with a relevant description so the user knows they need to avoid double-clicking the LinkedIn Sign-in button? What do you think?

[nelson2]

Hello @marcelina.barycka !

Thank you very much for the suggestions.

To be able to test the suggestions, I first need to redirect users to a personalized page using what you suggest about “Custom error pages”, as this is where I can redirect users to the flow of “https://auth.acme.com/authorize?client_id=xxxx” depending on their organization.

My error page is: https://auth.linkedin.acme.com/error

But unfortunately, when users are redirected to that page, the URL parameters do not contain any relevant information.

https://auth.linkedin.acme.com/error?client_id=&connection=&lang=en&error=invalid_request&error_description=You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn’t find your session. Try logging in again from the application and if the problem persists please contact the administrator.&tracking=e40e9ddxxxxx355a2bd

I tried checking the headers and cookies, but I still can’t find anything that tells me which organization it belongs to.

The referer is Linkedin.com, so I have no way of knowing where it comes from.

Even though I can redirect people to an error page, I have no way of building the URL in https://auth.acme.com/authorize?client_id=xxxx

So I have reached a dead end that only depends on Auth0.

I feel that this feature of being able to redirect a user in case of login error is essential for the proper functioning of organizations.

And this was LinkedIn’s response; they clearly aren’t going to do anything on their end. It is basic functionality to be able to disable the login button once it has been pressed.

Honestly, I don’t want to migrate to another authentication provider, but if I can’t find a solution to this problem, I will have no other option.

Thank you for your time and I hope you can help me solve this problem.

[marcelina.barycka]

Hi @nelson2,

I wouldn’t be that pessimistic about LinkedIn support

To reiterate what options we have on our side:

Custom error page: The customization will allow you to adjust the value of the error_description variable for this specific error code via the Management API call to make it more informative, like:

“Hey, among other possible reasons, the error you see is probably caused by you clicking the Sign-Up button on the Liked In login widget more than once. After submitting your credentials and clicking “Sign in” there, please give it a few seconds to proceed.”
On this error page, the flow ends with no further redirection.

---

Setting the common Login URI for the client application. I will try to be more specific here:

The Login URI must redirect to our /authorize endpoint along with the client_id and other required parameters like organization. When Auth0 calls this Login URI, Auth0 automatically adds the organization name and organization id parameters to it, so you don’t need to know what organization the flow has initiated from. Instead, when constructing the /authorize call, make use of these added by Auth0 to the Login URI params to:
1.define the organization param of the /authorize call,
2.define the redirect_to param of the /authorize.

For the second one, the general idea is:
Get organization name from query param > build organization specific callback URL with organization name > specify that redirect_uri in login request options.

[nelson2]

Hello @marcelina.barycka ,

I tested the two situations you mentioned:

1. I created a custom error page and it works quite well, although it depends on the user clicking on the organization they need to enter. It’s not ideal, but for now, it serves its purpose.

2. I tried again to generate an Application Login URI.

   • Before starting, I deactivated the custom error page.

   I created a public page on my end called https://auth.linkedin.acme.com/login, which captures all the URL parameters. This way, I can better visualize which parameters are being redirected by Auth0.

Unfortunately, when I configure the Application Login URL, it has no effect as it redirects to the usual error page (https://auth.acme.com/login/callback?) and not to the page https://auth.linkedin.acme.com/login.

Therefore, I couldn’t test which parameters are requested by the page at https://auth.linkedin.acme.com/login.

I also tried configuring the URI at the tenant level and it had no effect. I tried the combination of having the URI activated in both the application and the tenant, only in the tenant, and only in the application. In all cases, it still redirected to https://auth.acme.com/login/callback.

We will stick with the error page until we can decide what to do about this situation.

Again, thank you very much @marcelina.barycka for all the help and for guiding me to try new ideas.

Cheers.
Nelson.

[nelson2]

Hello @marcelina.barycka ,

Is there any internal update on how to use Login URI when the organizations feature is enabled?

Thanks
Nelson.

[nelson2]

Hi @marcelina.barycka , how are you doing?
Do you have any updates on this situation within the organizations?

Cheers
Nelson.