[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.