Modern Authentication - Rob Moore

all right good morning everyone my name is Rob Moore my name is Matt Davies and we're principal consultants at ratify so we're here today to talk to you about contemporary authentication so authentication is obviously a pretty hot topic in the last couple of years there's password breaches and every week there's people getting hacked left right and center there's a lot of examples of people doing things in ways that could definitely be improved so that's something that we really want to talk to you a bit about today but what we found when we started researching some of this stuff is that it's really really difficult to understand exactly what's going on every time you do any searching for what how how anything works you come up with pretty complicated spec documents you come up with all symbols on issues all sorts of crazy definitions using all sorts of stuff that's that's really really difficult to follow so one of the things that we wanted to do especially on a morning right after a crazy boat cruise is come up with some really really simple explanations of what's going on and try to use some consistent terminology so that it's hopefully reasonably easy to follow so we've broken this clock up into four parts we've got the Y of authentication why do we even care about this stuff we've got the what so some of the different terminology that goes on some of the difference by basic concepts that we really need to be aware of we've got the how so what are some of the different protocols and standards that are involved in some of this stuff and then we're going to deep dive into one of those standards in particular which is called open ID Connect which we really believe is one of the fundamentally important ones could be across at the moment because it's basically everywhere cool so let's start with the why why are we standing here talking to now if we start by looking at a traditional application model s pretty much everything within the application is within the bounds of a single application right so you've got your you know UI business logic data layer the UI is going to take credentials from the user pass it across the some sort of authentication source and check the credentials itself and then it will do some sort of lookup to check or throws a ssin cool so if we look at a more modern application we're seeing today a couple of different things the first thing that we're seeing is that people are quite often externalizing their identity off somewhere else outside of their application and that's really useful for a couple of reasons the first that it means we can really leverage third-party single sign-on providers we can use like for example a Google Facebook so on and these guys has invested a lot of time and money and effort into coming up with really really secure implementations of this stuff and frankly there's some really really clever people who come up with this stuff and they make sure that it works really really well and we get all of that for free the second thing that we get out of this is really easy single sign-on so users just have to maintain one identity they can go use it a bunch of different places they don't have to remember a bunch of different passwords it creates a really good experience for them so that's the first thing that we're seeing the second thing that we're seeing is that people are building applications in quite different ways nowadays they're coming up with applications which are much more distributed than they use micro so much more distributed than they used to be in the past and what we send tend to find is that you use a lot of different api's a lot of different services you might not own these services and api's anymore they might be owned by third parties and so you can no longer trust just giving them your users passwords you need some secure way to pass around the identity that's being used so it creates some interesting challenges and this is what we want to talk a little bit about today and on how to solve now certainly these in particular two things that we're noticing change the dynamic of how you perform authentication compared to what we did traditionally but there's something else is also really important and it's pretty much epitomized by this website so most of you probably know about Troy hunt he runs this website have a bento INSCOM I encourage everyone to go there and put your email address in but your friend's email input your friends email address is in after the talk of course and check out you know whether or not you've been in a breach but what this website makes abundantly clear very quickly is there is a lot of breach passwords out there millions and millions of them but more than that this isn't something that just happens a couple of times a year this is literally happening every other week and all you need to do to see that is just say follow Troy on Twitter and look at all the free tips he talks about so often it's frankly scary being a web developer and seeing that now absolutely yeah this is why this stuff is important if your application doesn't take a password it doesn't need to store it and you can't breach it and you've completely removed a whole set of risks oh so that's why we're here talking to about the stuff let's talk about what modern authentication actually is we find that there's a number of terms and concepts that are kind of important to understand to be able to kind of get the whole picture so we're going to dive into a few of these and hopefully try to explain them the first one is the difference between identity authentication and authorization now we've actually got a nice physical example of this so say I'm going out on a Saturday night I decide I want to go to a pub or bar or something like that and have a drink so I walk up to the entrance and then there's a bouncer let's say his name's Matt actually a little bit imposing and what I do at that point is I say hi Oh where's all my that's whatever fun man shelter I'm going to click her on them go all right so I walk up and they say hi I'm wrong there's nothing work unless you like yeah anyway so hi I'm Rob that's my identity now I could say anything I want to him I could say hi I'm Jim or Bob or or whatever he's not going to know that I am in fact Rob until I prove myself until I authenticate myself now in this instance that means I give him my driver's license and at that point I was indicated myself he knows I am now Rob proven my identity now at that point he's still not going to let me in because he needs to authorize me to make sure that I'm allowed to come in at that point he needs to in this instance check my driver's license for my date of birth oh thank you and check that I am in fact over the age of 18 not actually sure you are might be a bit of an old photo so once these check that and check that I'm over 18 I've been authenticated authorised I'm allowed access to the resource that I wanted to so maybe a beer in this case cool now this situation plays itself out in pretty much every modern authentication is doing very modern application that's doing authentication so this is just a physical example of it the other thing that's incredibly important to understand is something called claims-based authentication this is the underpinning of basically every modern authentication protocol we find that is likely I mean we got really confused we're trying to figure out what the media's and being developers the first thing we turn to to try to figure out what it was is of course we went to Stack Overflow now this is pretty much the simplest definition we've been able to find on what claims based off is so this guy says claims based authentication is about defining who you trust to give you accurate information about identity and only ever using that information provided but let's dive in a little bit deeper and try to explain it a bit better again we've got you got a nice physical example first if you think about the government and more specifically the licensing department in the government simply some sort of interference here by the licensing Department issues driving licenses like in the example we just showed with the bouncer this is actually a real world example of claims based authentication in this instance the driver's license is the identity token or security token the bits of information on the driver's license like your name address date of birth there the claim claims and claims based oils is basically just properties attached to your identity now in this instance the government is the identity provider if we go back to that stackoverflow quote that's the thing that you trust you trust that the government can identify someone so you trust information provided by the government in this example the identity sorry the licensing department is the security oaken service that issues the token now there's one other fundamental piece that's missing from this that makes up claims-based authentication it's the most important part because if you think about the instance where I walk up to the bouncer and I give this driver's license he needs to check it to make sure that it's valid that it's actually been issued by the government although it is not going to trust it it needs to make sure that it hasn't been it's not a fake ID basically and that's the act of token validation now in the case of the physical example is all these cool holographic logos and that sort of thing on the driver's license that you can look at to make sure that it's it's real in a electronic example all of this plays out and all of the modern protocols that we're going to be looking at in this talk and for instance a token validation is usually done as a cryptographically signed hash so one of the things that you might have noticed if you've done a lot of research into this stuff yourself is that there's a lot of different terms out there to basically describe the same thing you can you can have names that mean all sorts of things so one of the things that we really want to do as a part of this talk is try and use fairly consistent terminology so when we refer to a relying party we mean the application that's actually trying to perform authentication when we refer to a user we mean the actual end user that's trying to authenticate and when we refer to an identity provider we mean the source of truth the entity that's actually validating whether or not an identity is correct now if you if you look into this a bit you might see that there's all sorts of names for this stuff and confusingly for example a relying party in auth is called a client but in open ID Connect which is based on a loss it's called a relying party so it's easier to get a bit tripped up a user can kind of confusingly be called a subject such a weird pretty that's pretty weird one identity providers can be called all sorts of things so this can be a bit of a useful like reference I guess but when you're looking into this a bit absolutely feel free to print this slide out and print it up on your wall so when you're looking at the old circuit like 2:00 a.m. and you're not getting to confuse you know how much you like doing that yeah so when you think of traditional authentication you might first think about password authentication obviously the most common one out there and when we say password authentication what we mean is that the user will directly provide their password to the identity provider the to the sorry to the relying party the relying party will then pass that password on to the identity provider and verify it usually that's against like it's some sort of like internal database or something like that this is a pretty common set up and it's a pretty big problem for a couple of reasons the first is that that password is now shared across some kind potentially like Network environment in a couple of different places and could be intercepted so we've got that password in places it doesn't necessarily need to be the second is that this doesn't really support a scenario where that relying party isn't it isn't the owner of those passwords and credentials because you don't necessarily know how it's going to handle them or what it's going to do with it so um there's a couple of things that we can do about this to try and sort this out cool spoiler alert so that's where tokens come in right so we just talked about tokens with claims based authentication with the driver's license example and it's actually two different types of tokens so there's reference tokens and self-contained tokens reference tokens are basically just a random string of you know numbers and letters and whatever it is is just essentially a look at the way that that works is that the user will provide their password directly to the identity provider so that the relying party never sees it the identity provider will then issue a reference token to the user which they will pass on to the relying party and at that point the relying party will exchange that with the identity provider in return for that users identity and claims now because they've talked directly to the identity provider where there's some trust they know that they can trust those identity and claims self-contained tokens are a little bit different so again the user passes that password or credentials directly to the identity provider but in return they get their self-contained token so weird and that token actually contains the identity and claim information inside of it so when that token is then passed on to the relying party then the relying party has everything that they need to do authentication and authorization for that user now there's that important step of token validation that's missing here as well we're like not clicking and and that's so that the relying party can make sure that the token hasn't been tampered with so for instance the user hasn't gone and added a claim saying that they're an admin user or something like that that way they relying party can make sure that the token is as it was issued from the identity provider which of course it trusts and that's the most important part of claims based off as we said cool so something else that we wanted to talk about a little at this point is multi-factor authentication and we've got a definition up there but basically multi-factor authentication if you haven't come across it before is essentially trying to use more than one proof of proof of verification that the user is who they say they are so typically that by combining two different things one of those things is something that the user knows which is usually like some kind of static password something that the user has so quite typically like a mobile phone or some kind of device that you can't really like a clone or duplicate and lastly you can sometimes combine in biometrics so that's like your thumbprint or something like that and multi-factor authentication is really really important because it gives us such such a guarantee that the user is who they are as compared to just a password which is really easily leaked out and really easily reused where this kind of started is common elite mobile numbers commonly phones sort of evolved from there into token so software and hardware tokens which are essentially just things that the user has which generate tow tokens or codes according to some predefined algorithm which the server also knows about so it can essentially verify that the user has the same token that they should that's evolved even further from here into using machine learning to actually analyze the user's network activity and login patterns and location and things like that to verify they are who they say they are which gives us even more certainty so this is this is evolving very quickly but it's becoming increasingly more important to start taking advantage of some of this stuff as opposed to just using passwords and it's really easily really easy software the service providers make this super simple if you're using for example Microsoft Azure ad you can get all this multi-factor authentication and the machine learning side just out of the box and the user just automatically gets to opt in and take advantage of this so it's kind of cool and it's pretty easy and not many excuses left and not start taking advantage of some of this stuff if you want to know a bit more about that machine learning stuff it's something called risk-based multi-factor authentication feel free to hit up our CIO t14 he will talk your ear off about it for like an hour and it is pretty cool though yeah so we wanted to talk jump now and talk a little bit about how some of the spam that are involved here we're going to talk a little bit about token standards and the actual authentication protocols that are used but I guess it's really important to note that standards are super important here they give you a huge interoperability out of the box if you're relying part of your application is talking to an identity provider that follows some certain standard you can just drop a library into your application and instantly be guaranteed that it's all just going to work and that lets you take advantage of peer review and think if things like that we're really really clever people have looked at this stuff and come up with implementations that are really really secure and you're at less risk of making mistakes let's be honest these people are like way smarter than oh yeah way smarter than us and I guess like following on from that point the security it becomes a lot simpler in this case because you're again taking advantage of really large standards bodies that have figured this stuff out they're usually backed by organizations with a lot of money and resources and time who put a lot of effort into making these things really solid so you get a lot out of just using them so the first thing that's worth talking about is token format so we're going to talk mainly about sam'l and JWT tokens there's a few different token formats out there but we're just going to mainly focus on those two so let's start by looking at somal tokens this is the incredibly boring frankly definition of what observable token is essentially it just boils down to it's a standard it's an XML format it has the ability to have attributes so that you can have claim information and it's cryptographically secure this is what a sandwich auction looks like pretty crazy it's just gross it's ugly it's for both it's exactly what you expect and always wanted from XML but but but to be fair to the sam'l token format standard it's been around for a long time it's incredibly robust and it has a lot of support so like 99% of the time you don't have to know anything about that you just pull in a library and it kind of work so it's actually pretty useful now to be even varus's able to examine if you had a bit of kind of syntax highlighting bit of formatting get rid of some of the craziest XML stuff in there then it actually ends up being quite simple if you look at it there's essentially a header which has a the the actual issuer that issued the token and the signature so that you can verify that it's intact it's got a subject statement talking about who's indicating it's got an authentication statement talking about the properties of the actual act of authenticating and then it's got a bunch of attributes which is that claim information that we've been talking about so JWT so we've got a definition up here for a JSON web token but essentially JW tees are an attempt to try and make this stuff a little bit more compact try and make it such that a real person who's looking at this stuff can basically understand what's getting transmitted back and forth and and delve into it a bit their JavaScript token so obviously you get the advantage of really strong interoperability with JavaScript but also with just about every other language out there so really really easy to use and they start to get a lot simpler than some more tokens did so we've got an example Matt yeah don't mess with us Matt that's not Jack you said it was going to be Jason them right are carrying those two that I'm only half messing with you so this is base 64 encoded so what we've got here is a basics before encoded header followed by a base64 encoded payload followed by a hash of those two things and if we perform some magic and we base64 decode this stuff we get something looks like this so adjacent web token has a header in it so that's going to start with type equals JWT that's always going to be the case that's going to be followed by a hashing algorithm that can be RS 2 5 6 or HS 2 5 6 if it's RS 2 5 6 it means its certificate based hashing so you'll also get the thumbprint of that x.509 certificate that's being used followed by that in the actual body of the token itself you've got a number of fields that are reserved we haven't put the complete list up here by any means but these fields are basically if they're in the token you can be assured of what they mean they're very well defined if you've got followed by that a number of public claims so these public claims are also well defined but they're defined in their separate registry they're defined in the ia and a registry for JWT if you see these you know what they mean but you don't necessarily you they're not necessarily locked down over they can be changed and lastly we've got a number of private claims these are totally custom claims that you basically make up so you can put whatever you want here you just need to define their meaning on both your relying party side and on the identity provider side and make sure that they agree on what they mean and you're not going to get great interoperability with other third party services that you don't own by using them but they can be pretty handy in some situations a couple other things to note here so you can see that there's a whole bunch of these really cryptic three-letter and lot of claimed names which on first inspection is a little bit confusing but the reason why they did that was very deliberate the definition on the last slide talked about the fact that JW tees are meant to be compact this is very deliberate to make them smaller because they're deliberately designed to be passed around in HTTP headers so you kind of want them to not be too big right and that's actually also the reason why their basic ste 4 encoded so there isn't any weird characters in there don't mess with patient repeats cool so now that we've talked about token formats are going to talk about authentication protocols arguably these are even more important to have standards for from security point of view because the protocols are determined like what information gets passed around who will indicates where these are the ones where it's even more likely to have those little security holes so for instance for a period of time there people were using OAuth 2 and actually had something called an open redirect attack in there so we've got a bit of a timeline as the different authentication protocols it's really not important to remember of what all of these are exactly the important thing to note is that we started in around like early 2000s and these protocols sam'l WS Federation came around in an effort for organizations trying to figure out okay we've got an application we want that application to talk to an application owned by some other organization but we don't just want to give them all our passwords we need to do something smarter than that so that was federation that was an attempt to solve that problem they were also trying to figure out it really early days how do we do single sign-on effectively how do we try and make sure I users don't have to log into the ten apps that we own as a part of our org so that's what they were trying to do there in the mid-2000s we had protocols like open ID come along and open ID was actually an attempt by the social networks to try and figure out okay well we've got a huge number of user identities how do we like start leveraging our brand a bit better and getting developers to start using those identities and and spread them out a bit wider without compromising the security of our users so they were trying to make it a lot simpler for developers to integrate this stuff in the hopes that that would start pushing that out and they were obviously pretty successful as so what we see today so that was all followed by I guess more modern protocols like Open ID Connect which we'll talk a bit about a bit more in a bit in in a bit but basically open ID connects was an attempt to start simplifying this even further and really learn a lot of lessons from the past especially around filling in some of the gaps that previous protocols didn't really standardize very well so pretty much every protocol on the last slide follows this basic flow what will happen is the relying party will generate a redirect URL they'll send the user on that URL and it will take them through the identity provider at which point they're going to authenticate and then the identity provider will come up with a response and a redirect URL back to the relying party at which point it can process that response pretty much every protocol follows this basic flow so what we're going to look at is just a couple of the protocols we saw in the last slide to give an example in particular of this first redirect URL this is what WS Federation looks like especially not too complex it's got an instruction to the server in this case assigning one pointer it's got this WT realm parameter I don't know why it's called that but that basically identifies the relying party and as part of the registration the relying party has with WS Federation server then the server will know where to redirect them back to we've also got some context information which is just transparent information that's passed back on that redirect back to the relying party WS Federation uses sam'l tokens as its token format now confusingly similar is not only a token format but also an authentication protocol and much like the token format the I mean look at that URL that's just nasty right the reason why it's so crazy is that the request itself is a a 64 encoded sam'l token and then the whole request gets signed bit weird but it means that this bi-directional trust between the relying party and the identity provider so it's incredibly row buttoned and like I said earlier it's got a lot of support if you are trying to integrate some sort of off-the-shelf or software as a service provider with your corporate identity nine times out of ten you're probably going to be using sam'l to do it so it's a very powerful and well supported standard and then that leads us to a bit more of a modern protocol in order to this is much nicer and cleaner it's got an instruction again to the server in this case response type we've got a client ID which identifies the relying party and in this case we've a she also got a redirect URI where the user should be sent to after they authenticate that's actually the source of that open redirect bug that I mentioned if the server doesn't verify that that redirect URI is like ok in a whitelist then you're kind of in a world of hurt call so that leads us to open ID Connect so one of the really interesting things about OAuth 2 is it was actually just an authorization protocol it was never an authentication protocol but that doesn't mean that people didn't use it as an authentication protocol they all just implemented it in slightly different ways so Facebook Google Microsoft it all had slightly different ways of doing this originally so what Open ID Connect attempts to do is fill in the gaps it actually standardizes authentication as well it uses JW tees as the token type it supports multiple different relying party types so you can use what web app seeking use desktop app server the server use JavaScript running on a web browser which is pretty cool you can so there's there's a whole heap of different um client types there depending on your implementation of open ID Connect there's a whole heap of other different things that it can provide you can get token encryption you can dynamically register your clients so you don't actually have to configure them all in the app they can register themselves if that's what you want you can do dynamic discovery of all of the information about the open ID connect server by your client relying party application just dynamically which we'll talk about a bit more in a bit dynamic session management there's all sorts of really really cool and useful features that simplify the whole experience the developers as part of this cool so now that we've covered the kind of basics behind token formats and and authentication protocols as we said we wanted to do a deep dive specifically into open ID connect because it's becoming increasingly prevalent and important and in our mind is probably the most important protocol to have some understanding of these days so so what we're going to do is break this up into a few parts because I mean we are talking it is very simple specification but it's still a spec right so we're going to try to break it in easy for you because I mean frankly when we learn is stuff like it melts at our brain so first we're going to talk about some fundamentals these are things that you really need to understand in order to kind of get what's going on in the rest of the protocol starting with relying parties now as Matt mentioned before one of the things that overnight in connect that just confuses me is that it's literally an extension of oauth2 but it uses a different word for the relying party in the spec just really weird but one of the important things to think about with relying parties is registration this is important from two perspectives the relying party itself needs to have some information about the identity provider that it's talking to so it needs to know for instance the public key of the certificate that's being used to sign the JWT so it can do token validation and need to know a bunch of URLs so it knows how and where to talk to that identity provider and then on the other side of things the identity provider itself also needs to know about the relying party so that when it gets a request from that relying party it knows that it can trusted it's not some random app trying to hack in in terms of the responsibility of a relying party in open ad Connect it's basically very simple it comes down to that basic flow that we looked at before the relying party needs about a constructor request send the user on its way and then deal with a response that comes back from the open ad connect server in terms of dealing with the response it needs to be able to verify the signature of any tokens in that response and look at the timestamp and the last time of those tokens to make sure that they're still valid and they haven't expired they're identified by a client ID again confusing right it's called a client ID but it's a relying party it's just crazy anyway there's two types of relying parties is confidential relying parties and public relying parties confidential relying parties can keep a secret so typically it's something running on a server whereas public relying parties can't so typically that's going to be either JavaScript running in a web browser or it's going to be a mobile application but it's support space so one of the really really cool things that Open ID Connect mandates is that you put up a metadata in point about your open ID Connect service so you put that up at well - known flash open ID - configuration that contains all of the information that you're relying parties possibly need to know in order to authenticate to your server so that's things like all of the different API endpoints that you can hit for different information the public key of your finding certificate the different like token types and claim types and scopes that you support etc so this lets us do some really cool things that we previously haven't really been able to do easily we can for example we could change the finding certificate that we use for our server and one of the things that the spec mandates is that you only cache that information from this metadata endpoint for a certain amount of time which means that we can change the certificate and we can guarantee that all of our clients can go update against that new signing certificate within a certain amount of time previously that's something that's been quite difficult you don't necessarily own all the different relying parties subscribing to you so it's kind of cool when it gives us a lot of power and flexibility one of the things I think is probably the most exciting bit about low commodity Connect for me can be summarized by this bit of code all you need to do to use Open ID Connect at the bare minimum is something like this you need one URL to the identity provider server that's it you pull in the library you pass it the URL it goes to that endpoint it figures everything out and you're good to go that is just create a convenient and this is this is obviously c-sharp and Island but there's examples for basically every programming language out there and they all look something like this at their simplest just one URL cool so the next thing to talk about a skirt now for those of you familiar with OAuth 2 it's exactly the same as in OAuth 2 so scopes allow you to tailor authorization in order for me to try to explain what that means I'll use an example say that you've got some sort of application X Y Z over here that's trying to get you to log in to your Twitter account by that application and then it asks for permission to read your tweets and also read your direct messages now there's two types of scopes is required and optional so the application over here can say hey you know what for me to be able to function my core functionality is that I can read your tweets if you don't grant me that just don't bother but direct messages there's this kind of sidebar kind of cool nice to have functionality you know we if you don't give me that I will just adapt and hide that bit of the app what this would look like in the UI is that it'll be like hi login with your Twitter account to application XYZ you will be by doing this you will be granting application XYZ the ability to read your tweets and check box read your direct messages and you can basically tick or untick that checkbox depending on whether or not you want to grab that permission that active ticking or on ticking is called consent basically how it works the one thing that's kind of different in open ad connectives open ID Connect actually defines a set of standard scopes and then obviously you can also use whatever custom ones that you want as well the standard scopes of this list here the one at the top open ID is required if you're using Open ID connect to a Center cater user you have to request the open ID scopes just part of the spec the four scopes underneath that will grant you a subset of information about that user and we'll look at with what the subsets are in a bit the last one is kind of interesting I've line access if you request the offline access scope and it's granted then you will be able to generate something called refresh tokens and we'll explain what they are in a second so these are the these are the four main tokens you get out of open ID Connect you get an ID token so this is just the user's identity and fairly self-explanatory this is the JWT we were talking about before and we've got an access to a concern access token is just a representation of the fact that you've got permission to access something on behalf of a user also a JWT now you can also have something called a refresh token so refresh tokens basically just the ability to get another access token when yours expires and you might want to do that in certain types of applications and the last type of token is a code and this is just a short-lived code that you can exchange for a token in certain types of scenarios which we'll cover a little bit later terms and scenarios where you might want to use refresh tokens typically boiled down to two scenarios one would be where say you're in like a JavaScript running on a web browser it's a public relying party so the tokens are like visible there now from a security perspective that means that there's a higher likelihood those tokens might be compromised which means you probably want to shorten the lifetime of them but what you can then do is have the access tokens the shorter lifetime and then have a refresh token with a longer lifetime that you can use to get new access tokens whenever you need them cool so this is what an open ID connects JWT looks like one of the first things to point out here is that unlike in regular JWT s there are actually required fields here that you do have to specify so we've got the required ones up here those required ones are basically just well defined fields which always will have to be in the token if you see them you know exactly what they mean you've got some optional fields here as well which are just next on here those optional fields again they're well defined if you see them in your token you can be assured of what they mean but you don't have to specify these and then that's all followed by a number of custom claims as well and these custom ones are basically again you can make these up you can do whatever you want with these but you're just then limited in your interoperability and you just have to specify exactly what they mean yourself cool so now recover the fundamentals the next thing to talk about is endpoints it's a number of different endpoints that you can communicate with with open either connect these three here are the required endpoints they will be in every implementation of open IV connect server there are also a bunch other optional ones that we're not going to cover the first endpoint to talk about is the authorization endpoint this is the endpoint that you send users to to log in this endpoint will give the users some sort of UI for them to provide their credentials now the endpoint will either return a code or an ID token access token and or refresh token depending on which flow you use and we'll cover that in a little bit the initial redirect that the relying party sends the user on to the identity provider will look something like this you'll have whatever the URL is for the authorized endpoint and then there's four required parameters there's a response type client ID redirect URI and scope the response type we'll cover when we look at flows the client ID identifies that relying party the redirect URI is where the user should be sent to afterwards and the server will check that against a whitelist and the scope as I said has to at least have open ID it's space delimited and then you can have any other scopes that the relying party wants to try to request optionally you can also have a nonce to prevent replay attacks and the state that gets transparently passed back on the other end once the user is authenticated they redirect back to the relying party might look something like this you can see that redirect URI we had there will appear there and then we're in this case because we were asking for a code we'll have a code pass to us and then in this case because we had some state that will be passed back transparently that's basically it so we mentioned MSA before if you're using Open ID Connect this is a really really cool place to do it because you can do essentially anything you want at this authorization endpoint between the user getting redirected to your endpoint and then that getting redirected back to the relying party so if you want to use this you use this time you can also trigger an MFA challenge at this point before that redirect happens and that makes it really really simple to integrate this stuff so the next endpoint to talk about is the token endpoint this is an oauth2 compatible endpoint unlike the authorization endpoint where real users hit and has a UI this is just a server server communications so it's basically just an API endpoint what this will do is perform authentication of a relying party the relying party when it hits this endpoint always has to authenticate itself and then it will return some tokens now there's a few different exchanges that can happen at this endpoint but the three main ones are it will either exchange a code for an ID token access token and auto-refresh circuit or you can exchange a refresh token for an access token and a new refresh token to use next time or you can exchange some sort of set of credentials for an ID token and or an access token and this will make a bit more sense when we look at the flows here's an example of what the HTTP request might look like in this case we've taken the Refresh token the example so you'll do a post HTTP POST you will perform some sort of authorization to identify yourself as a relying party in this case we've got basic authentication so it'll probably be the client ID along with some sort of shared secret but there's other mechanisms that can be used as well like client certificates the grant type is a required field that always has to get passed through in this case it's refresh token and so the Refresh token grant type you have to pass the Refresh token and you can also optionally pass in a scope if you want to vary the authorization for this particular access token that you're generating the response will look something like this is just Jason you'll get in this case an access token and a refresh token pretty simple so we've got an even simpler endpoint up here which is the user info endpoint so there's a lot of scenarios when you're building applications where you need to know exactly who is logged in and what permissions you have so this user info endpoint will return the claims that your particular relying party is authorized to see so you'll get a subset basically of claims based on the subset of scopes that are requested and we've got those standard claims up here if you can't have a look at that later those standard scopes we looked at before depending on which ones of those that you have will give a subset the standard claims that are here and that's defined in the spec okay so the last thing to talk about with open ID connect are the different flows so when you're choosing a flow there's a few different things you need to make decisions on you need to figure out if you want an interactive or a non interactive flow so that's basically if the user involved or is that some kind of server server communication you need to figure out if you need a confidential versus a public relying party a confidential relying party being as we said someone who can be or something that can be trusted with a secret so some kind of server typically you need to figure out what credentials are being used and who should see them exactly and you need to figure out what types of tokens do you need do you need a refresh token for example in this type of scenario because you don't want a very long-lived access token being held by a client okay let's start by looking at the interactive flows these are the flows that involve an end user logging in and that authorization endpoint we talked about now there's two different things that determine which flow you would probably use and there's actually three flows so we've got the authorization code flow the implicit flow and the hybrid flow now it's worth pointing out not all of these flows are going to be available in every implementation of an agonising connect server that you have the authorization code flow does not reveal any tokens to the user agents that the end user is using so say our web browser or something like that the tokens are only existing in the confidential relying party so they're kept secret that's an important thing to think about it is possible to use Refresh tokens with that flow whereas conversely in the implicit flow you can't use refresh tokens and the user agents that the client that decide that the user is using will see the tokens and we'll show you a diagram of that in a second the hybrid flows basically the combination of the two in the hybrid flow the user agent can see the tokens but you can also use refresh latencies now if you cast your mind back to when we showed the authorization endpoint there was one parameter that we had to pass in that initial redirect call whoo come on response time the response type value determines which flow that you're using so if the value is code you're using the authorization code flow if the value is ID token or a tea token and token you're using the implicit flow and if it's a combination then you're using the hybrid flow so we thought we'd show you visually what the authorization code flow looks like basically in this scenario the confidential relying party will redirect the user through to the authorization endpoint on the identity provider the identity provider will then redirect the user back with an authorization code and the confidential relying party will then check that code at the token endpoint with the identity provider in response for in response for the actual tokens that are being used so this flow is really really useful in a number of different scenarios now there we go do it manually so we've got here an example of what hte request looks like it's pretty much exactly the same as what we showed for the Refresh token example the relying party needs to authorize itself in whatever way the grant type in this case is authorization underscore code and for that one we passed through the code parameter and in return we get the access token the ID token and if we requested it using that offline access scope the Refresh token cool so we're going to show you now what the implicit flow looks like so they called two-legged OAuth and in this particular flow this is exactly the same as what we just had accepts it and the relying party doesn't necessarily do the same thing the authorization endpoint will in this case return exactly the same tokens to the user as as in the previous example you would have needed a relying party to go get so the user themselves will own the tokens that are involved so you can see here that user still provides proof of identity they get back the access and the ID tokens directly and then they just provide that straight to the relying party in this case everyone knows about the tokens there's cases where you might not have a choice you actually might need to use this flow for example in JavaScript applications that's really common we've got here an example of what HP request looks like the important thing to note here is that you can see the hash in the URL that basically means that the server doesn't ever have to see this particular ID token it's all held purely on the client so we've got we've got the hybrid flop here's is the third flow that we want to talk about the hybrid flow is exactly the same as the implicit flow but you also have refresh tokens and you might need this in certain scenarios or again you don't want a particularly long lives access token to be held in this case you pass an authorization code as well and you can exchange that as at the relying party on the identity server in exchange for a refresh token and then use that from there cool now that we've looked at the interactive flows that involve real users you look at the non interactive flows these only involve server to server communications kind of as you'll see in a second now the first one that we will look at is something called client credentials flow so can you say yeah so in this flow the relying party will pass its credentials to the token endpoint with a grant type of client credentials and in return it will get an ID token access token and or refresh token that identifies that relying party this is useful for server to server communications where you want services calling other services in the background asynchronously and that kind of thing the cool thing about this is this means you can use your identity provider not only to identify your users but also to identify all of your servers so you can't get this added benefit is quite powerful so the next one is called resource owner credentials flow so that ten times now in this flow the relying party actually takes the credentials from the user now we've obviously been talking about how that's a really bad idea throughout this presentation but there are some circumstances in which it's still a reasonable thing to do so for instance so you've got Facebook they've created their own mobile app if you go and look at it you'll see that the username and password fields are part of the native experience is not popping up a web browser so they're not using one of the other flows they're doing something like this the reason for that is because they want to control the experience of the app and make it nice and native and they can do that because they're the ones that built the app so they know how the app handles the password doesn't siphon it off somewhere or do something dodgy and they obviously also control the identity provider on the other side however you think about a third-party company creating a mobile app that you get people to log in on behalf of their Facebook user identity there's no way Facebook is going to let you create that kind of experience so in that case that's where you have to pop up that web browser and use the other flows where you're only ever entering the credentials into the Facebook website this is an example of what the client credentials flow looks like from a HTTP point of view very similar to the other two examples we showed and really basic you just pass quite a grant type of client underscore credentials and then for the resource owner credentials flow very similar grant type of password and then you pass in the username and the password so as we said before trying to get our heads around the open ID connects back you know it's brain melting it's a very simple spec but it's still a spec there's still a lot of little aspects to it but you don't really need to know it in real depth as we said you can just pull in a library so I guess the takeaway is that we want people to get from this talk would be you know an understanding of claims based authentication knowledge about say JWT tokens understanding that open ID Connect is a thing and that you should use it for authentication rather than or what - understanding that open OD Connect has a bunch of different flows and there's a few just different decision points to choose which one that's pretty much all you need to know because from there you can probably go and have a glimpse through parts of the spec it's actually reasonably well written it's quite simple and sort of from there figure out okay in this scenario this is probably what I want to do so what we're going to try to do is to just a slight a small sorry demo of an open OD connect server just to illustrate a couple of the concepts that we just talked about so so what we've got here is on this computer we've created an identity server at localhost 4 for 399 slash identity and if you remember from the metadata slide that Matt talked about what does that mean ah that's why there's that dot move up up dot well - known slash open ID - configuration now some of the things that we see in here are things like the issuer we've got the authorization endpoint the token endpoint the user info area in point that we talked about we've got a whole bunch of other things like they're supported scopes and you've got things like the supported response types so these are all these flows we talked about like I said not all I did open a connect servers will support all of the flows this one does if you're curious this is using identity server 3 on dotnet really important URI and here is this JW KSU are I'm there so we click through on that jwkr stands for a JSON web key basically a format that allows you to describe I guess a public certificate in JSON format so all these values here represent the public certificate of the signing certificate that this identity server uses to sign JWT s so the relying party that pulls in an open ID can act library can go and hit this endpoint hit this particular URL from the endpoint grab this information and it's got everything it needs to be able to verify whether a token is intact as I said really powerful stuff so what we've got here is a JavaScript client that's going to be using implicit off against that open ID connect server that we had so we're just going to go to the network tab here and we're going to click login cool oops so as you can as we can see here when it loads type yeah ctrl long taking ages to refresh some reason as we can see here we're actually on that identity server now this is based off hitting the authorization endpoint we talked about and we've got a UI here to put a username and password in now before we do that if we just go to f12 what they're talking and it again ok cool here we go so here's an example Oh existing right is an example of hitting that authorization and point maybe just I'm out because I'm crazy so it's probably bit hard to see now but we hit that authorized endpoint we pass through a state and nonce we pass through a client ID in this case of JavaScript underscore implicit we passed a redirect URI which is HTTP localhost for 21500 slash index dot HTML and we also passed a response type of ID tokens with just asking for an ID token and we're using the implicit flow and we also pass through that required scope of open ID so it's all the stuff that we were talking about and then this particular identity server has given us this login page if we log in got it wrong dude Jimmy job yeah go for it all right for that York word if I gotta run - yeah they're working yeah okay spits buh so now we can see we got taken back to that index.html on localhost 21500 and we've got the hash test the server would never have seen this we've got the ID underscore token barely there and then a whole bunch of other stuff the Java scripts basically just showing us the parameters that were passed here so you can see we also got the scope and the stage and stuff like that now that ID token if we grab that value let me do it quite long and we go to this brilliant site called JWT - IO if you want to take any takeaways from this talk if you're working with JW T's you remember that Sykes is awesome you can paste in on the left hand side and on the right here it's decoded it for us so on the header day you can see that type we talked about we've got the x.509 thumbprint and then here we've got all of our claims so we've got that issue of local host four four three nine nine we've got the audience which is our client ID we've got the expiry time in UNIX format the nonce we had the time it was issued and the subject so that's the username that I typed in username one other thing I'd point out about GWT just scroll up you pretty much know you're dealing with the JWT you've got a Y followed by a bunch of stuff followed by a dot followed by ey followed by a bunch of stuff I live i dot for what very munch of stuff so you pretty much look for UI and then a whole heap of stuff and you typically go to JWT the reason why is because the basics default encoded version of squiggly brackets followed by a stay on quote is a way cool and so we've got here a few examples of links that you might want to go have a look at these two links at the top are a pretty complete list pretty comprehensive list of all the different implementations of Open ID connect that you can go and have a look at you've got a few different software as-a-service ones a few different self hosted ones which are basically off-the-shelf ones that you'll just set up and go with and then we've got a few examples at the bottom identity cerveteri being one of them of a service that you can set up and really customize yourself which are really really useful to have a look at useful when you want to do like a lot of custom scopes and claims and authentication kind of cool stuff like that cool and that's it thank you thank you if you want to get this slide you can go to bit ly / modern or that'll pop you off to the github where we've got the slides got any questions so what would be the keep anything so I don't really developing that using overriding correct is there is there a penalty just going yeah so the question was we've got an existing site it's done all the different libraries for Dropbox Google and Facebook or whatever it is all using oauth2 rather than open ID connect should you move across I guess it depends on whether you trust that all of those different libraries that you've pulled in don't have any security holes right because obviously there's quite a few so that every single one of those could have a hole that the others might not have right to be fair those companies are pretty big they're probably pretty robust they've been used a lot if it's working you probably don't need to touch it right there like going forward potentially use something like this because it's an easier standard next time you don't have two point five libraries you just pull in one and you're good to go right the JWT one or the summer one oh yeah yeah that'sthat's little oh and I take sec so the the slides where we're showing the flows by the way like the clicker wasn't working so to get the full effect is probably better to download the deck and make sure you look through because it's a lot easier to understand when you see it it by bit yeah sure yeah good question yeah cool really good question so the question was in the self-contained token helps of eternal time in the self-contained token example here how can the relying party know that this token is valid if it's not communicating directly to the identity provider the reason being that this this step here is what the token validation so the token formats we looked at both sam'l and JWT both have a component inside of them with a cryptographic signature that cryptographic signature is signed by either a secret key that you've exchanged previously with the identity provider or by a public/private key pair where you know what the public key is so that JW KS URL that we looked at for a open OD Connect that the public key of the certificate is using that it has a private key for that assigns the certificate so what you can do is you do the cryptographic hashing algorithm on the contents and then you can tell if the signature is different so the signature is different the token has been tampered with and thus it's not it's not safe to use right yes so you would know if the key used to sign the token that's the same key based on that registration step I talked about right that might involve exchanging ass appreciated secret key or it might involved in the case of open ad Connect going to that well-known discovery endpoint pulling out the public key and then using that key sure that's that's a fair point but that would happen like once only or in the background asynchronously if in the actual authentication flow this is it it doesn't need to talk to the identity provider because it's previously exchanged information so it knows how to verify the tokens yeah absolutely yeah so the question was and the token you know you don't know how it's been obtained you just get this token this is actually the concept called bearer tokens the bearer tokens means the person holding it just by the nature of the fact that they're holding it you can you just you have to trust it that makes sense now obviously there's circumstances where tokens might get compromised and that's where you do things like lower the lifetimes of access tokens and stuff like that so that if they do get compromised they can only be used for a certain amount of time then they're not useful anymore if that makes sense so okay so sure yeah so depending on what protocols you use there may be some protocols that allow you to use certificates in a slightly different way like potentially you present a certificate at this point and that somehow gets encoded and token in terms of Open ID Connect what you're relying on is that it's always over HTTPS and you say you trust that the token is it's very unlikely that the tokens have been compromised if that makes sense so the combination of HTTPS combined with token validation means that you generally can just trust the tokens any other questions yes so the question was to the major identity providers support this pretty much yeah I don't know top of my head of Google does but I'd be damned surprises that aren't Microsoft definitely do so pretty much yeah so it's probably all we got time for feel free to hit us up later and we can answer any questions thanks guys [Applause]

Channel: NDC Conferences

Views: 8,486

Rating: 4.9574466 out of 5

Keywords: ndc, ndc sydney, rob moore, .net, architecture, mobile

Id: X6a9bjNutEw

Length: 62min 13sec (3733 seconds)

Published: Thu Jan 19 2017