Introduction to OAuth 2.0 and OpenID Connect

Philippe De Ryck

Recorded at GOTO 2018

[Music]
all right let's have lunch that was it
keep the applause for at the end I'm
gonna talk about a lot and a Freddie
connect maybe towards the end you're not
so happy anymore because it's actually a
complex topic
it's not that easy to digest but I'm
gonna try to make it digestible for you
and my goal here is that you go away by
understanding or fully understanding
what does why it does what it does and
how it does that
same for open ID connect I'm going to
talk about that towards the end it's
built on top of OAuth for one particular
purpose and that is the takeaway from
this session when we talk about what the
best way to introduce that is perhaps
through a real world analogy so this is
valet parking something we in Europe are
not too familiar with but in the u.s.
you can actually hand someone your car
key and they will parked car for you
very easy very straightforward of course
you're handing a stranger the key to
your probably fancy car so that's
probably maybe a bit of a risk so what
you have in these cars is you have a
valet key a special key that you can use
to give towards to ophélie and that key
only opens the door of the car and
starts the car but it does not give
access to the glovebox compartment or
the trunk so if you have valuables in
there I share valuable documents or
suitcases or whatever if you put them in
there that key will not grant them
access to that resource and it brings us
close towards the ID of oh because o it
is about delegation of access and if a
key is a kind of delegating access to
your car to someone else that you don't
really know but under certain conditions
and that's what parts brings to the
table and oh art we need an
authorization server to handle that
delegation first a real world
ohad paced example let's talk about
something like Twitter everybody knows
Twitter I have a Twitter feed my slides
are available through my Twitter feed so
you can grab a copy from there if you
want to to post the slides on Twitter I
use an application known as buffer
buffer allows you me to schedule my
tweets so I can put them ready like
release that at 12 o'clock and I'm good
to go
in the background buffer needs access to
my Twitter profile so I'm gonna delegate
access to buffer to access my Twitter
for
on my behalf and post the tweet whenever
I say it should be posted if you look at
the Twitter side of things there's a
number of applications that has access
to my Twitter feed here's a few examples
you see legitimate Twitter clients
having access but you also see this
buffer application in there and some
other types of applications that is
fought at work that is how what actually
does this thing and what our tries to
achieve allowing you as a user to grant
an application access on your behalf to
a third-party resource so if you look at
we're gonna make all of this possible
through the authorization server that's
gonna be the key component in the whole
of OAuth we as a user want to grant a
client application access so in my
example from before buffer would be the
client application I want to grant that
application access to a resource I
control to access that resource the
client uses an access token that access
token is something that the client has
received buffer receipt from Twitter and
can use that to access a protected
resource in our terms which is hosted by
the resource server so in the example
that we have that would be the Twitter
API to post a tweet that would be a
protected resource on a resource server
and an access token is going to grant
access and the resource server is gonna
need some way to verify whether the
client is actually allowed to do that
that's very important that a resource
server does proper authorization
otherwise any client would be able to do
anything on behalf of any user which is
definitely not what we want oh art what
the spec provides is actually about the
dance between the client and an
authorization server about granting
access and that's actually it may be the
verifying client access is also part of
what but maybe not even the course
packets it's a separate specification
and how to use the access token to
access resource server that's not even
covered by a lot because a lot is purely
about delegation of course all the other
things come into play when you start
using a lot because you'll needs if you
are building an API you'll need to check
authorization and make decisions and
things like that but keep in mind that
it's just based on the mechanisms
provided by ODS but not part of coart
itself the image here shows one very
weird thing we have one client a one
resource server so why go to the TRO
of setting up allowed to make that work
it's probably not worth the effort
because it is quite complex to get this
working and you can make some mistakes
against that of course this really pays
off in a landscape where you have
multiple clients you have things like
buffer which is a back-end system you
have things like a mobile front-end
application you have a web application
all of these can be clients of the same
part protocol or Oh our framework and of
course you have multiple resource
servers all of them offer several types
of resources different API is different
kinds of resources and they all need to
make authorization decisions that is
what an OAuth architecture on high level
looks like before we dive into the
details of how this delegation actually
happens small word about me I'm Philip
deck thank you for the introduction
no one and I am a trainer on web
security so I teach developers how to
build better and more secure
applications I do that all over the
world and under my company pragmatic web
security which is my vehicle for doing
that
I'm also organizing the Second Life
course which is a course in Belgium a
week long security for developers I'm
taught by experts from around the world
I'm a Google developer expert which
means Google recognizes me for my
contributions with security to the
community but I'm not employed by Google
or not affiliated with Google in any way
just as a disclaimer because people tend
to get confused about that otherwise
let's talk about a lot that's more
complex but also of maybe more
interesting I'm gonna approach a lot
from two different perspectives I'm
going to talk about the client
perspective first what does it mean to
be a client what do you need to do to
actually get this flow started and get
this access token and now I'm going to
talk about a resource servers
perspective how can you authorize a
client that is trying to get access to
an API back to the Twitter example so if
you want to build an OAuth client
building it is not that hard but if you
wanna use it with a real authorization
server you'll need to register the
client and in the Twitter case this
means registering for Twitter developer
accounts which is just like clicking a
button and clicking the okay in an email
that's about it and then you need to
register your client with some detail so
you need to provide a name this is
typically known as the client identifier
you need to provide a URL and especially
a callback URL so you need to tell the
server this is where you should send
something if something comes back from
this whole flow we're gonna talk about
that later why that actually matters and
once you do that you get from Twitter
you get your clients secrets you can
typically get an access token and a
secret twitter uses two different
secrets but that doesn't really matter
here or matters is that you have secrets
those secrets should be protected they
should be used in certain scenarios
which I'll talk about in the next slides
and before you start worrying I revoke
these after I make the screenshot that's
also valid if they somebody finds the
slides online and they're like oh my god
this guy put secrets on his slides what
the hell is he doing it's okay they
revoked don't worry
Twitter is an example of a public
service anyone can build a client anyone
can registered with Twitter you can also
use the same thing in an enterprise
architecture nobody prevents you from
running your own authorization server
which is only used within your
enterprise for your clients and your
resource servers in that case you
probably don't have this public
registration interface in that case you
probably have someone responsible for
managing the authorization server and he
registers the clients he or she
to do that so that's this is an open
system the other one the enterprise
there are two various deployment modes
but the principles are the same you need
to register client you need to tell the
authorization server where stuff needs
to be sent to at the end of the flow to
redirect URI really matters there let's
talk about the properties let's talk
about different clients I have three
scenarios I want to cover there are more
but I only have a limited amount of time
so I had to make a selection I'm gonna
focus on three important flows to make
you understand how it works
the first flow is shameless advertising
from second left but that doesn't matter
the first client wants to show a number
of tweets from a feed on a website so we
want to be able to select that I want
eaten is in this street and I want to
show that on the website fairly simple
right what we need to do is call the
Twitter API and
get that tweet information this we can
do with a client credentials grant so
what uses somewhat complex terminology
but bear with me and we will figure it
out so the client here is again it's
it's a back-end system it's just a
system and the client goes to the
authorization server using his client
credentials
remember that client secret that we got
from Twitter this is the moment where
you use it from your back-end system
from a secure environment you go to the
authorization server and you ask can I
get an access token here's proof that I
am indeed this client that's my
identifier and this is my secret and the
authorization server whenever everything
checks out grants the clients or gives
the client an access token client in
turn uses that access token to go to the
resource server hey can I get this list
of tweets from this account which is
public information and the resource
server says oh yeah sure here is the
data
of course after making a proper
authorization decision this is the
easiest of the OAuth flows you might
remember that I said what is about
delegation there's nothing being
delegated here this is direct access
from a client to server essentially it's
machine to machine communication there's
no user involved because it it's not
needed in this type of scenario quick
overview I'm gonna build us up
throughout the the next two scenarios so
the client credentials grant is for
direct access by the client application
remember this it's machine to machine
there's no user involved you get an
access token you can access a resource
that's it everything happens in name of
the client brings us to the second
scenario what if we want to schedule
tweets on behalf of the user that's a
very legitimate case we saw the buffer
example if you want to build something
like that we actually need a way to ask
the user hey can we get access to your
Twitter account so that we can actually
post tweets in your name at that time
you do that for example with the
authorization code grant it's based on a
code let me explain to you how it works
so you can see it's already a bit more
complicated there's different parties
involved the client in this case client
at the bottom is still a tag and web
application and that's gonna matter
later in this flow because we still need
to use a secret and we can only use that
secret and it's
stored in a secure location and a
back-end is considered to be secure so
the client is going to request access
typically that involves the browser it's
gonna trigger a redirect that goes
through the browser towards the
authorization server authorization
server is going to present the user with
a page if it's Twitter it's gonna ask
you who are you if it already knows you
so if you're already authenticated disk
that may be skipped but in general to
ask you please log into your Twitter
account on Twitter itself because the
authorization server here in our example
that is Twitter you log in and then the
authorization server ask who's Mac hey
this this application buffer is trying
to access your Twitter account do you
really want that you want to authorize
that and then the client says oh yeah
sure that's what I intended to do you
click yes now physician services are
interesting so you have authorized
authenticated and authorizes clients so
I'm gonna issue an authorization code
and it's going to do that with a
redirect through the browser towards
this redirect URI that has been
registered before so the client during
registration said if you want to send me
something send it here and that's what
the authorization server will use here
to send that authorization code to this
matters for security otherwise you could
trick it into sending it to the attacker
which is not supposed to happen
this authorization code doesn't grant
any access it's not a token so the
client exchanges that authorization code
into an access token this exchange step
9 and 10 require the use of client
credentials this is where the client
actually has to authenticate to the
authorization server hey remember me I'm
this buffer thing and this is what's my
secret that you gave me I have these to
prove it that's really me and can I now
get an access token in return for this
authorization code even more you can
also get a refresh token but I'm going
to talk about that in a second with that
access token the application can now
now go to this Twitter API and say oh a
post street on behalf of Philip please
and off you go and that is how
delegation works in OAuth so what we
really achieve with a lot is we allow a
user to authorize a client to access
resources on their behalf that's what
what is all about in this flow this is
the most secure flow in a lot because it
involves client authentication step 9
and 10 here require the client to use
its credentials that's really important
doesn't exist in other flows which we
shall talk about in the next scenario
also important the authorization code
here is only valid from one time used
for a very short period of time so
usually it's like a minute so you have a
minute between receiving it here to make
that call which should be enough even on
slow systems if you're taking longer
than a minute there you probably need to
fix some other things before using a lot
and that is what this flow has to offer
if you want to look at that from the
browser's perspective this is what the
user would actually see so you see the
application of buffer in this case
asking you can you connect your Twitter
profile to my application and if you
click that button it's gonna send a call
to the backend of buffer like oh yeah I
want to connect my Twitter account and
it's gonna initiate this flow with a
redirect so you don't see that instead
you end up with a page from the
authorization server that page from the
login if necessary that might be skipped
you authenticate and then the
authorization server asks you do you
really want to allow this yes I do
ok here goes the code truly redirect
back to the backend of the client
application which can now exchange it
and access the protected resources that
is what the user see sees so you connect
it you go to Twitter very important
that's very important in order that you
actually go to the party that should
attend the gate you doesn't this doesn't
happen under the hood it's actually very
feasible you're redirected to Twitter
and you do whatever you need to do there
as a user I mentioned that the client
also gets a refresh token I'm not gonna
talk into more detail about that a
refresh token allows the client to get a
new access token later on so access
tokens are usually short-lived
if buffer gets an access token from
Twitter it's fell out for let's say 10
minutes so it can access the API for 10
access there honestly if I want to tweet
something else tomorrow it will need
access again but I'm not present
tomorrow because I'm probably in a tree
on a train so instead of having to ask
me can you give me another access token
through the hole
process this flow with a refresh token
ask the client to get a new access token
using that Refresh token can go to the
authorization server and say like hey
remember you gave me this Refresh token
a couple of days weeks months years ago
I want to use this to get a new access
token authorization server can check
everything give the client a new access
token and client can independently
access the account in on behalf of the
user again that's what a refresh token
bus and of course you can access the
resource server if you want to get into
the dirty details of how this works it's
all HTTP based well let's let's call out
HTTP based everything should be HTTPS
but the protocol is HTTP so you send
them a request to this authorization
server on Twitter and you indicate that
you want to run this authorization code
grant for me I do that by specifying
code as a response type like I expect a
ID you provide the redirect URI here as
well which should match the one you
registered before and a final detail is
there's a state parameter again no time
to go into detail but you should always
use the state parameter it prevents
certain attacks putting a random value
in there and checking it whenever the
flow is completed is enough but if you
want to know more about that talk to me
later and if you if the flow completes
if the user has authenticated authorize
the application this is what comes back
to through the browser towards the
client application so you see that this
this URL here is used here to make the
call the callback PHP page that receives
this code which I can now use to
exchange that for an access token on the
authorization server that exchange works
like this it's a back-channel request so
it doesn't go through the browser it's
against server to server so it can
simply use a post it uses the
authorization header it basic to
transmit client credentials they are
embedded in there and it provides the
code it got earlier that code is here in
the request the client ideas again here
and the grant type indicates that the
client wants to exchange this code into
an access token and that is the
authorization code grant flow which is
the most complex to be honest but also
oh yeah sorry the response contains the
access token which can be used to access
protected resources and also the Refresh
token as you can see here all right are
still good one more and then we can talk
about some other things so to recap the
authorization code grant gives delegated
access to a back-end application it can
only be used on deck and applications
why because you use this client
credentials to exchange this code for a
token if you want to do that on a client
on a web browser on a mobile application
you would have to hard-code your secret
internet application so it's going to
take someone else like two minutes to
actually cut that out and impersonate
your client so you should never ever
ever do that so this code is only
developed if your client can store
secrets in a secure way meaning if it's
a back-end application very important so
Lee also the reason that only this flow
gives you a refresh token because it's
the only flow that allows the client to
authenticate itself to the authorization
server scenario number three instead of
building this PHP back-end which nobody
really likes we want to build a modern
JavaScript front-end we have like a
hundred frameworks to choose from so
we'll pick one and we build our
front-end using that framework and in
our front-end we want to improve the UI
of Twitter we want to make it possible
to directly interact with certain tweets
we want the user to respond to tweets
things like that so we need access to
the api's again we need access to
retweets access to post new tweets or
replies or whatever let's take a look at
how we can do that the flow we're going
to use here is the implicit grant flow
here's how it works
note that a client is a front-end
application your client is a web
that's now your clients we don't have a
back-end because we don't need it
because our client is a front-end
JavaScript application it's gonna
interact with Twitter directly no need
for our own back-end no need for our own
data since we only interact with Twitter
so the client is gonna ask for access
it's typically happens from within the
browser so there's no redirect here it's
just a navigation to the authorization
server
it's gonna ask the user to authenticate
just like before it's gonna ask user to
authorize the application just like
before whenever that checks out the
authorization server goes back to this
redirect URI with an access token this
time not an authorization code but an
access token directly and that access
token grants this client access to the
resource server and we're good to go
with this access token in step seven we
can read the tweets we can allow the
user to type a reply and we can post
that reply back on that resource server
using that access token that's what the
implicit grabbed us from the users
perspective the user sees a page from
the client this is our JavaScript
front-end application clicks a button
like oh yeah open my feet and then the
flow starts so we're navigated to the
authorization server page where we are
asked to authenticate if necessary we
are asked to approve the application if
necessary ever sent back to a page from
that front-end application that page can
now extract the access token from the
URL and access protected resources
directly and that's what the implicit
grant flow does if you look at the
requests behind this you can see that
they look very similar and we still call
the same endpoint but instead of code we
now tell it we want and token in
response so this tells the authorization
server we're running this implicit grant
flow we're not doing this authorization
code granting but an implicit grant we
provided a client ID which is the only
thing tying this to our client and we
again provided a redirect you arrive the
response is gonna go to that redirect
URI it's gonna provide an access token
in the response directly no refresh
token very important detail note how
this is a hash and not a question mark
fragment and the fragment of the URI is
never sent to the server whenever the
browser loads to URL with a fragment
that fragment stays in the browser
browser only sends whatever is before
that to the server and loads that
resource but a fragment is part of the
URL but it's never sent over the network
so here this makes sense because the
access token is intended to be used on
the client side and that's what we're
doing here there's no additional steps
of course this thing gets a bit tricky
if the access token expires because that
would imply that you have to run the
flow again but again that is a very
heated debate in this community on how
to handle these cases and I'm not gonna
go into detail there so if you look at
this from the overview point of view
delegated the implicit grant gives you
application never ever ever use this
flow when you're also using a back-end
because things will go wrong I can
guarantee that a lot of applications
mistakenly do this they run the implicit
grant for and then they take the access
token and ship them off to their
back-end and then they do some stuff in
the backend through that access token if
you do that you will run into serious
problems so please don't do that always
pick the proper flow for your scenario
very important access tokens are
obtained directly through the redirect
through the fragment of the URI and a
front-end application is also not
supposed to have access to refresh
tokens because front ends are by
definition insecure I know that people
think like yeah but it's it's a
JavaScript framework and I really want
this long term access and I'm gonna do
bit to give a refresh token that's a bad
idea because the Refresh token is only
issued in the other flow because it
requires the use of this client secret
which no one should know except your
client so if you start using refresh
tokens without client secrets you're
doing it wrong and you're opening
yourselves up for serious
vulnerabilities if somebody steals that
they have eternal access to that
back-end system until you explicitly
revoke that if that is at all possible
and that concludes the client
perspective I know this is a very brief
overview so I'll be very happy to answer
any questions after the talk if you have
more specific ones let's talk about the
resource service perspective if you're a
and you're supposed to make a decision
with that access token
note that the access token is sent to
you by the client one of the common
misconceptions is that clients are
supposed to read access to and supposed
to understand what they mean
but as far as the client is concerned
the access token can just as well be
dinosaur it doesn't matter what it is
can be dinosaur a bird dog or some funky
token whatever it doesn't matter what
matters is that the resource server can
do something with it
these are two access tokens because you
have two different kinds commonly used
in OAuth one kind is called a reference
token and the other one is called a
self-contained talk that's like about
the reference token first a reference
token is actually just an identifier
it's an identifier that points to a
piece of our set of metadata kept by the
authorization server so whenever you
give that to a client you're not
disclosing any sensitive information
you're only giving it an identifier and
that identifier will later be used by
the resource server to fetch information
from the authorization server and with
that information it can make a decision
and that process is called token
introspection that's one of the things
in OA that got specified a bit later
than the main spec here's how token
introspection works so you have your
client you have your resource server and
you have your authorization server they
have different endpoints in this case
it's a token endpoint that is being used
so wherever the client access the
protected resource with a reference
token it simply sends this identifier
one way or another usually it's the
authorization header with there and then
the identifier in there the resource
server uses that to exchange that
identifier into a set of metadata set of
stored claims about this user the
authorization server provides that and
with those claims the server can make an
access control decision that claim is
going to say like oh yeah this was
issued for that client and it's
associated with this Twitter profile and
yes this token is still valid here's an
example of how to do that it's again a
back-channel request
it's server-to-server communication you
do a post request you send it the token
you got from the client you tell the
authorization serve this should be an
access token can you check that for me
please and that's what you get in return
the authorization services like oh yeah
I know these identifiers it's still
valid it's still active it's not been
revoked you
hasn't canceled this access token it's
associated with this particular client
and associated with this subject this is
a unique identifier for the subject this
can be an ID this can be this can also
be a full name or whatever the system
wants to use and that is what token
introspection is so if we go quickly
back to this image the resource server
needs to do this round-trip every time
it wants to resolve such a reference
token it's a reference token by design
it's more secure because the
authorization server stays in control of
this token it has all the metadata here
so whenever you say like oh crap I lost
my phone and it my phone has an
application and application has access
to Twitter and I want to revoke that you
can go to Twitter and say like oh yeah
refocus access please I trigger can
forget that information and that
identifier now becomes invalid that's
one of the powers of using reference
tokens so again I'm gonna compare them
to self-contained talk and so reference
tokens are an identifier keep that in
mind full control for the authorization
server but requires this back channel
request in reality doing that
back-channel request on every single
incoming API call is probably not the
best idea it's gonna put a lot of load
on the authorization server for one and
it's a lot of communication between
services for every call that you have to
do so reality what we see in systems
being implementing this is they cache
these access tokens or these references
for a short amount of time so the
resource server can decide like okay I'm
not gonna resolve this every time
because we have a lot of API calls so
I'm gonna catch this for two to three
minutes that's acceptable but of course
it loses a bit of control so if the user
would revoke that in the meantime then
the act the reference stalker will still
be cached for two to three minutes
that's downside of caching and that's
definitely something you might want to
take into account let's talk about the
other side of things I'll talk about
self-contained tokens the name says
itself a self-contained token contains
everything you need to make your
authorization decisions this is what a
self-contained token might look like so
it's a JSON web token a chase event and
I'm gonna talk about the details about
JSON web tokens but the important part
of a JSON web token is the payload and a
payload is a set of claims that are
protected in one way or another so
usually a JSON web token is signed to
ensure that nobody can modify these
claims without being detected
and these claims are generated by the
authorization server the token assigned
by the authorization server and your
resource server can use them to decide
is this allowed or not so what it needs
to do is it needs to verify the
signature of this token and whenever the
data in there like oh yeah this was
Philippe making that request oh yeah no
no and it's indeed for the proper client
so and it comes from Twitter so yes I'm
gonna trust this data I'm gonna decide
yes Philippe is allowed to make or the
client is allowed to make this call on
behalf of Philippa to post this tweet to
that Twitter timeline and that is the
job of the resource server big benefit
self-contained means no roundtrip you
don't have to go back to the
authorization server over and over again
to check what is this identifier oh yeah
thank you no you can simply do it with
the token itself so you win a lot in
that department
the downside is you have no control over
these access tokens they're
self-contained if the user goes to the
authorization service says I want to
revoke this token you can maybe revoke
it but how will the resource server ever
know that it's revoked there's no
communication anymore so as long as this
token stays fell it it can be used by
everyone who has access to that token so
if I can steal your token and it remains
valid for five months then you can have
five point four months because I now
have five months of access to that
back-end API in your name which is very
problematic so these tokens should be
short-lived it is one of the primary
security considerations in the
specifications use short-lived access
tokens and the people implement this in
real life in the idea whatever two weeks
good to go oh sure it works but there
are definitely risks and involved with
that if I'm not mistaken the the recent
Facebook troubles was related to access
tokens and I think they were valid for
60 days
so yeah there are risks involved there
the metadata you need to make decisions
they're stored on the client
so they're out of freed from the
authorization server meaning that you
cannot easily revoke them there are
mechanisms to do that but they're
difficult they're tricky resource
servers need to check the integrity of a
self-contained token before using them
very very important if you forget that
things will go around really really
quickly that's the use of access tokens
you may have noticed in the request
before that there was this parameter
called scope I skimmed over it because I
knew I was going to talk about it later
so I didn't mention before scopes are
actually quite an interesting property
because the scope allows you to limit
the permissions associated with an
access token so if you request an access
token as the client you can provide the
scope remote like hey authorization
server I want access to this account and
I want to read access or write access
and the authorization server is going to
ask the user this application is trying
to access your account that wants to
read your Twitter feed and writes
postings to your Twitter feed do you
want that and you can decide yes or no
and if you don't want that you choose no
of course and the whole flow fails with
an error and if you click yes then
authorization server will associate the
Scopes with the access token this is
very useful a very practical example in
real life I bought a scanner which can
scan to Evernote which I thought it was
a very cool feature no more manual
putting things in Evernote and when I
set it up it used a lot and it asked
full access to my Evernote account like
hey we can read all your notes and
notebooks and we can write notes and was
like why do you need to read all that
information my whole wife is in there
I'm I'm not gonna give you access to
that especially not because your other
software sucks so I'm not sure that your
what implementation is gonna be any good
so these things actually do work in
practice scopes are undefined in what
the OAuth specs us like yeah you can put
your scopes in this parameter but yeah
put put in there whatever you
you're gone look at a real example this
is how the users ask for permissions on
for example slick these are the scopes
offered by selectable a very small
portion of the scopes they have chosen
to have very fine-grained scopes based
on the objects and the level of access
so for example you have an arts cope
which gives right access to channels and
that is associated with this method so
if you want to use any of these methods
you need write access the needed scope
granted by the user and they make a
distinction between user related clients
and both related clients again so that
the user has a very good idea of what
exactly he is granting to a client and
the best practice for a client is to
request as many scopes as you can get as
little scopes as you can get away with
sorry as little scopes as you can get
away with so if you're only showing
tweets to a user there's no point in
asking for read and write access just
ask root access a very important
consideration in practice you can go
completely nuts with scopes so if your
Google you have a lot of api's they have
chosen to use URLs as scopes so of
course if you request like 25,000 of
them it's probably gonna be a very long
request but you're not supposed to do
that you're probably not building a
client that needs both access to Google
Analytics and Google Docs spreadsheets
at the same time probably me I don't
know what you're building but you get
the idea but you can see interesting
things like you have a full access to
analytics scope like view and manage
data but you also have a read-only scope
and things like deleting users or
deleting requests or deleting data from
analytics is a separate scope which is
not even part of the view and manage
data scope because it's so sensitive
that they explicitly put it separately
and again if you request an access to a
commit only the read-only scope and
somebody manages to steal that the worst
they can do is read data at least they
cannot delete or modify any data so
again it's your responsibility as an
implementer of the client to choose the
Scopes that suit your client and to keep
them as minimal as
and when you do that this mechanism
actually works quite well of course it's
the responsibility of the resource
server to check these scopes they are
part of the metadata associated with a
token
so whenever the token comes in the
resource servers you check what you're
trying to do
post the tweet do you have write access
yes okay apart from the other checks
that are done of course that is how
scopes actually do work very well to
contain permissions associated with an
access token so far for dive into Ord
let's talk about open early connect a
statement at the bottom might not be
very accurate I'm fully aware of that
but open ID Connect is about
authentication because how do you do
really evolve people think they can do a
little bit it's actually very tricky so
if you run this hole or outflow at the
end your client gets an access token it
could fetch user information with that
access token that is typically how
authentication is implemented but is
that really authentic Asian how do you
know if the user is authenticated well
it's kind of implicit because you assume
that the authorization server does some
form of authentication but is it fresh
when the user intent kay maybe the user
did that five months ago and his session
with the authorization server is still
valid does that count as an
authentication for the client if the
client uses this user info to
authenticate the user is that a fellow
authentication not really and every
client makes a mistake then you don't
even know whether the access token is
fell out and finally where do you get
that user info on Twitter it's on that
endpoint and on Facebook it's on that
on that endpoint and you get the idea
so if you want to implement this login
with Facebook Twitter and Google you're
very likely to have three different
implementations which everybody hates
nobody wants that so people actually
messing this up really really badly and
that's where open-ended Connect comes in
operated Connect is built on poet it
follows the same principle of delegation
but instead of resulting in an access
token it results
the issuing of an identity token so the
client again starts the flow
requests identity information the user
authenticates grants access and in the
end the authorization server gives an
identity token to the client and that
information about who the user is when
he authenticated and some other
properties and with that the client can
decide to why is this fella yes or no
and if it is I'm gonna authorize or
authenticate this user and if it isn't
I'm gonna reject this and that's what
open ID Connect is really about of
course you might want to get additional
information from the user and that's
what you have the user info endpoint for
an open ID Connect instead of allowing
the authorization server to choose like
yeah we're gonna put that wherever you
want no if you are implementing already
connect you provide one endpoint that's
called user info no questions that's
just how it works and that's where the
client can actually get that information
from and this is built on part because
it used it flows but it makes a lot of
decisions for you where oh it is very
open like here you can use this
mechanism implement it however you want
openly Connect says this is how you do
it that's what you get out of it this is
data in the identity token and that is
how you implement this and this becomes
interoperable Google influences if you
log in with Google you're using OpenID
Connect but if you would use other
services if they also implement OpenID
Connect it's the same implementation
which is very nice and very clean in
your application this is an example of
an identity token you might recognize
the format by now this is again a JSON
web token it's signed by the
authorization server so if you would
choose login with Google you'll get a
token from Google and it's signed by
Google so you're the client application
you can verify this is token sign my
Google oh yeah this is it fell it oh
yeah okay now I have some information
the SUV claim is a unique identifier
representing the user which is in your
case not very useful because it's
Google's ID I don't know but you also
get this email at the bottom and that
email will for example allow you to link
the identity of that user to something
you
concept in your application so you can
now look up in your own database like do
I have user with flip at pragmatic lips
cute come on yeah here's the guy so this
token is fella it's from that guy so I'm
gonna link it to his account and now
he's authenticated as Phillip in this
buffer application or whatever is using
it you can see there's a few other
claims involved here as well um maybe
one of the important things is there's
an authentication time in here so you
know exactly when the authorization
server has authenticated to user and you
can decide is this acceptable yes or no
if it's a high value transaction that
you're doing with this in an enterprises
and not with login with Google
please but in an enterprise system then
you might want to require a fresh
authentication because maybe it's not
valid if the user logged in yesterday no
you want fresh authentication the ACR
indicates the strength of the
authentication that's useful to indicate
whether the user used multi-factor
authentication yes or no because
sometimes you might require that and
this is a protocol designed to provide
you that information and that's what
open ID Connect brings to the table open
early connect is based on art and offers
three flows which are actually very
similar to the OAuth flow that we
discussed before I'm gonna quickly go
over them and then I'm gonna wrap up so
we have time for one or two questions at
the end there's an implicit grant flow
used for front-end applications only
that never changes implicit grant means
implicit client authentication as in not
really client authentication so only
front-ends it works just like the other
flow so the client is gonna start the
type token it now says I also want an
identity token an ID token that
indicates I'm running open ID connect
here I need a identity information from
the user from you it's gonna do the
dance with the user authorization yes of
course and here we go it gives an access
token and an identity token the identity
authenticate the user which in a
front-end application doesn't mean very
much but you get the idea now can say
welcome back for this Thank You
front-end application the access token
in this regard can be used to make calls
to a protected resource
like which part it's port rolled into
one so that you can actually do
something useful afterwards with api's
as well you don't have to use that this
is optional the use of the access token
but it's often done together that's the
implicit grant front and only
authorization code grant very quickly
the same setup as before you the client
starts the whole dance with a redirect
again this doesn't change it's still
code you go to the hops of
authenticating the user granting
authorization you redirect with
client and that's where operandi Connect
comes into play the client now exchanges
this authorization code using suppliant
credentials and gets an identity token
and an access token and that identity
token again authenticates the user in
this case it's a back-end system so it's
going to look up in its own database or
yet that's associated with this user so
now I know that this user is logged in
instead of doing the authentication
directly we got that information from
here and we now know that that user is
effectively logged in into the backend
so we set up our own session or whatever
we do and we do our enable interaction
with the user and again we can use the
access token if we want to and then the
new one sorry
this is for back-end applications that's
what we covered and then the new one is
the hybrid flow this one is its well
it's new but it's not really new if you
understand this workflow is it just
helps you get the identity token quicker
in the client so essentially what you do
is you start the same flow but instead
of only acts requesting a code you also
ask for an identity token in this step
so we're gonna do the whole dance and
we're gonna get an authorization code
and you're talking directly in the URL
which will make it end up directly in
the client allowing the client to attend
to authenticate the user at that point
without having to do this spectrum or
request to exchange the code for the
access token and it's open first so it
saves you time it's quicker it's more
efficient and it's often used in
practice because of these reasons and of
course then you can still get your
access token to
you put this back together again the
identity token is intended for the
back-end application very important if
you are using this hybrid flow you need
to ensure that this identity token is
intended for your client
there are many implementations that
actually do this and then they accept
any identity token that comes in meaning
that if I have a client that you just
log in with Google and if you have a
client that logged into the Google if
you are not checking the audience I can
give you an access token identity token
issued from my client and you will
accept that meaning that I could take
something from my client and use that to
log in as a user of your application
because of a vulnerability and this is
actually very very common in already
connect scenarios and that's why this is
so important there's other checks that
need to be done but this is really
really crucial because there's at that
step no client credentials being used no
know everybody is like filled up until
here with flows and tokens and codes to
remember part is a mechanism to delegate
access on behalf of the user there are
some other use cases but the general
difficult flows in allowed allow an
application to access a resource on
behalf of the resource owner the user
that is associated with that resource
and that's the only thing you should do
it on unless of course you have no other
choice for example Facebook has their
own authentication protocol on top of
odd which is not open any connect but if
you have a choice in an enterprise set
up you will have a choice if you deploy
your own authorization server if you
need authentication
that's radios use open addy connect part
is not about authentication smart
delegation open ID connect offers you
identity information is designed for
authentication in these ways and
actually handles a lot of more corner
cases than the ones I have been able to
discuss here and that's what these
things really are about and I hope that
that's the thing you take away and if
there's another thing you need to
remember always use the correct flow
look it's not that hard once you know
that you need to look for this look what
is the proper flow from application and
actually use that proper flow and that
concludes the talk thanks you thank you
for listening and if you have any
questions I'd be happy to answer them