Invalidate sso cookies

[flle]

Hi.
Is there any way to prevent the sso cookies from being set? Or is there a way to delete them? I want my users to only have a single session. Therefore I delete all refresh tokens previously issued if the user logs into a new device. It works surprisingly well. However, the old devices still have the sso cookie set on my auth0 domain wich means that they are de facto still logged in (since they can request a refresh token).

[James.Morrison]

Hey there @flle! If you have a newer tenant (year old or younger) you have SSO enabled by default, I can make a request to our team to see if they can disable it but I need your confirmation first to do so. From there I will need you to direct message me your tenant name that you would like to have the effect on. Thanks in advance!

[James.Morrison]

I just sent you an email @flle regarding this request. When you get a moment if you could please respond to the email I would be happy to proceed forward. Thank you.

[James.Morrison]

I wanted to follow up on this front @flle as two alternative solutions were brought up to me which doesn’t require us disabling the SSO flag on your tenants.

1. You could also leverage the /logout endpoint and or have the app clear the local_storage cookie relevant to your application. All /authorize requests could be passed with prompt=login. No local cookie after logout means no Auth0 session will be honored on the authentication server.
   Logout

2. Leverage a rule as previously mentioned by one of our engineers here:

@Carlos_Mostek

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

Both these solutions enable us to leave your SSO enabled just in case you want to use it at a later time vs disabling it all together. Please give this a look and let me know how you would like to proceed forward. Thank you.

[flle]

Thanks.

Regarding 1.:
Do you mean the SSO cookie? I think the SSO cookie is set on the auth domain it self. Like my-tenant.auth.com. I don’t think I can delete them since they are usually not accessible via JS to my knowledge.

I am actually having two apps. One is a SPA and another one is a mobile app. If a user wants to make use of the logout endpoint, he needs to be connected to the internet, wich is not always the case. If the user isn’t connected to the internet I would just delete the local tokens. However, if I just delete the local tokens the sso cookie is still set on the domain. So based on my understanding, the sso cookie shouldn’t be set in the first place.

Regarding 2:
I don’t understand yet how exactly recommendation two can help me.

[flle]

@James.Morrison so actually, my main objective is, that I want only one “active session”. Meaning that if I login in “Browser A” and after that in “Browser B”, “Browser A” shouldn’t be able to get new access tokens.
Since I can’t revoke SSO cookies to my knowledge, I thought that it’s the best to use refresh tokens and store them somehow at the server or what ever. But I don’t really like the overhead for such a simple and normal feature.

Sames goes for mobile, my phone got stolen a few months ago and I want to be able to remove it from my active device list in the application we are building. However, even if I remove the refresh token with the management api, it’s still possible to get one since the SSO cookie is set.

So if you have another solution to reach my goal I am happy to try it. After all those are basic security features I would say.

[flle]

@James.Morrison if there is no alternative solution that is solving my problem I would like you to disable SSO for the tenants I sent to you.

[James.Morrison]

I apologize for the delay in response.

@flle

so actually, my main objective is, that I want only one “active session”. Meaning that if I login in “Browser A” and after that in “Browser B”, “Browser A” shouldn’t be able to get new access tokens.
Since I can’t revoke SSO cookies to my knowledge, I thought that it’s the best to use refresh tokens and store them somehow at the server or what ever. But I don’t really like the overhead for such a simple and normal feature.

Sames goes for mobile, my phone got stolen a few months ago and I want to be able to remove it from my active device list in the application we are building. However, even if I remove the refresh token with the management api, it’s still possible to get one since the SSO cookie is set.

So if you have another solution to reach my goal I am happy to try it. After all those are basic security features I would say.

After diving deeper into this since your last response, this is not something that Auth0 offers out of the box. To move forward in this fashion you would have to custom build the solution within your application. However if you feel this is something you would like us to add in the future, please visit Auth0: Secure access for everyone. But not just anyone. and leave us your feedback on this front. Each suggestion is read by a person on our Product team help plot the path forward in our roadmaps.

So to follow up on the SSO Cookie front, this would not actually be a solution for this use case.

[flle]

NP. I will submit a feature request.

So to follow up on the SSO Cookie front, this would not actually be a solution for this use case.
So you mean that disabling SSO alone won’t solve the problem? If so, that’s not a problem for my solution.

I expected that I have to build a solution my self since I couldn’t find the functionality I was looking for. The strategy is the following: I will remove refresh tokens via the management api wich will technically log them out. On our backend, I will store information about when exactly we removed the last refresh token. Getting a new Access token with the refresh token won’t work since it got removed. All access tokens issued with that refresh tokens before the actual refresh token deletion will be handled as invalid tokens since the refresh token used to issue them got deleted by the backend. That way, I can enforce a single session. It also gives me ways to logout a user in case their phone got stolen. However, the whole idea only works if I disable SSO cookies to enforce user login every time so that they can’t just get new refresh tokens.