IdP-Initiated SAML Login

[adarnon]

Description

If I'm not wrong, the library currently does not support IdP-Initiated Logins through SAML. This is a flow that many enterprise customers require and I couldn't find a way around it with the library.

Reproduction

1. Set up a SAML connection with an IdP, e.g., Okta.
2. In Auth0, make sure to enable IdP-Initiated Login in the connection settings page.
3. Attempt to log in to your app by visiting the SSO URL. You will receive the following error:

state missing from the response

The library uses a cookie a0:state to prevent CSRF attacks. However, in IdP-initiated connections the cookie does not exist so the flow fails. There should be a way to ignore the missing cookie for connections that allow IdP-initiated login.

Environment

Please provide the following:

• Version of this library used: 0.16.0
• Version of the platform or framework used, if applicable: Next.js 10.0.5
• Other relevant versions (language, server software, OS, browser): Chrome 88
• Other modules/plugins/libraries that might be involved:

[adamjmcgrath]

Hi @adarnon - thanks for raising this issue.

This library implements OpenID Connect (OIDC) which does not support the concept of an IdP-Initiated flow

You should be able to configure a similar experience using silent authentication and seamless SSO though.

• login via some enterprise portal (will create session on auth0.com)
• Visit a page on your app that requires authentication
• the page redirects the user to auth0 to login (with prompt=none)
• user is logged in to auth0 so gets redirected back to the app, is logged in to the app and returned to the original page they were trying to visit
• the experience for the user will be visiting your app in a logged in state from the portal with no required interaction

[adarnon]

Thank you, that makes sense. How would you suggest creating a session on auth0.com through the enterprise portal? The SSO url https://MY_TENTANT/login/callback?connection=CONNECTION_ID just immediately redirects to /api/callback in my app.

[adamjmcgrath]

Hi @adarnon

login via some enterprise portal (will create session on auth0.com)

By this I mean, your login portal is a web app - have the user login to auth0.com on this web app - eg.

• user clicks login on portal app
• user is redirected to auth0.com to login
• user logs in and is returned to portal app
• user visits one of the apps from the portal
• user silently logs in to app via prompt=none and active session on auth0.com

[adamjmcgrath]

Hi @adarnon - I hope this answers your question - closing for now, feel free to ping me to reopen it if you want to discuss further

[adarnon]

@adamjmcgrath Hey, I'm not following the first steps, maybe I'm confused about the terminology.

Right now, my application uses nextjs-auth0 to handle user auth. If a user visits any page on my app, they are redirected to /api/login which initiates the login flow, and then they end up having an a0:session cookie that is authenticated with the relevant Auth0 client on auth0.

My users want to be able to log in from their IdP. So, for example, they would have "Adar's App" on their Okta dashboard, and clicking on it would directly log them into my app. If I add a SAML connection on Auth0 and connect it to my Auth0 Client, turn on universal login and home-realm discovery, and configure the SSO login URL on the Okta app, when the user tries to visit the app they'll get the error above - because they didn't initiate the session from /api/login and they don't have an a0:state cookie whose purpose, to my understanding, protects from CSRF.

When you say "user clicks login on portal app", do you mean in their SSO dashboard? If so, how would they be redirected to auth0.com to log in? Should I add another dedicated API route for IdP-initiated SSO under my web app?
Also, they don't have auth0.com logins. Their login goes through my custom domain (e.g., my-auth.mydomain.com), and the resulting session cookie is created under my app's domain.

[saqbach]

I know this is closed, but it's something we ran into and just wanted to say thank you @adamjmcgrath. With your instructions above we were able to get a workaround working for Okta that we're happy with. 🙏

[osdiab]

I am also confused like @adarnon was - my scenario is that I'm providing a service to an enterprise client who uses Okta, and they have their own portal for their applications. They want to be able to click on our app from there and get logged in immediately. When you say that the user clicks log in on the portal app - I'm confused, since I don't own their portal app and I can't make my clients not use Okta. Would love some guidance for how I can make this flow work!