[MUSIC] Stuart Kwan: Hi. My name’s 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 modern authentication for web applications. In a previous video took a look at some of the concepts of when we have a client that’s talking to a service and in order to authenticate, it needs to use this new player called an identity provider. In this scenario, we’re going to make this concrete. The client is going to be a browser. And we’re going to have our hero, Alice, here using the web browser to talk to a website. When we begin, Alice just navigates her browser to the website. Now, she hasn’t authenticated. The website doesn’t know who Alice is yet and there’s actually a way that it’s going to know that it doesn’t know who Alice is yet, but we’re going to talk about that in a little bit, but suffice it to say Alice isn’t signed in, so we’ve got to get her signed in. The website has a trust relationship with the identity provider and it uses this trust relationship to know that if it wants to sign Alice in that it needs to send her to the identity provider to get signed in. So, what it’s going to do is it’s actually going to use Alice’s browser and send a redirect through her browser to get her browser to talk to the identity provider. This is literally the website sending an authentication request to the identity provider by using her browser as an agent to do so. If you were to look at a web browser when you’re looking at a sign-in page and you were to look at the address bar of the browser, the parameters that are in the query string of that URL, the stuff that’s after the question mark, are actually just the parameters of a sign-in request. So now, Alice’s browser is talking to the identity provider and she needs to sign in. And maybe she’s going to enter a name and password in a form or maybe she’s going to present a smart card or maybe she’s going to use an authenticator on her phone or maybe multiple of those factors to get signed in. That’s a matter between Alice and the identity provider, but once the identity provider has decided that Alice has signed in, it’s going to issue a token for her and it’s going to use her browser again to get that token back to the website. And usually, that’s done through an HTTP post where the token is in the body of the post message. What you’re going to hear with these protocols is that they talk about bindings, so about how the authentication requests and responses are bound to the protocol. In this particular case, I showed a fairly popular combination where the website is using a redirect binding to send the request and the identity provider is using a post binding to send a token back to the website. So now that the token has arrived at the website, the website can validate the signature on the token because it knows the sign-in key of the identity provider. And in the case of an actual website, it can find this sign-in key just by getting it off of an endpoint that the identity provider has stood up—a document basically where it can read the sign-in keys if they’re public keys and that anybody, in fact, can validate tokens that might be issued by that identity provider. And at that moment, Alice can be considered authenticated by the website because we’ve determined the token is valid and from the claims, we know that this is Alice. Now, how does the website know on subsequent calls from Alice’s browser that this is still Alice and Alice is authenticated? We talked about that earlier; how did the website know that Alice wasn’t authenticated? Well, the way that it does this is after it has received the token and signed Alice in, it puts a cookie on Alice’s browser. Now if you’re not familiar with HTTP cookies, what they are is just a piece of information that the website says, browser, please always send this piece of information back to me on every request that you send to this particular host. So, for example, if this is literally example.com, then always send this cookie back to example.com every time you visit it. This established a session that Alice’s browser has with this website. And when you think about it, the cookie is actually another form of security token. It needs to be signed. Otherwise, if Alice could tamper with the cookie, then she could pretend to be someone else by altering the contents of the cookies. So, it’s actually signed with another key; I’ll just call that K2. And that’s a key that the website owns and it uses to sign its cookies. It has not relationship at all to the signing key of the tokens from the identity provider. It’s just another key used by the website to validate these cookies. So, that’s the complete flow. We have Alice at her browser. She’s able to get a token from the identity provider, send it to the website. The website can validate it, can set a cookie to use as the session. Now, the actual protocols that get used in industry for this are protocols like the SAML protocol, the OpenID Connect protocol, and the WS Federation protocol. They all do basically the same thing. They have various different bindings. They carry various different kinds of tokens, but they perform this particular function. The biggest difference between them is really technically speaking just the way they’re encoded; XML is used for both SAML and WS Federation, and with OpenID Connect, the tokens and the protocol itself is mainly described in JSON instead. And that’s the basics of modern authentication for web applications.