CODEWITHSUNDEEP
cookiesdnssingle-sign-on
user1518048
user1518048

Reputation: 491

Automatic cookie single sign on on multiple domains - like google

I don't understand how google achieve the following mechanism of single sign on:

  1. I login in gmail for example (I suppose this creates a cookie withmy authorization)
  2. I open a new tab and direct type the url of "youtube"
  3. Then I enter youtube logged in.

How can this second site detect that I've already been logged in. They are different domains. Youtube can't read the cookie of Gmail.

All the solutions I've read about Single sign on don't allow this. The client always ask permission to a central login app. In my example YouTube doesn't know I am the same user logged in Gmail (actually it does know, but I don't understand how)

Note that I type the url of "youtube" by hand. I don't clic the youtube icon from the upper toolbar of gmail (In that case gmail may pass some auth params through the url for example).

Upvotes: 40

Views: 25531

Answers (5)

Hichem
Hichem

Reputation: 1182

The cookies are set on specific domains. Ex:

setcookie(name,value,expire,path,domain)

When you log in on gmail, before "mail.google.com", you have been redirected to "accounts.google.com" then to "mail.google.com" so the cookies are on "accounts.google.com" too.

In this case, the domain is "accounts.google.com" and the path is "/" (the home path).

When you request "www.youtube.com" then you click on "connection" it requests "accounts.google.com" fast so you can't see this redirection and checks if you have cookies on "accounts.google.com". If so, it checks if the cookies are valid and not expired, or user not banned... Then it redirects you to "www.youtube.com/signin?loginthisSession=Sessionid". This request contains the value of the of sessionid cookie catched from the cookies of "accounts.google.com".

In the last step, "www.youtube.com" logs you and set its own cookie on the domain "www.youtube.com" and saves them.

So the trick is on the 302 HTTP redirect.

Update

i do not know why people keep mentioning iframe take a look at the date whene this questions was posted on 2016 google was not using then iframe as i mentioned the capture of web traffic as you can see SetSID wich means set the cookie of SESSION_ID from accounts.google.dz(com) then redirects to youtube.com it can not be used trought iframe differant domains security measure you can not be redirected from domain to domain trought iframe neither please read this before posting

enter image description here

Upvotes: 23

Ng Sek Long
Ng Sek Long

Reputation: 4786

While evaluating this cross domain SSO topic, I have come up with possible a new SSO synchronization flow using cookie with timestamp. Although it is not a flow used by Google, I think this flow is possible to implement for system with limited number of domains.

This flow do not use 3rd party cookie

This is going to be a long post :)

domains

To make an example, let say we have these domains for our example pet forums:

Change to https://account.domain1.com:

Login Steps:

  1. User go to dog.domain2.com, user have not sign in yet.
  2. User click the Login button in dog.domain2.com
  3. User get redirect to account.domain1.com for login
  4. User Input username & password, login success
  5. New step, before redirect back to https://dog.domain2.com, set cookies on all domains
    1. Redirect browser to https://accounts.domain2.com?...
    2. Set a cookie on the .domains2.com domain (More on the cookie value later)
    3. Redirect browser to https://accounts.domain2.com?...
    4. Set a cookie on the .domains3.com domain
    5. Redirect browser to https://accounts.domain1.com?...
    6. Set a cookie on the .domains1.com domain
    7. Redirect back to original flow
  6. Redirect user back to their original service, i.e. https://dog.domain2.com

Now, right after login flow we have cookies over all 3 domains. Any of our service (e.g. https://cat.domain1.com / https://dog.domain2.com / https://rabbit.domain2.com ) can access this cookie under their own domain.

Cookie Content

  • The content of the cookie, should allows for any webpage to look at it, and determine if SSO sync is needed
  • Different types of cookie content can be stored, including
    • Boolean indicate user logined or not
    • User ID
    • Expired At timestamp

Boolean indicate user logined or not

User ID

  • While it is tempting to just stored the user_id on those cookie, and let all the domain to see them and set the user accordingly.
    • This is way too dangerous, since the cookie is set at the parent domain,
    • if any of the website under your domain been hacked, impersonation might happen (Copying any of the user_id, pasting it to their own browser cookie).

Expired At Timestamp

  • What I suggest, is for the cookie value to set as the SSO expired time, and set the type as session cookie, this have the following benefits:
    • An expired time have minimal security impact if leaked / altered
    • Our website can check the expired time to know if user need to relogin
    • As for why session cookie, is for when user close them browser, and tried to login again, the cookie will be deleted hence logout the user as well
  • Any webpage that use the SSO, should also stored a cookie themselves with the same expired time
    • There will be cases that, User A Login, visit https://cat.domains1.com Then User B Login
    • Since User A and User B will have a different login expired time, storing and compare that timestamp will tell the user to sync with SSO again

Example checking implement for your service

E.g. On https://cat.domains1.com, you can add this to the top of your page load

<?php
$sso_expired_time = $_COOKIE["sso_expired_time "] ?? 0;
$website_expired_time = $_COOKIE["website_expired_time "] ?? 0;

if( (int) $sso_expired_time  < time() || $sso_expired_time  !== $website_expired_time ) {
    // User not sync, perform sync
    setcookie("website_expired_time", $website_expired_time,0,"/", $_SERVER['SERVER_NAME'], true, true);
    // Redirect to https://account.domain1.com for Login
    // Or, Initiate the login sequence for your selected login protocol
    header("Location: https://account.domain1.com/.....") 
    exit;
}
// User is sync

// Page load success, continue other operation

Logout

Login is very similar to Login, basically:

  • Before logout goes through, redirect to all 3 domains just like login
  • Remove the SSO cookie
  • Continue the normal logout flow

Pro and cons for the methods:

  • Pro: All domain sync possible
  • Pro: No need to relies on 3rd party cookie
  • Cons: First time login longer (around 50ms longer)
  • Cons: Customization on every website is needed for the sync to works

Upvotes: 1

pedrofb
pedrofb

Reputation: 39271

Cookies and localStorage can be shared between domains using an intermediate domain. On the home page is embedded an "iframe ', which accesses cookies and sends messages to the main.

mail.google.com and youtube.com can share the cookies using accounts.google.es. Open Chrome->Inspect->Resources->Local storage and you will see in accounts.google.com the authentication token in JWT format.

I have detailed the technical steps in this answer: https://stackoverflow.com/a/37565692/6371459. Also take a look at https://github.com/Aralink/ssojwt to see an implementation of a Single Sign On using JWT in a central domain

Upvotes: 5

Nurkartiko
Nurkartiko

Reputation: 181

Check this out.. http://www.codeproject.com/Articles/106439/Single-Sign-On-SSO-for-cross-domain-ASP-NET-applic. The article consist explanation and sample of SSO cross domain.

Upvotes: 2

LMG
LMG

Reputation: 976

As far as I remember, if I am not wrong, cookies contains a specified field that contains the domain that can read and get such cookie. That is made in order to prevent certain web sites to read all your cookie list and make your own business. You should be able to see which kind of sites can 'see' your gmail cookie.

Correct me if I am wrong, this should compile the answer given regarding the SID and gmail-YouTube example..

Upvotes: 0

Related Questions