Declining Access Permissions On Sign-Up Gets Sing-In Screen "Stuck" on the Permissions Grant Screen

Help
,
1

When I “Sign-Up” a new user from my Angular app, the new user is asked to Accept or Decline permission. If I “Accept”, all is well, and I’m routed to my application as expected.

If, however, I “Decline” the permissions, I’m routed back to my app in “NOT Logged in” state, as expected, but that’s where things stop working right. Every time I try to revisit the Login page to sign in or sign up as a different user, I’m presented with that same “Accept”/“Decline” screen for the PRIOR USER’s attempt to sign on.

Worse, this persists not only after closing the tab and opening a new one, but even closing the whole browser doesn’t clear it up. When the browser is re-opened, and an I navigate to the Auth0 Universal Login screen, I’m still presented with that “Accept/Decline” challenge from the previous user’s attempt to sign up.

Repeatedly "Decline"ing doesn’t help.

The only way out of this “stuck” state is to “Accept” the permission request on behalf of the prior user, which logs him into the app, then log out. After that, everything is normal.

Through all of this, I see no related errors in the Dev console, or anything else to hint at what might be wrong.

This is, of course, a catastrophic failure, and can’t be used this way.

Any idea what might be going on here?

3

Hi @bill.rebey,

Yes, the user’s session is persisting through every attempt to login until it expires.

There are a couple of options to work around this active session. The first option is to log the user out after they decline to grant permissions. You can call the /v2/logout endpoint for this.

Alternately, you can force the login page to load again by including the prompt=login query parameter. This will prompt the user to log in and provide credentials again regardless of an active session.

https://{yourDomain}/authorize?
    response_type=code&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope={scope}&
    audience={apiAudience}&
    state={state}&
  prompt=login

Thanks,
Rueben

4

Thanks, @rueben.tiow , for the feedback.

I think I like the first option the best, so that I can explicitly log the user out and clear the session when he declines access.

I see that my server gets a few callbacks from Auth0 when the “Decline” button is clicked.
The third one, though, look like the one that I’d want to recognize and react to with the “v2/logout” call that you mention above:

https://localhost:4201/?page=Contribute&error=access_denied&error_description=User%20did%20not%20authorize%20the%20request&state=NVRwWEt5a083ZUF2MlZsOW5DdUNXYl9qTDVsQzBDRklkemx6YlNvX1hBbw%3D%3D

Would that be best time/place to recognize the user’s denial of access and call the “v2/logout” Autho0 API, or is there a more appropriate workflow than that?

1 Like
5

Hi @bill.rebey,

Thanks for the follow-up.

Yes, the first option would work great for this case!

Yes, that would be a great point to call the /v2/logout endpoint. :clap:

Let me know if you have any additional questions.
Thanks,
Rueben

6

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