After a successful authentication, a user can fail to authorize because their account is blocked or for various other reasons like an action.
When this happens the redirect url contains the error and state query parameters.
ex: ?error=unauthorized&error_description=user%20is%20blocked&state=Y0lWcndGcE9rbDVZdXl3M1BWbEFUOXZ5YnFkYmlXUjJNTHM2OE9Gc0lYTQ%3D%3D
Expected: The application at the URL redirect has an opportunity to handle these parameters and display a message saying why the login failed and what to do.
Actual: Because there is a token in the query parameter, Auth0 Angular redirects us to the base route / without even fully loading the page.
Questions:
Why does the url contain an empty token on a failure to authorize?
How can I show a message to the user saying they have been blocked if Auth0 Angular is automatically redirecting to the base route due to there being a state query parameter with an invalid token?
P.S. Sorry if the tags are wrong, there’s a limited selection and it requires 2 to post.
The state URL parameter its just a value being created during the initial step of the authorization process (by the client app) to ensure the requests happen between the same IdP and a client app (the client app expects the state value received in a response from the IdP to be the same as it’s initially generated).
How can I show a message to the user saying they have been blocked
This doc can put some light on it. Unfortunately, currently there is no way to adjust the flow. There is also some suggestion there for a workaround.
This topic refers to a similar problem.
The doc describes scenarios where Auth0 redirect to a default or custom error pages.
That’s all well and good… BUT Auth0 Angular SDK automatically redirects to the base route / whenever these query parameters are present on any route:
?code=abc123&state=abc123
To reiterate the issue:
If auth0/auth0-angular is instantiated in an Angular application at all, then any route with those query parameters will automatically route the page back to the base route as soon as it loads which is before any angular component can even be loaded.
Unless there is a way to exempt pages from getting redirected whenever the above query parameters are specified, this is an issue with Auth0 Angular itself.
If you need a stackblitz implemented with Auth0 to further understand the issue, I can provide that.
If you need me to instead open an issue on the github for Auth0 Angular, I can do that.
I saw here in the community some confusion around redirecting a user back to other than the root url destination after a successful authentication with auth0/auth0-angular.
If you intend to provide a specific URL to direct the user to after the login flow ends, the LoginWithRedirect method’s options serves it - AuthService | @auth0/auth0-angular.
As stated previously, this is specifically on a failed authentication. This actually redirects me to the custom error page URL you pointed me towards with your first response and not the url within login with redirect.
This happens to be the same page on our application, however even with the custom error page having the same url as specified in the loginWithRedirect, the application still redirect back to / if Auth0 is instantiated.
I will post to the Github in hopes they actually take the time to understand the issue instead of just responding with the best approximate documentation or existing issues.
Looking at the doc I shared on error / custom error pages, these are served when there is an error during the authentication, like incorrectly formed /authorization request / invalid callback URL or an expired login link in case of a Classic Login Page instead of correctly handled login rejection due to a user being blocked.
The specification I shared regarding setting a path for the callback URL root/what_comes_next was in case you decide to try the mentioned before workaround, just I see now the link has not been attached (basically it refers to not to block a user causing a login rejection but to use actions based on a usermetadata value).
But whenever you find the specification / docs are in contradiction to what you observe, reaching out directly to the repo owners seems to be most efficient way.