Akward/non-working sign out behaviour with domains and subdomains

[victornoel]

Describe the bug

When protecting both yyy.xxx.website.com and xxx.website.com, if I sign out via yyy.xxx.website.com/oauth2/sign_out, I can still access yyy.xxx.website.com.

It feels like it is related to the cookie of xxx.website.com which is not deleted during sign out.

To Reproduce Steps to reproduce the behavior:

1. Setup SSO to protect both yyy.xxx.website.com and xxx.website.com
2. Connect to xxx.website.com and sign in: a cookie is created for xxx.website.com
3. Connect to yyy.xxx.website.com: a cookie is created for yyy.xxx.website.com
4. Sign out from yyy.xxx.website.com via yyy.xxx.website.com/oauth2/sign_out and sign out
5. You are redirected to yyy.xxx.website.com and can still access it

Then: 6. Sign out from xxx.website.com via xxx.website.com/oauth2/sign_out and sign out 7. You are asked to sign in to continue accessing the sites as expected

Expected behavior

I should be signed out completely when signing out…

Additional context

Using latest release on kubernetes with the helm chart (https://github.com/helm/charts/pull/8157).

I had to set PROVIDER_URL_INTERNAL to the internal cluster-side address of the auth service.

[victornoel]

As a complement: if I delete all the cookies from SSO and sign in via yyy.xxx.website.com then directly sign out via yyy.xxx.website.com/oauth2/sign_out, I am properly signed out as expected.

[loganmeetsworld]

Thanks for filing this ticket. We will look into this behavior.

[jphines]

hey @victornoel -- thanks for opening this issue!

Context Overview

This is a complicated problem for us actually -- per your example,

It feels like it is related to the cookie of xxx.website.com which is not deleted during sign out.

This is correct. That cookie for xxxx.website.com is not deleted and on all modern browsers it's not possible for us to delete cookies for any other domain than originating request origin domain, i.e. yyy.xxx.website.com.

Why?

This is complicated by two core tenants of sso:

• sso uses only cookie sessions for state (we don't want to have to maintain stateful storage systems) so there is no global session state we can invalidate across domains on the server side.

• sso heavily caches and leverages configurable ttls to maintain session expiration windows so we don't overwhelm upstream identity providers. For instance, we don't want to check for a valid session state on every request that pass through the proxy, this might be tens-to-hundreds of requests for a single page view depending on the page architecture.

Mitigations

Fortunately, depending on your security risk and the amount of pressure you want to exert on your downstream identity provider, you could set these ttls to very low so this would work nearly as intended. For example, if you set your session state for 1s, if you signed out on yyy.xxx.website.com, your session state on xxx.website.com should also expire with one second, which would be invalidated, and the user should be triggered to sign in.

In practice, we haven't find setting our session state ttl's that low to be pratical for most security contexts. We've found 5-30m to be reasonable for us in most situations. This means that if you sign out on yyy.xxx.website.com it could take up to 5-30m to be signed out of xxx.website.com once your session expires on that domain.

In the future

We've discussed internally maintaining session state in a datastore that could be leveraged to store global session states and issue near immediate invalidations. This would then implement the behavior you are looking for -- @shrayolacrayon's work in https://github.com/buzzfeed/sso/pull/137 to consoliate our session store logic is a step in this direction.

Next up would be immplementing alternative session stores that leverage a datastore that we could feel comfortable exerting more request pressure for session validation checks.

[victornoel]

@jphines thanks a lot for this detailed answer, I will be following the work on the session store closely then :)

For now, I decided to use www.xxx.website.com and yyy.xxx.website.com so that they don't interfere with each other. My next step will be to redirect xxx.website.com to www.xxx.website.com in order to have a behaviour almost identical as my original need.

[adsodemelk]

I am facing a similar issue. I deployed sso on kubernetes following this great guide. I have not used the helm chart.

I am protecting xxx.website.com and yyy.website.com, zzz.website.com. xxx.website.com is essentially a web app that has links to all the services (yyy, zzz ) and a signout link to xxx.website.com/oauth2/sign_out.

If I sign out (GET into xxx.website.com/oauth2/sign_out) and sign in back again (xxx.website.com) when hitting into one of the other links (yyy.website.com) I get a 403 error (You're not authorized to view this page). If i refresh the page once again a new cookie is set and i can access the service yyy.website.com normally. Sometimes I can have a 500 rather than a 403. It feels like it is related to the cookies of yyy.website.com or zzz.website.com which are not deleted during sign out. Is this expected behaviour?

Thanks

[paddu2020-tcg]

Hi Team, I am facing this issue. How to resolve this issue. Please suggest.