[MUSIC] Stuart Kwan: Hi. I’m Stuart Kwan and I’m a Program Manager in the Azure Active Directory team and in this video, we’re going to take a quick look at web single sign-on. So in a previous discussion, we looked at how Alice at her browser was able to sign into the website by getting a token from the identity provider using protocols like SAML or OpenID Connect or WS Federation. Now, one might ask if Alice has done all this, what if there was another website? We’ll call this another website and it’s at a different URL, say example2.com, and Alice points her browser at that website? As we mentioned before, she’s not authenticated when she reaches this website. The cookie that has been set on her browser is only being sent to example.com because it was set by example.com. So when she goes to example2.com, there’s no cookie; there’s no session. She needs to sign in again when she reaches this website. If this website also trusts the identity provider, then the website will, as we saw before, use her browser and send an authentication request through her browser to the identity provider. Now, something I didn’t mention in the previous video was when Alice’s browser was having that authentication conversation with the identity provider, it’s also possible for the identity provider to put a cookie on her browser representing her session with the identity provider. So now when Alice sends this next authentication request through to the identity provider from the second website, the cookie can be used to authenticate her, meaning she doesn’t need to enter her name and password or do any kind of interactive authentication here. If the identity provider decides that it’s okay, it can simply use the cookie to know this is Alice and then send a token back through her browser, token t2, to the website. And then the website once it validates the token using the sign in key of the identity provider, can set another cookie—this one for example2.com, we’ll call it c3—so that she now has a session with this other website. Now, you’ll notice when Alice first opened her browser, she went to example.com. She got signed in through the IDP. She went to the next website. She didn’t have to enter her credentials again. That’s why we call this single sign-on because she only needed to enter her credentials once in order to get all of these sessions created. Now, you might ask yourself, what’s the relationship between the first token, t1 sent to the first website, and the second token, t2 sent to the second website. Well, as it turns out, there doesn’t have to be any relationship between these tokens. The tokens and the claims that are in the tokens are a matter of the relationship between the website and the IDP. If example.com needs one set of claims to do its job, then the IDP will send that set of claims. If example2.com needs a different set of claims, then it will send a different set of claims to example2.com. So, There doesn’t have to be any relationship between these tokens. Furthermore, it’s even possible for example.com to use one protocol to authenticate to the IDP, say SAML, and for example2 to use a different protocol to authenticate with the IDP, like OpenID Connect. And everything will still be single sign-on because of the session that Alice’s browser has with the IDP. That’s the secret to being able to have the IDP do all of these different interactions and send all these different tokens. So, as we can see the IDP plays this interesting sort of impedance matching role, where it makes sure that each of the websites gets what it needs through the protocol that it needs. And that’s the basics of web single sign-on using modern authentication.
