Thank you Nicolas, that all makes sense and I appreciate the feedback and answers to my questions.
/authorize with prompt=login will force the login prompt. This is useful when the user clicks on something like “I’m not this person” or “Log in with a different account”.
A bit of feedback for Auth0 (not for you in particular): within our web SPAs we use (as you can imagine) auth0-js. We also force our users to have verified email addresses. So as I can imagine many Auth0 customers do, we have a simple custom rule that ensures users have a verified email address, and if not we return an ‘unauthorized error’ to the app via this custom rule. Because this ‘returns control’ to the application, our applications must recognize this problem (error) and, rather than providing a UI for this situation within each of our many apps, we instead have each app simply redirect the user back to our HLP, passing this error as a query param. So within our SPA app, that looks something like this:
// 'auth0' is declared above via auth0-js
function login () {
...
this.auth0.authorize({errorDesc: 'email_not_verified', prompt: 'login'});
}
It seems somewhat dissonant to require this ‘prompt’ param whenever the app ‘is sure’ it is time to take the user to our HLP. If any app forgets this extra parameter, the user will be in a ‘loop’ between our app & auth0, because though they have a valid SSO session, our custom rules will continually return an error (if/when the user’s email is not yet verified).
I guess I’m really complaining that an authentication that ‘fails’ because of a custom rule still creates an SSO session (now that ‘Enable seamless sso’ is the default for new tenants).