3

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.

Improve this question
  • Steps 4 and 5 are performed generally using OAuth2. Here is an explanation of how OAuth2 works. – RoraΖ Oct 14 '14 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. – user1658296 Oct 15 '14 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 '14 at 11:30
1

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/

Improve this answer
-1

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.

Improve this answer
  • 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 '14 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 '15 at 3:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.