Disable SSO Session/Cookie entirely

Help
, , ,
1

Hi all

Just a quick question regarding the session/cookie Auth0 keeps when using sso.
Is it possible to disable it entirely? I know you can clear it by redirecting your users to the logout page, but this will not do for me.

A bit of context to understand why I need this.

The application I’m working on is a multi-tenanted app, meaning if you’d be able to go to https//myapp.com/myTenant you should not be able to go to https//myapp.com/yourTenant
Now when a user logs in in Auth0 successfully (we’re working with a different connection per tenant to make sure a user only successfully authenticates with the correct tenant) a cookie will be set. If a user now tries to login in a different tenant, Auth0 will find a cookie and authenticate the user even though it’s a different connection this time.

What I’ve tried:

  • adding prompt=login to the login URL, this is however unreliable (also not a good UX, don’t want user to logged out in there Idp, just in Auth0)
  • logging the user out in Auth0 after login in in our app ( I know right :smile: ) but that created issues with allowed redirect URL because we have redirect URL’s after login (for example go directly to a specific page based on whatever variable after login), and I can’t possibly white-list all those 100+ in the Auth0 dashboard
  • Decreasing session timeout to the lowest value ( apparently 1 minute) but this is still enough time to get authenticated for the wrong tenant.

Sorry for my rambling :wink: Is my issue clear?
Let me know if I need to provide more info.

Thanks in advance!
Jinse

2

Your rules will run even if you have an SSO session. If a user from Tenant A is not allowed to log into Tenant B, then you should create either a rule to reject that request as unauthorized, or just have the application itself reject that user’s login attempt.

If the user is allowed to log into both tenants, then I don’t understand why it would be an issue to have their SSO session used to “authenticate” them.

If you truly want separation, then you may want to simply create a different auth0 tenant for each of your tenants. This will give you complete separation. If the identity is related to your underlying tenant, then this makes sense because their authentication should be against a domain that is consistent with their tenant.

You may find that you are going to have a painful time isolating down to the specific tenant database on the login page. One other thing you could do is have a separate client per tenant. This can work for you if you always know which tenant you are logging into before you go to auth0 to log them in. If that is the case, then you could use a separate client ID per tenant, and then you can simply enable the database associated with the tenant for their client. This will prevent SSO from working between clients if the database for the SSO cookie is not enabled for that other tenant.

1 Like
3

Hi Carlos

Thanks a lot for your answer.

A little bit more background story on our users. Our application doesn’t necessarily need to know the user being authenticated by Auth0. Any user that can authenticate with the Idp of one of our tenants can log in in our app. The user will be created afterwards. This means I can’t use rules (I think, correct me if I’m wrong) because I don’t know anything about a user when I redirect him to Auth0. The only thing I always know is the tenant where the user is trying to log in to. So we’re relying on Auth0 to determine if a user can log in to a specific tenant. This is working great when they first log in, but the session messes with that.

If I could be using rules for this, could you guide my in the correct direction?
For now I got it working to redirect the user back to the Auth0 logout after logging in (thus clearing the session) but it makes me shudder every time I see this piece of code :wink:

Creating a different Auth0 client per tenant is a good suggestion I think, but I’d rather fixed it with one client if I have the option. I’m using asp.net OWIN and that framework isn’t really build for multiple clients.

In any case I’ll try out this solution to see if it works at all, but let me know if I could achieve a solution without it :wink:

Thanks a lot!
Jinse

4

After some time messing around with it, I was unable to get it working with different auth0 clients :frowning:
So I’m still hoping that you could provide me a solid solution.

Thanks
Jinse

5

Sorry for the delayed response. Haven’t been able to check community lately.

Rules run after authentication, so if you know which user is associated with which tenant, then you should be able to do something like this:

  1. User goes to your page https://myapp.com/myTenant
  2. https://myapp.com/myTenant redirects to /authorize?redirect_uri=https://myapp.com/myTenant/callback
  3. User enters their credentials on the login page (or they are automatically authenticated using the SSO cookie)
  4. Auth0 validates the credentials and executes rules
  5. The rule checks whether the user is allowed access to https://myapp.com/myTenant/callback
  6. if so, they proceed as normal
  7. if not, the rule rejects them with an UnauthorizedError

NOTE: if you aren’t using a different callback per user, then either the callback can do the check, or you could pass a special scope to the /authorize page to define the tenant, such as tenant:myTenant