Introduction to OAuth 2.0 and OpenID Connect • Philippe De Ryck • 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 a conceptual view from a very high level 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 registers them for the developers asking to do that so that's this is an open system the other one the enterprise system is more of a closed system so 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 access this resource server so it can 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 authorization server is gonna ask you to 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 minutes and then it expires boom no more 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 code as response you provide your client 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 the most secure 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 application a web page in the browser 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 this means that this is part of the 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 delegated access to a front-end 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 this anyway I'm gonna modify the flow a 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 resource server you get an access token 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 signature checks out it can look at 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 so a self-contained token contains all 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 authentication with all odds you can't 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 endpoint and then you have Google it's 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 identity token is going to contain 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 flow but instead of giving the response 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 token allows the front-end to 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 authorization codes which goes to the 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 access your protected resources so if 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 secret nothing linking to this code I 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 you

Channel: GOTO Conferences

Views: 34,817

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Philippe De Ryck, Pragmatic Web Security, OAuth, GOTOber, GOTO Berlin, Security, OpenID Connect, OAuth 2

Id: GyCL8AJUhww

Length: 47min 17sec (2837 seconds)

Published: Thu Jan 10 2019