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).
@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.
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
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.
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.
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.