I confugured auth0 as IDP and use apache-Mellon as SP, and use Firefox as client.
I would like to demonstrate SSO flow.
after successful login to SP, I deleted mellon’s (my SP) cookie and tried to access SP again.
I expected that SP would redirect me to IDP, but IDP would recognize existing session and approve without asking user/password.
But IDP demanded login again.
Why? How can we debug this behavior?
thank you!
Hey there @vitalyk , welcome to the Community!
In general, cookies is one of the mechanisms that allows Auth0 to recognize that a specific browser’s or device’s user has already logged in with their IdP and has a valid session. No cookie means no designator for Auth0 = a need for a user to provide credentials again.
You can think of the case analogically to the following: A user is logged in to their Apache account via SSO on machine A and thus has a valid SSO session on the IdP and a valid auth cookie on machine A.
Later, the same user attempts to log in to their Apache account (while still having a valid SSO session on the IdP) on machine B, but instead of being automatically logged in, needs first to authenticate (it’s a different machine, no cookie there, that exists on machine A - no designator for auth0 that a person attempting to log in is the same person as on the device A).
Is your intent to not rely on cookies for SSO?
Hi,
Thank you for your reply!
I did not delete IDP cookie, it is still present.
I only deleted SP’s cookie…
IDP should have been able to recognize this session.
By the way, is here any mechanism that is not based on cookies?
Thanks,
Vitaly
Hey there @vitalyk !
Hmm, alright!
Are you aware of a cookie mechanism on the SP side allowing the user to browse through the content? There is a short doc here describing different mechanisms that determine the user login session (the native purpose of this doc was to describe what’s happening after blocking a user, but it would give you also a context for your use case).
Let’s also check the behavior following these steps:
(EDIT: After clearing the browsers cookies):
- Please log in to your SP on the Firefox,
- Open a new tab and, while having the browser developer tool (Network tab) open, please provide the SP URL (simply opening your app in a new tab)
- Please search for an authorization call.
What does this call look like? What cookie (if any) is attached to the request? Are you redirected to any login page? Did you have to provide credentials once more?
You can also repeat the steps after reopening the browser.
(One more thing I can think of is the federated log out (which means if you log out on the SP side, it would also log you out form the IdP side).
Please let us know your findings so we know more about what’s happening! 
Also feel free to ask if you have any other questions on the topic!
PS:
A refresh token rotation mechanism is available, but its purpose is to return a new access token (with SAML, IdP returns assertions). I need to investigate if a client app that is set to talk SAML can use this mechanism.
PS: Here is a short instruction on how to test the SAML SSO - Configure Auth0 as SAML Identity Provider
Just one thing to keep in mind is not to share here any sensitive data
thank you for your reply.
I configured our SP to have session expiration in 5 seconds.
It means that if i access the SP page 6 seconds after login, it should redirect me to IDP.
IDP has session expiration of 24 hours, therefore it should not ask username/password again.
I attached trace-saml screenshot to show what it going on.
we look at lines 3, 12 and 13
below is content of these GETs .
You may see that all cookies are same.
So the question is: why did we get User/Password prompt?
thank you in advance,
Vitaly
#3:
GET /samlp/J0rYDP03hzFxWou8B6ZQE6Km6Nj3vOOI?
sanitized (we avoid sharing here tenant domain / cookies / callback URLs / etc )
Hi @vitalyk - I am investigating it further (based on my so far investigation, we would have to take a closer look at the slo (single logout) property of the logout object in the SAML Protocol Settings as well as the OIDC backchannel logout property.)
I will update you soon!
there is following Addon in our configuration:
{
“logout”: {
“callback”: “http://xxx.raxxxxe.com/mellon/logout”,
“slo_enabled”: true
}
}
we dont use any OIDC. Only use SAML.
I can provide all details of our setup and send any captures if necessary.
Thank you!
Hi @vitalyk !
Thanks for sharing! - There is every indication that the slo_enabled set to true works this way: once the SP initiates the logout, the user is also logged out from the upstream IdP (Auth0 in your case).
(Thus you would learn more about the current behavior by tracing the SP’s log out, especially if you can see that after the SP receives the logout response, the response is also sent to the IdP so the session is terminated there as well )
In your SAML settings, please change the slo_enabled to false and verify if the flow is as intended. (And please let us know results!)
Single Log Out or SLO: Signing a user out of the upstream identity provider and any other applications they are signed in to. This is only available in the context of SAML interactions.
Feel free to ask follow-up questions if there are any!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.