How does SSO (Single Sign On) work

However, if user opens a browser directly and goes to App B, then how does their session get established with existing token?

If the answer is there's session state on the back-end server, then how does session state match the user logged in App A with the new request for App B?

I would say it's more about cookies and redirects than it is tokens. Tokens are generated once a user's identity is established.

So when you hit App B via your browser, App B redirects your user-agent to the Auth Server (which may in turn redirect you to a SSO site).

The thing to note is that the SSO login request is actually an HTTP request between your browser and the SSO server.

So the SSO cookie is already there - because earlier, App A would have also redirected your user-agent to the Auth / SSO server where the login was performed. The SSO server could then persist a cookie between you and it.

I can see if I login to App A and retrieve a token then launch App B from App A by passing the token to App B.

I'm not sure I understand about App A passing its token to App B. Usually Apps (Oauth 2.0 clients) would not share tokens. App B should make its own request to the Auth server which (if the user is signed in) may skip the login part but would then need to verify that :

1. App B has rights to the scopes requested and that

2. the signed-in user has granted access to those scopes.

If the user is logged in and has previously approved scope access then all this processing is seamless to the end user other than a bunch of redirects.

This assuming you use the Implicit grant flow (I noted that one of your apps is an angularjs app).

If you use the code, password or client-credentials Oauth2.0 grants then you may receive a refresh token after initial user login and consent.

The refresh token equates to long-term access (for that app only) without the need again for login and consent from the end-user more than once.

Well, there are certainly many ways to achieve it, and it can be tricky. I can give you one solution as an example:

Consider two apps on different subdomains:

The Fine Corinthian Turkey Shop (turkey.example.com)
Rent a Baboon (monkey.example.com)

These two web apps want to share signon, and arrange for a third hosted website for their single sign-on:

sso.example.com

Then the flow is:

1. Frank visits http://turkey.example.com/orders/12
2. Turkey redirects to https://sso.example.com/login
3. SSO presents user with login form, validates and issues token
4. The token is saved in a cookie on SSO.
5. User is now validated on SSO, but needs to get the token back to turkey.
6. SSO stores a combination of (Guid, Token, Expiry) on the server, where Guid is a random guid and Expiry is something like 30 seconds.
7. SSO sets a secure cookie on *.example.com containing the Guid
8. SSO redirects back to http://turkey.example.com/orders/12
9. Turkey can now retrieve the ticket from the cookie
10. Turkey calls SSO server and exchanges the ticket for the token.
11. Turkey stores token in the browser (typically a cookie)

Now let's imagine that Frank wants some nice juicy baboons to go with that turkey:

1. Frank visits: http://monkey.example.com/order-in-bulk
2. Monkey sees that Frank has no stored token and redirects to https://sso.example.com/login
3. SSO sees that Frank is already logged in as he has a stored token.
4. SSO stores a new (Guid, token, expiry) triple on the server
5. Process is identical to the initial login the rest of the way