70 lines
3.3 KiB
Org Mode
70 lines
3.3 KiB
Org Mode
:PROPERTIES:
|
||
:ID: f220f537-574c-4545-8727-6a18efcac8a0
|
||
:END:
|
||
#+TITLE: Cross Domain Sessions
|
||
#+Author: Yann Esposito
|
||
#+Date: [2021-03-30]
|
||
|
||
- tags :: [[id:299643a7-00e5-47fb-a987-3b9278e89da3][Auth]]
|
||
- source :: https://www.quora.com/How-does-Google-achieve-single-sign-on-between-different-domains-such-as-YouTube-and-Gmail
|
||
|
||
|
||
Q: How does Google achieve single sign-on between different domains such as
|
||
YouTube and Gmail?
|
||
|
||
I assume your question refers to SSO on browser
|
||
|
||
Short Version:
|
||
|
||
Single Sign On between various google apps is achieved via cookies.
|
||
If you check the cookies that are transmitted/received when you visit one
|
||
of the google domains, you will see that it adds cookies for multiple
|
||
domains like accounts.google.com, accounts.youtube.com/accounts/, etc.
|
||
These cookies contain your current login session information and hence you
|
||
get SSO
|
||
|
||
If you try to login to any app with cookies blocked, you won’t be able to
|
||
login even when your username and password are correct.
|
||
Google usually shows a help page about troubleshooting login issues.
|
||
Specifically, it will open up the page about enabling cookies in your
|
||
browser
|
||
|
||
Detailed Version:
|
||
|
||
- open https://mail.google.com/mail/ in a browser tab
|
||
- since you are not logged on (no session cookies sent during request) you are redirected to https://accounts.google.com
|
||
- you provide username and password and click on login
|
||
- posts a request to accounts.google.com/password
|
||
- the response contains cookies for the domain “.google.com” which contain
|
||
the session information
|
||
- it also contains identifier which is sent to accounts.youtube.com.
|
||
request is sent to accounts.youtube.com/SetSID URL
|
||
- there can be more requests similar to this for domains which are owned by
|
||
google but do not end with “.google.com”
|
||
- e.g. accounts.google.com.au , accounts.google.co.in
|
||
- for all such other domain requests, the current session identifier is sent
|
||
- this session identifier is different from the cookie value that is sent
|
||
- the required URLs are generated on the server and the browser simply
|
||
makes requests to these URLs
|
||
- the above activities happen in background when you are looking at “Please
|
||
Wait…” screen. When you sent your credentials at password URL, you are
|
||
redirected to the please wait screen which sets required cookies for
|
||
other domains
|
||
- once cookies are set, you are redirected to your gmail inbox
|
||
- since a request to accounts.youtube.com was already sent with current
|
||
session identifier, the server at accounts.youtube.com generates cookies
|
||
for “.youtube.com” which are present in the browser
|
||
- Google would maintain a central database of login sessions which can be
|
||
queried with the session identifier by all the other domain servers. That
|
||
is how they can generate cookies for the same user. I don’t know the
|
||
exact implementation but this is the general idea of maintaining cross
|
||
domain SSO
|
||
- now when you try to open www.youtube.com in another tab, those cookies
|
||
are sent along with the requests which auto logs you into youtube
|
||
- Similar set of events happen when you click logout on gmail tab
|
||
|
||
you see a please wait screen that sends requests to accounts.google.com,
|
||
account.youtube.com and any other domain that doesn’t end with
|
||
“.google.com” but is owned by google the response would clear the session
|
||
cookies now navigating to any link on youtube tab would suddenly show you
|
||
logged out
|