How to implement cross-domain, auto-login SSO without browser redirects for unlogged users?

Question

I need to implement an SSO solution with the following requirements:

1. Cross-domain: Let's assume I have a.com, b.com and sso.com. If I become logged in through a.com, I shouldn't need to login when I visit b.com.
2. Centralized: Unlogged user clicking "Login" on a.com is shown a login screen hosted on sso.com. Credentials are checked by sso.com in data source only accessible to it.
3. Auto-login: If the user has logged in to a.com, and subsequently visits b.com, they will be immediately logged in. I.e., on b.com, instead of a "Login" link, we want to display right away their username, etc - without the need to click anything.
4. No redirect for anonymous users: Vast majority of my users will use the sites without having an account. Therefore, when they first come to a.com, or b.com, there must not be a quick redirect of the entire page to sso.com and back to check if they are logged in. Such a redirect would be bad for SEO and latency.

For the few users who have logged in to a.com and then go to b.com (or vice-versa), a redirect is acceptable.

There's a lot of examples on the web for SSO, especially with OAuth2, OpenID Connect, and CAS, but I could not find a recipe for these specific requirements. The closest is the Stackoverflow SSO guide (here), but they have some extra requirements I don't have (e.g. login should still work if SSO server is down).

Answer 1

It seems to me this OpenID Connect scheme should do it. Note though that I'm not a security expert, so don't use it without further confirmation.

1. User is unlogged to a.com, b.com, sso.com.
2. User goes to a.com, clicks "Login".
3. Redirect to sso.com, with return URL on a.com as param.
4. User provides valid credentials. sso.com accepts them, redirects to a.com with Authorization Code as param. There's also an SSO session cookie for sso.com on the redirect response.
5. Browser follows the redirect, queries a.com. a.com server sends Authorization Code to sso.com in backend, receives Access Token & ID Token, sets session cookie on a.com. User is now logged in on a.com.
6. User goes to b.com.
7. Javascript on b.com makes a silent CORS AJAX call to sso.com, to a custom endpoint (e.g. sso.com/has-sso-session). The endpoint responds with essentially true / false based on the presence of SSO cookie on the request.
8. If the response is:
   • true, Javascript redirects the browser to sso.com, with return URL on b.comas param. This triggers regular OpenID Connect authentication, which will be automatic because user has an SSO cookie. At the end of it, b.com server sends Authorization Code to sso.com in backend, receives Access Token & ID Token, sets session cookie on b.com. User is now logged in on b.com.
   • false, Javascript sets an SSO check failed session cookie on b.com. This prevents further checks when browsing b.com, unless the user clicks "Login".

Answer 2

The easiest and only way you can do SSO without any redirect at all is if all of your applications run on subdomains (a.site.com, b.site.com). Subdomains can share domain level cookies, so that your application will receive the login cookie right from the first request.

If you want your applications to be on multiple unrelated primary domains (a.com, b.com), the best you can do is to have a JavaScript that makes a cross domain request to the SSO service on page load to decide whether it should proceed to grab an access token. This won't affect SEO because spiders don't run JavaScript, and won't add latency for anonymous user either as the initial page load by unlogged user will render the anon version of the page.