State not received anymore on "implicit grant"

Help
1

Please fill out the following to the best of your ability. Doing so will help out the troubleshooting process

  • What are you trying to achieve? What is the use case or idea behind it?
    Make our service work again, without changing anything

  • If this is caused by an SDK please mention the SDK along with the specific version number.
    No

  • Is this easily reproducible? If not, please explain.
    Yes

4 days ago, when we sent the login_url "“easymile-sitecc.eu.auth0.com/login” with:

  1. redirect_uri
  2. approval_prompt
  3. scope
  4. client
  5. response_type
  6. state

When you send us to our callback, we received the state, but not anymore (all our services stopped working at once, without touching anything on our side, so we guess that you changed something 4 days ago. ie 9 march)

We had to change our code to not check that anymore (Which is potentially a security issue)

  • If this is related to Lock / any SDK please share the SDK as well as lock initialization code or any code that is relevant.
    No

  • If this is an issue with an API please mention the endpoint you are trying to hit. Relevant code, and or a network trace, is really helpful when debugging such issues.

  • Environment-specific information (Which OS, Language Runtime + Version, Browser etc).

1 Like
3

@michael.bitard you mention that you performed a request to /login, but that is not correct. The expected endpoint to start an OIDC/OAuth 2.0 authentication/authorization request would be /authorize. If you’re calling /login directly you need to change this.

@cody.mcmichael if you’re also starting the transaction at /login and this is the reason you don’t have a valid state then you should also update your logic to not call that endpoint directly. If this is not the reason then you’ll need to provide additional information about how the request is started.

4

@jmangelo Thanks for your answer!

I’ll try that soon. In the meantime, can you tell me why this still works when I call /login? It should not, right?
I’m also curious to know what changed on auth0 side to stop sending back the state

5

I believe it works when Legacy Lock API toggle is enabled so that will likely change soon due to the April 1st migration. I don’t think the /login endpoint was ever documented as part of the Authentication API (https://auth0.com/docs/api/authentication); it exists and is externally visible due to /authorize also redirecting to it for some scenarios, but to my knowledge this was meant to be an internal endpoint so changes in behavior in that endpoint are okay given the assumption (which in reality does not hold as we’ve seen) that this would only have internal consumers.

6

Thanks for everything, it works like a charm!

8

The above code does not specify a state parameter so the authorization URL created will not include one; the latest versions of client SDK’s for web application require the presence of a state parameter and when used to start the transaction always generate a state. Given you’re using a utility method to create the authorization URL the library will not do this automatically.

You can continue to use that method and provide the state yourself, but then when parsing/validating the response you would also have to provide the same state value when calling parseHash (see https://github.com/auth0/auth0.js/blob/5c66a40a0f5f54e81d524bf1f7f79e8461362e0c/src/web-auth/index.js#L124).

1 Like
9

I’m having a similar issue as well.

I pass a URL parameter redirect_uri to the /authorize endpoint. The param value is URI encoded and includes it’s own parameter, login_type. I need this value on the customized hosted login page. Something stopped working 2 days ago. I noticed that /authorize is not redirecting to /login, and the redirect_uri parameter is not being passed to /login.

I’m not certain, but I don’t think /authorize used to redirect to /login, and I believe this is the issue.

Can someone please confirm? My login screen is now broken.

10

You should probably open this as a new topic (if you haven’t done so already) and also include an HTTP trace (HAR) that illustrates the situation.

12

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