The IdP is an enterprise SAMLP connection for a third party IdP-initiated SSO to our SPA, which then accesses our API. Because it is IdP-initiated to the SPA, there is no audience, so an opaque access token is returned. I want a JWT access token for our API, and we are using auth0-js, so I followed the advice in other posts by initializing WebAuth with audience set to my-api, and calling checkSession after parseHash.
The problem is that in development, my SPA is at localhost, so the consent_required error is returned despite being a first party app. I don’t believe this would be a problem in other environments since I wouldn’t be using localhost. I would probably be ok if developers are prompted for consent locally rather than having to now have everyone set up a hosts file and change all configuration. But how? I am not the IdP in this scenario, so who is responsible for prompting for consent? I expected auth0-js to redirect to its own consent page, but perhaps it does not due to the user being from enterprise connection. How do I handle it?
Thanks,
Jeremy
1 Like
Hi Jeremy.
The consent, in this case, is asked by Auth0 to the user (“Can {the application} access your resources at {the API}?”).
checkSession is a handy feature to try to silently obtain a token from Auth0, used mostly to get a refreshed token for an SPA. It uses an /authorize request (a token request) with two distinct features:
- the
/authorize request happens in a hidden IFRAME to avoid disrupting the SPA state (no page reloads)
- it includes an
prompt=none parameter, which in the OAuth2 protocol means “Do not show any UI to the user” (because the request will happen in a hidden IFRAME, so the user couldn’t possible handle any required interaction).
The “Do not show any UI to the user” means that the application should be prepared for failure: it could be that the user needs to re-authenticate again (the session has expired), that they need to take an MFA challenge or, as in your case, a consent prompt needs to be approved.
If checkSession fails, then you should make an interactive token request (i.e. /authorize, or authorize() in Auth0.js). This is a full redirection, where any required interactive UI will be presented to the user. If you don’t mind the full page reload, you can do a full authorize() request when handling this IdP-Initiated situation.
My recommendation for IdP-Initiated flows handling is to ditch the response completely and start a fresh authentication request directly (the /authorize request). You can configure the IdP-Initiated tab in the connection to use a different callback path by configuring the query string (i.e. redirect_uri=https://myapp.com/login) and, in the /login route of your app, don’t even try the parseHash and simply force a regular /authorize request.
Hi Nicolas,
If I run authorize() after the idp-initiated SSO, it redirects me to auth0’s login page for my SP. I expected their session to already be active, since they just came in, and to just prompt for consent. If I specify the SAML connection to the authorize call, it redirects to the sign in at the SAML IdP instead of just prompting for consent.
Given that the user just completed SAML SSO, how do I just prompt for consent?
Thank you,
Jeremy
Do you have Enable Seamless SSO turned on in your tenant Advanced Settings? See Single Sign-On for details.
I don’t have this option under Log In Session Management or anywhere else I can find.
Hi @jeremyr. I tested this on my side today and got the same behavior you are getting. This is not a flow I use frequently so I now have doubts on whether this used to work or not. Apologies for the confusion, leading you to think that this should work.
I’m trying to get some confirmation on whether the current behavior is expected or if this is something that should be corrected. I’ll update this thread when I get more information.
I checked internally, and there is a bug report filed related to this, as the expectation is that the login prompt should not be required on an /authorize request once the session was established with an IdP-Initiated response.
I don’t have an ETA for this to be solved, nor a public way to check the status, but the good news is that this has already been reported and will be fixed.
Nicolas, it’s been 4 months since you found this in your bug tracker. Has it been resolved yet?
Hi @jeremyr. My sincere apologies on the delay. This case took some time to investigate and, at that time, I updated a couple of support cases and documentation but completely forgot to come back to this topic.
Anyway, this is what came out of my research: this behavior is intentional. The session created by an IdP-initiated flow is considered as a “lesser” session internally for security concerns, and thus the user is required to re-authenticate.
The IdP-initiated flow has some security flaws (read more at Configure SAML Identity Provider-Initiated Single Sign-On), hence these restrictions.
Once again, sorry for not coming back before.