Problem statement
When allowing a connection to use IdP-Initiated SSO flow (by selecting Accept Requests in the SAML Connection’s IdP-Initiated SSO tab), then IdP-Initiated flow works perfectly fine.
All this without applying any of the documented changes, like:
- Create a custom login route handler}
- Create the query string
- Changes to Lock configuration. The Lock is not invoked at all in our JS code; Only the
loginWithRedirect()from the Auth0 React SDK is used to trigger the redirect to the Auth0 Login UI.
Why does IdP-Initiated SSO work in the initial setup even though the above have not been followed?
Solution
What is possibly happening is that the IdP-Initiated flow is actually working and creating a valid session in the Auth0 layer. However, it is not doing this in the application layer. Please read about session layers here.
Not having a session at the application layer is to be expected because the OIDC protocol does not have a concept of IdP-Initiated. It is likely that the application is doing a Silent authentication attempt. Check if there is a second /authorize request with a prompt:none being performed. Find more about the silent authentication attempts in this link.
This /authorize request, with the silent authentication, can find a valid session at the auth0 layer and hence automatically log the user.
It is good that the app does not find the session and it retries to authorize silently. However, this approach will not always work as third-party cookie issues would reject silent authentication attempts.
The reason why such a scenario works is likely because the silent authentication attempt is done from within the custom domain. Doing requests using the custom domain will ensure that third-party cookies are never blocked between requests sharing the domain that was configured.
The workaround of a new handler in the docs takes into account that there may not be a Custom Domain feature in use. Hence, the silent auth attempt may fail. Please see the workaround.
Notice that the example is doing at the end of the code a “loginWithRedirect()”. This action will force a new /authorize request. The purpose of this “secondary” /authorize call is to create the session in the application layer. In the end, the behavior expected will be the same as performing a valid silent authentication.
So, for this case, it may not be needed to implement the extra handler for IdP-Initiated approach since there already is a custom domain that allows the third-party cookies. This allows the silent authentication to correctly authenticate the user without the need of having to invoke “loginWithRedirect” on the custom handler.