Wrong grant used when already logged in

[jasperh]

We’re using hosted pages and the implicit grand. This means that the following flow works as expected:

• User enters our site
• We fire WebAuth.login()
• User gets redirected to Auth0
• User logs in at Auth0
• User gets redirected back to our site (on: domain.com/login#access_token=token)
• We call WebAuth.parseHash() to ensure the user is properly logged in

When a user returns to Auth0 manually from this point (using the back-button for example), it gets presented with a UI that shows the user is already logged in. When the user confirms this by clicking on the large button it gets redirected back to us.

The problem here is that it doesn’t get redirected to domain.com/login#access_token=token, but to domain.com/login?code=code. Reading this comment I’d say this has something to do with the wrong grant being used.

The end result is that parseHash fails, redirecting the user back to Auth0 again. The same UI is shown, but when a user confirms it again it does redirect the user to the correct callback url.

Why would this be different for this particular flow? Did we miss configuration anywhere, or is this a bug?

[nicolas_sabena]

Hi @jasperh.
This is an unfortunate consequence of not supporting the Back button to land in the hosted login page. When pressing the back button, the login page can’t find the previous state initiated by the application (where the grant type requested, among other things, is stored).

For compatibility reasons Auth0 still tries to send a response with the default code result, but other than a few legacy corner cases this is really not very useful as a response (most applications would reject this anyway because the state is missing and the CSRF validation would fail).

Improving the handling of the back button when landing on the hosted login page is under the radar, but can’t provide any meaningful ETA at this moment.