2

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?

mailman_73
  • 778
  • 12
  • 29

1 Answers1

1

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.

Jan Garaj
  • 25,598
  • 3
  • 38
  • 59
  • Thank you for the response. If I understand you correctly, we have to make a redirect to SSO when we start our app and then SSO decide what to do. It means that we can't make ajax request in the background to check if the user authorized or not. In this case, we can't refresh the user's expired session in the background. We always have to interrupt (sometimes or all the time) him in order to authorize him. – mailman_73 Dec 30 '19 at 07:07
  • @mailman_73 No, I recommend to study basic OIDC grant code flow (generally whole OIDC specification, but OIDC is just one SSO protocol from many). Redirect really depends on the app business logic. Some parts of the app may be available without any auth + usually OIDC libs are used and those are doing redirects. Also IdPs (e.g. Auth0, Keycloak, ...) have quite good documentation, that is also good starting point to understand it more deeply. – Jan Garaj Dec 30 '19 at 13:30