I am interested in how a browser manages secure sessions. As I understand it this is the scenario when logging into a google account:

1) Browser (B) and google Server (S) perform a handshake to create a secure session by encrypting http traffic using TLS or SSL.

2) User (U) enters log in details

3) U is authenticated

4) U opens a tab to youtube, and is provided with an option to sign in using their google account.

5) U uses their google account, but is not required to enter any details as their browser still has a secure session with their google account.

My question is, how is steps 4-5 performed with respect to the browser, how does the webpage like youtube hoover up the passwords and session details to send to the youtube server? How does the browser store and manage this?

I am familiar with the operation of protocols like sso and federated identity, but here I'm interested in writing a webpage/app capable of picking up this information from the browser.

  • Steps 4 and 5 are performed generally using OAuth2. Here is an explanation of how OAuth2 works.
    – RoraΖ
    Oct 14, 2014 at 12:03
  • I'm not sure that is what I am looking for - I should add the case I am interested in has both webpages served from two different separate enterprise domains. Oct 15, 2014 at 6:31
  • OAuth takes credentials from say, Google, Google provides an authentication token that can be processed by StackExchange to login. If this is not what you mean then I think you're going to have to clarify your question.
    – RoraΖ
    Oct 15, 2014 at 11:30

2 Answers 2


Secure session details per-website are stored in local cookies set by a response and sent to the server in future requests.

For cross-domain example, like you described with youtube (and a comment described), the standard method is OAUTH or OAUTH2. It is the same mechanism that you may allow other websites to access your facebook or twitter details.

This all manifests as a series of requests with parameters and responses redirecting to other targets.

OAUTH has some "implicit" flows that may allow auto-login across websites without the user explicitly approving it.

You can interactively move through some example requests here: https://developers.google.com/oauthplayground/


Fundamental to anything, the use of a token/coookie is the authentication mechanism's reason it works. How this cookie is verified by a third party is the magic sauce. It's surprisingly funny how everyone keeps trying to break web 1.0s client/server model to include 3rd party intervention.

  • Welcome to Security Stack Exchange, and thank you for providing an answer! Could you elaborate a little on your answer? I would also recommend taking a look at the site tour, under help --> site tour to see what the site is all about.
    – Jonathan
    Dec 9, 2014 at 2:19
  • HTTP (and thus the web) is not based on a client/server architecture, but on a stateless request/response architecture. The difference is significant.
    – Xander
    Feb 7, 2015 at 3:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .