CODEWITHSUNDEEP
securitycookiesauthorizationsingle-sign-oncross-site
mailman_73
mailman_73

Reputation: 798

How should Single-Sign-On work if all browsers will prevent cross site tracking

more and more modern browsers prevent cross-site tracking by default. For example, Safari, Firefox, Brave, they all use 'prevent cross-site tracking' as a default option. I analyzed our users and found out that 6% of them prevent cross-site tracking and have issues with authorization and refreshing tokens. But I'm sure that the percentage will grow. According to the news, Safari will keep preventing tracking by default.

Maybe, it's a good thing to do, but it breaks the majority of Single-sign on implementations.

THE CASE

Assuming, we have a big international service that has one domain for one country: site.com, site.ae, site.ru, site.ca, .... And we have SSO service on sso.site.com that follows three rules:

  1. A user logs in the SSO domain once
  2. A user is authorized on all domains
  3. His session doesn't expire because we save him logged in as long as possible (until he signs out someday, of course).

SSO is awesome. It helps users. Users don't care about re-authorization. And it makes things easier for a company because there is only one authorization service. And you don't have to come up with another one for a new service.

How do modern SSO implementations (i.e. Auth0, stackauth e.t.c) achieve this?

They store tokens (access, refresh, JWT, doesn't matter) in cookies with the SSO domain sso.site.com. When a user opens site.ae or site.ca, for example, his user agent sends a request to the SSO, and the SSO checks his credentials stored in cookies, actualizes them (if necessary) and sends back the response, and then the app asks for user's data to another backend e.t.c.

THE PROBLEM

But it's not possible to do if user agents prevent cross-site cookies by default. Cause the SSO cookies won't be sent from another domain (i.e. site.ae) except for site.com since the SSO exists on sso.site.com

We may not use cookies in the near future. Yeah, we can use a chain of redirects though. Just imagine if you have hundreds of domains and ten milliseconds for each redirect! It slows the performance and user experience.

So my question is how can we login users and keep them authorized on many domains in the world when all browsers prevent cross-site tracking?

Upvotes: 2

Views: 1982

Answers (1)

Jan Garaj
Jan Garaj

Reputation: 28696

SSO protocols don't use cross site cookies usually. Typical use case for Open ID Connect (OIDC):

  • user has identity provider (IdP) session (usually cookies in the browser) after successful auth for IdP domain, e.g. sso.site.com
  • each OIDC application redirects unauthenticated user to the IdP login page and IdP redirects browser back (if IdP session exists or after successful user auth) with token/code (it depends on used flow) and then OIDC apps handle auth cookies/id token/access token/token refresh on their own on own domain

Similar approach with IdP session uses also SAML SSO protocol.

Upvotes: 1

Related Questions