What do you want to learn? Leverged jhuang@tampa.cgsinc.com Skip to main content Pluralsight uses cookies.Learn more about your privacy Introduction to OAuth2, OpenID Connect and JSON Web Tokens (JWT) by Dominick Baier OAuth2, OpenID Connect and JWT are the new security stack for modern applications. Resume CourseBookmarkAdd to Channel Table of contents Description Transcript Exercise files Discussion Learning Check Recommended Overview Agenda Hi and welcome to introduction to OAuth2, OpenID Connect and JSON Web Tokens. That's a pretty long title but it accurately describes what we're going to do over the next approximately two hours. I want to introduce you to a set of new technologies that are designed to work together and build the security foundation for writing modern applications. So, our course of events will be that I first want to introduce you to, like give you the high-level overview of these technologies. which, which technology to use in which situation, and what the intention is how they, how they should be used and so on. And one thing that both OAuth2 and OpenID have in common is that they're dealing with so-called security tokens. And the, the, defecto standard today when building new applications is a thing called the JSON Web Token which is a security token format which is relatively new. But works very well for our use cases here. So, I'm, I going to first introduce you to debt concept. And then we have a look at OAuth2. What it's supposed to do and what it's not, not very good for. We have a look at what we call the so-called OAuth Flows that are various protocol variations. How to do the interaction between the various parties that work together in OAuth2. And afterwards we have a look at OpenID Connect which is a authentication protocol that is built on top of OAuth2. And we also have two appendixes. And one is so when you look around on the Internet you find a pretty extensive discussion on OAuth2 and its security properties. And if it's working or if it's not working and there are all kinds of opinions about that. So, I thought I should dedicate a whole appendix to that so we have a look at what these people think is good and what people think isn't good. And what's my take on that and to get a good understanding where these things fit in. And I also want to give you like a, a little further reading list and some pointers to libraries and open source projects, and so on. Stuff that you can that is useful when working with these technologies. The Security Stack for Modern Applications Overview The first module, I want to give you a quick overview. Where these technologies are actually used and how they build what I call the new security stack for modern applications. Enterprise Security So I personally come from enterprise security background, and so I spend a lot of time in my life building security features for enterprise type of applications. And, quite frankly we had this luxury of, you know, living in this in this blue triangle here. Typically an active directory where the client, machine, the user, the servers and the security infrastructure were all managed in the sense of. You know, you join this machine to the domain, and you had a number of protocols there, like Kerberos for doing the authentication, authorization part. You have LDAP, which kept your user directory together. You could assign people to roles and query information about the user. And it was all, you knoe, very, very clear how these things worked. Also, that there wasn't really a trust issue because basically this, this triangle, everything was inside of that. It's kind of a trusted subsystem, so the client machines that provisioned by the enterprise, the servers are provisioned by the enterprise, and the users, you know. There was a certain trust position. So at the moment when they joined the enterprise they got an enterprise account, so they were provisioned and, and everything was you know very clear how how things work. It become became more of a problem once we went into the scenarios of like business to business federation for example yeah? So Kerberos and LDAP are clearly protocols which are, which work really well in the intranet, but don't work at all across intranets. So, there were a number of newer protocols that we use to to, to connect outside resources. Either that our internal employees could do single sign on, for example, to external websites. Or that external process or services yeah could could talk to our internal services. And that was the whole era of the WS staff specifications like WS security WS trust WS federation. Or the SML protocol or the SML token type. Obviously this was all around XML and soap. And we could make these things work business to business, because in business scenarios both ends of the environment are typically tightly controlled, and with a certain amount of negotiations they could work together. The Mobile Revolution But suddenly this happened. A completely new form factor of personal computer hit the market. And that was obviously the smartphone or mobile revolution, and after that obviously the tablets that, that followed them. And these devices were kind of a game changer, yeah. So they didn't care about ender price at all, they were at first at least consumer devices. They didn't have these enterprise stacks like soap and SAML and WS stein. What they have HDP and Jason and you know, they are really good at, at what, what, what they are. also, the company that you know, produced them they din't you know, didn't have much of enterprise back on at all. And that was fine for people, as I said. At first, they were considered like, yeah, they are consumer devices, but as we all know, these consumer devices kind of, they're brought into the enterprise scenario so they're typically from management, down to, you know, the information worker. And they they changed the market. Yeah. So when I talk today to customers, there is not a single customer who's says like, oh well we don't care about mobile devices. Yeah. It's typically that maybe mobile device are not their, their their main focus or maybe, maybe not right now. But they certainly know that at some point you know, that there might be more mobile devices out there than desktop computers, maybe there are all ready. So based on the fact that we have these devices there are at least two but I want to point out two very, very common scenarios, and that shows now why they are business critical. Mobile Enterprise Apps So first of all, is obviously the mobile enterprise applications. So meaning that now suddenly, you want to use these type of devices to connect to your mobile sorry, to your enterprise services. You know that might be like for example like, like someone that wants to, you know, walk around with this mobile thing, and accept the access enterprise data or maybe, you know, at day time, they are in the domain. but, and you know, this, this guy leaves leaves the, leaves the building, puts his mobile device in his pocket, and suddenly he lives outside of that, you know, that magic triangle which, you know, just took care of everything for us in, in, in the, in the past. So very very typical scenarios Basically like accessing like, data on the road for example, or you know, querying services which live inside of your enterprise. OAuth2 for Authorization So, what is OAuth good for? So, OAuth is about authorization or delegated authorization and the idea is you're writing an application, and that application needs to access some sort of backend service. Now the way this works is, or the way this could work. Like when we think of, you know traditional enterprise scenarios is, you're writing the applications. You popup like a log on dialog for example, and you collect the users password for example. This might work if you know the client and the service, and the authentication. They all come from the same vendor. Like, like in the way it was in enterprise systems. But now that we are talking about a multitude of client platforms, talking to a multitude of back end services. And even a multitude of authentication providers. I can also think of you know things like Facebook logins and Google logins and so on, we want to motilzarize that a little bit more. And also that means that maybe you are using a client application that wasn't written by the same company that is providing the back end services. So do you really want to give that client application your password? Or do you want to use something you know that you only type in the password into the backend system and this somehow makes it happen that the application can access that. So that is OAuth2. So OAuth2 is about requesting so called access tokens from an authorization server, and then you can use the access tokens to talk to a backend service. OpenID Connect for Authentication OpenID Connect is, it solves a different problem, and it's about authentication. So, the idea is that maybe this, this application doesn't need to talk to a back-end service. At least not in the first place. So what, but, but it needs to know who the user is, so. In OpenID Connect you're doing an, a round trip to a so-called authentication server, you type in the password at the authentication server and this returns a token back to the client application that allows it, to validate, your identity. And maybe at some point later, they're using OAuth to get another token to talk to a vacant service, but that, you know, out of two distinct a use case this year. Open a deconnect off indication OAuth for delegating authorization. Summary You've seen that basically, the security landscape is changing and a big part of that is the, the fact that people are using more and more mobile devices these days, which don't have support for this, you know. This old school kind of heavy, protocols like SAML and WS star and and all these things. And also, where I said in the beginning that we, we could use these older protocols very well for business to business, for business to customer they are not really an option. So I guess what, what it all boils down to is that after after we realize that, and after we know that these mobile devices are really also very good at, you know, doing HTP, for example, and JASON and all these things, we need new, new common denominator technologies That work really well what these devices to offer. So, for example, HTML 5 is, is, is a good example. So people use more and more HTML 5 and JavaScript and CSS as as a technology to write client applications. Why? Because they work on almost any platform without code changes. And the same happened to the authentication, authorization story. We're now using protocols and techniques that work well both with desktop devices and laptop, but also on the small form factors like mobiles and, and smartphones and, and tablets. And these are basically OAuth for authorization open or deconnect for authentication and chasing them token as the, as the token format that we sent back and forth. JSON Web Tokens (JWT) Overview Let's start with a quick look at JSON web token. As I said, JSON Web Tokens are an emerging standard. They are very close to its standardization. IETF has taken care of that, and OpenID connect mandates the use of JSON Web token for all of the tokens that are exchanged in that protocol. And OAF two, isn't mandated, but as I said most implementations these days use JSON Web Token. So let's have a look at them first. So, I want to give you a little indu, overview of the purpose of security tokens, and, and what other types of tokens we have out there and where, where they are used. Then we have a look at the structure of a JSON Web Token, and then I want to quickly show you how easy it is to create and consume them using development framework. The Purpose of Security Tokens So the purpose of a security token is really to produce a data structure that contains information about the issuer and about maybe the recipient and about the subject that this token describes. So think of an authentication operation where you sign in somewhere and the authentication server sends back to the application a token that describes your identity. And that obviously must be protected so nobody can tamper with that and change its contents. So this tokens are in addition typically signed. Depending on the technology you either sign them symmetrically or asymmetrically. And signing also fulfills the, the, the need or the purpose of making them authentic, meaning the recipient of that token wants to make sure it is coming from a trusted source. Because only when you trust the issuer of the token you can also trust the contents of the token the, the claims typically that that are in, inside of the token. Tokens typically contain an, an expiration time, so you know, they only have a limited validity Depending on, on the scenario, this might be something like a work day, like ten hour, for example, in in, that's very common in for example. Or maybe with access tokens, they are very short-lived like something like, like an hour or even shorter. To minimize the window well, like for example a stolen token could be abused. So tokens are very, very important, they are key aspects to all of, all of the protocols in the security space. So, a client, a client, which is an application, requests the token, an issuer issues a token and a resource consumes a token. And obviously, a, as I said earlier, the resource, typically some web API, has a trust relationship with the issuer of the token, meaning they had some a priori key exchange. So, the consumer knows about the key that the, the issuer uses for signing the token and can use that key to validate the token and if that validation succeeds, the the resource can use the claims inside of the token. History There are historically a number of tokens that we were using. The one that's not on this slide is, is a Kerberos service ticket. I am I skipped that here, but strictly speaking also in Kerberos we have we, we pass around security tokens. But the term security token became much more popular in WS star or SAML space. So, the most the most popular and most widely used security token today, is certainly the SAML token, the security assertion markup language token, there are two flavors to version 1.1, and version 2.0. They are XML based and they have many, many options on how you can encrypt them and sign them and they're very expressive. And, you need typically a pretty advanced XML stack to be able to parse and produce them because it's not only XML there's also schema involved there is XML encryption involved, which is a pretty complicated standard. There is XML digital signatures involved and so on. So in the area where you had all this powerful a SOAP and XML engine, like in WCF for example. These are very, very popular tokens. Now, as I said earlier and in, in the la, in the last module these newer devices, like mobile devices for example, they don't really have these advanced XML stacks anymore. So, one token type that was created in die, as a direct, you know, reaction to making SAML much, much more simpler was the Simple Web Token. This was a joined venture by Microsoft, Google, and Yahoo. And they took a very, very simple approach. They basically used key value pairs for claims, form URL encoded them, and only provided as a part for symmetric signatures. Now, it turned out that these tokens were a little too simply, so we need a little bit more of the SAML features. And we need a little bit more cryptographic options because symmetric signatures, they just don't scale very well once the systems become more, more complicated. So, from tak, taking the experience of SAML, what is good about SAML, and what was missing in the Simple Web Tokens. There was the idea that came up with the JSON Web Token or the chart as many say. And the JSON Web Token, the idea is that you are encoding the token using JSON and that that's very beneficial because you will find that JSON path on, on almost every platform and even if there is no path it's really simple to pass them. You could pass them manually by hand that wouldn't be too hard. But also I gue, I guess one of the big features is that since JSON is the native format in in JavaScript, and JavaScript becomes a much more important language these days it's also very easy to use from JavaScript, which is a plus for many people. The next thing is they agreed on a number of cryptographic algorithms that can be used for signing and for encryption. Not as many as you could use in SAML because that is really an open model here. But you know, some, some that make sense and there is HMAC SHA for symmetric signatures and elliptic curves and RSA for asymmetric signatures. And we have RSA and AES CGM which is an authenticated encryption algorithm to do encryption. So it's less complicated than SAML, but more advanced than Simple Web Tokens and that it seems to hit the sweet spot for many people, so just became pretty quickly, quickly the standard token type to use for many of these interactions and that's what we are going to use here as well. JWT Structure and Format So how does the JSON Web Token look like? It basically has two parts one is the header which provides some metadata and some information about which algorithms and which keys are used for, for doing the cryptographic operations, and it has a number of it has claims just generally speaking, yeah. There is claims fall into two ar, areas one are reserved claims. That, that su, so, some of them you are seeing here on the slide and then you can have application defined claims that you can freely define. But really important token charts token basically at least have an issuer claim so the recipient knows where the token is coming from. It has an audience claim, so the recipient knows that he is really the right recipient for the token and not someone else. Here they typically have an IssuedAt claim, which tells the recipient when the token was issued, an Expiration claim telling the recipient when the token has expired, and the Subject claim, which is basically like an identifier of the entity that this token describes, like a UserID for example. And you, and you see also that they're using abbreviations like iss for Issuer or Audience--- aud for Audience. So, another intent of this JSON Web Token format is to keep these token sizes really small, so you can use them in mobile scenarios very well. This is the structure of a sample JSON Web Token. You can see on top we have the header section. So you see that it's a chart, so that can be used for versioning. And the algorithm says here that we are using an HMAC SHA-256 to assign the token. Now in the claims section you see some of the claims I just talked about like the issuer, the expiration that's epoch time by the way. Meaning you're taking the number of seconds from the first January of 1970. So that's the way they get around all the different date time encodings on cross platform. You have the audience. You have the sub check alice in this case. Then we have a claim called client, so that could be useful for example, in OAF when you want to know which application requested that token. And you have something called scopes which also again is something which is useful in OAF to do authorization, as we will see later in the OAF module. But as I said you can put in whatever claims you want here. And then we have a way to serialize that token and as you can see at the bottom, you basically take the header part Base64 URL encoded, we'll take the claims part Base64 URL encode. And then you'll take this string with the dot in the middle and you run the signature algorithm acro, over that string and depend the Base64 URL encoded signature at the end with a dot. And that's how you transmit JSON Web Tokens. So that's quite simple especially if you compare that to how SAML tokens work. Producing and Consuming JWTs So how would you produce a token? I will point you to more libraries in, in the appendix, but if you are a .NET developer the most obvious one you would use is, is the one from Microsoft. So there's a Microsoft library on NuGet that implements JSON Web Token handling. And as you can see, there a class called JSON Web Token, SecurityToken, or JWTSecurityToken. And you pass in the claims that I talked about earlier, so like the Issuer claim, the Audience claim, claims that describe the subject. You tell the class what's the signing credential, you tell them that the validFrom, validTo thing. And then you can use a class called the JWTSecurityTokenHandler to serialize the token. And then you can just transmit that via arbitrary means. Yeah? So. You could put on a, on a, on a header in an HTP request, you could put it on the, in the query string you know, you could even put it in, into a cookie. It, it, it doesn't really matter. It's, it's just a string now, that you can pass around in your system in a very flexible way. Now the consumer of that token, he would just you know retrieve that cell last string, as I said from wherever you put it on. The most common thing obviously, would be in the HTP header. And to validate a token, you basically just read that string, you, you put it back into this short security token class. You set some validation parameter, for example, I, I expect the issuer to be myIssuer, I expect your audience to be myResource and that is the signing key that you, that that, the class should use to validate the signature. And then again you can use the, the chart security chart in handler class call of elevate a token on that and get back a claims principle containing all the claims in, in, in the token and that includes the reserved claims like issuer, audience, expiration, and so on plus the claims describing the subject. So that is, that is really easy. And there are, in the meantime, there are now libraries for all platforms like Java and PHP and, and Node and so on, that can deal with JSON Web Tokens. Summary I want to get that out of the way, so, so whenever I say token in this in this training here, I always mean JSON Web Tokens, as a data they are the defectors standards that are used by O Auth and opener deconnect. At least for the, for the more modern implementation. You see given its format, it's simply a string. Its relatively easy to create transmit pass and validate those chart tokens. You have good library support. And all of that combined make them the obvious choice these days for, for tokens. That there are other token types out there and I will put some links to them in, in, into the resources appendix but given the bigger implementations today like Microsoft and, and Google and and these types of companies really the top form of data we can use. And as I said already in OpenIDconnect they also specify the chart as, as the only token type they, they support. Introduction to OAuth2 Overview In this module I want to introduce you to OAuth2. The OAuth2 is pretty popular at least the term. And there's also a, a lot of confusion, what OAuth2 is about and what it's good for and what it's not good for and so I really want to clear up with that here in this module will tell you, a little bit of the history, of OAuth2, its goals and long goals, and what are so called OAuth flows. History So what is OAuth2? So when you go to the OAuth website, it says an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications and there's also a link to read the specification. And when you click that link you see the lower part here of the slide. You come to an RFC like an official, you know, request for common document from the IETF, called the OAuth 2.0 authorization framework. So it's about authorization. It's about giving access or controlling access to resources. Now, OAuth has a, has a little bit of history. So we are already as the name says in OAuth2 so it, it's version two of the OAuth specification. And there, there was a version one OAuth1 that started around 2007. And it was really a way to solve some, some of the delegation and authorization problems we had back in the days. And Google, for example, was, was a big driver of the protocol, and it went to the IETF in 2008 and became an RFC 58 49 in 2010, for that was OAuth 1.0. And OAuth 1.0 as I said was all about solving the authorization problem, and we'll talk in, in much more detail what is authorization problem really is here. But it had some, some, weird constraints by the time so for example the the people that that build OAuth one they worked on a hosting company which didn't support SSL for example there. So the whole OAuth one protocol couldn't rely on any sort of transport protection, which us made them introduce pretty heavy crypto to rebuild some of the protection features. The other thing was that OAuth 1.0 was designed to work with PHP 4, for example, which also had some constraints and, In the end, OAuth 1 0 was more complicated than its authors wanted it to be. But again it worked. But there were other companies later on, like Microsoft, Yahoo, and Google which tried to simplify things. And they came up with WRAP, Web Resource Authorization Profiles. And that was supposed to be an extension to OAuth to make some things eas, some things easier, for example introducing bearer tokens and again we'll talk about what bearer tokens are in much more detail later on. But just in general there was a desire to simplify OAuth and that was the whole reason the work started on OAuth 2.0 in the 2010. Now, off to our. It's a bit, a bit controversial, because the, the main editor involved at some point redraw from all of its duties and and let o wanted the committee to basically remove his name from all specifications because he just wasn't happy with the, with the results. And the reason for that is, I guess that OAuth gained so much direction that more and more companies want to be part in this standardization process. So You had suddenly here, you had all the big players there like Google, Microsoft, Facebook and GitHub and Twitter, and you know all, all of the, all of the big companies went to these IETF meetings and I mean that's more or less the point, yeah, of, of having these standardization committees. But it turned out that OAuth became more complicated. Then it had to be because you know, not, not, not, not, not from a technical point of view but that all these companies had their, their own little ideas how things could work. Or should work to support their use cases. And so the OAuth 2 spec became pretty big, and there are a lot of variations now to the spec. And, Aaron Hammer, who, who is the original lead off and editor didn't like that and, as I said, resigned from all of his duties and also, you know, wro, wrote a couple of blog posts, which became very popular, and that's the reason why there's a bit of controversy around if OAuth is really a good protocol or not. So part of the reason why, OAuth has such a bad reputation is because it took so long to standardize meaning that all of the bigger players they are they just started to implement OAuth you know, at some point in the process. Yeah like the final specification had 32 revisions, for example, and, you know, some companies implemented OAuth at revision, you know, 13, for example, and some at, you know, 20, and some at 23. Obviously, this led to many incompatible implementations and this also lead to implementations which were from a security point of view, not mature at all, and if you look at this list here, Facebook and Twitter and, Github, for example, they were all, you know, hacked at some point in the process. I guess Facebook and Facebook being the most popular especially while, because it take us, IETF there OAuth implementation. So, in October 2012, OAuth 2 was finally signed off, and when, when they found another guy that took over the lead of responsibility, so he signed off the last revision and it became RFC at this time 6749 and there's an accompanying RFC 675o. That describes baratoken usage. So do I think that OAuth tool is insecure? We have a separate appendix for that, appendix A. Where I look at all the arguments that, that people made especially author Aaron Hemmer who wrote the spec and we look at what this really means for you. Then you can make up your own mind if, if you think, you want to use that or not. OAuth2 Overview So, from a high level overview the problem OAuth wants to solve is pretty simple. There's a human that uses some piece of software, maybe you know a browser based application, a desktop application, a mobile application and he wants to access data. Now when you first read the OAuth spec there's a pretty important distinction that you have to understand. So the spec talks about clients and resource owners. And again when you're coming from an enterprise background, yeah, as I said earlier, like, like me for example I did never....I didn't ever make a distinction between resource owners and clients because, you know, from an enterprise point of view, they are the same thing, yeah. The they are both owned by the enterprise, if you like, and they are they are trusted, but when we talk more about this multiple Multiple application apps and client platforms, you may run into situations where a trusted user they're like a resource owner may run an application to access your back end which is not written by yourself but coming from a certain party so the interesting part in o office that they take the, the software that human the resource owner uses into account. And this that software that client or the platform the client is running on since they take that into account can also have varying trust levels. So this is a very important distinction here. So whenever you, you read the word client in the spec they mean the software that is used to access the, the backend data. And the resource owner is the human that owns the backend data, or at least, where the, that the backend data is associated with. So, that's an important distinction. The Valet Parking Analogy There's also a nice story around it. And that's from Aaron Hammer, the original editor that I just mentioned. And also there's a book on O'Reilly like that introduces OAuth 2. And they, they use an interesting or a very easy to remember analogy to the real world. So I guess many of you notice this movie here, Ferris Bueller's Day Off, and the whole idea here is that you know, Ferris and his friends take a day off from school and they basically steal Daddy's really, really expensive and important Ferrari and in in the States, for those who are from the States, you all, you obviously know that but those who aren't, there's this thing called valet parking where you go to a garage or a restaurant, wherever and you give someone that, you know, might be of differing trust the key to your car and so he will park it. Yeah? So the idea is obviously that you give this key into good hands, and they will take care of parking the car and when you are done, with whatever you are doing, like with your dinner or something, they, they get the car for you and you don't have to worry about parking against the wall. obviously, in this movie what happened is that this guy t took the key to the car and they made a little road trip, which obviously wasn't the intention. But the problem here is really that you or in that case Ferris and his friends they own the resource which is the Ferrari and they gave that Ferrari to a third party which in speak would be the client. Or the and to, to use that resource the Ferrari that the client the valet parking guy he had to give him some sort of you know, access key, and that is, that was the master key to that car. So with, with that key, you can do whatever you want with the resource. Now, more, more expensive cars in, in the States these days, have two sets of keys. One is called the well, the normal key and one is called the valet parking key. And the valet parking key has limited access to the car's resources. For example, you can only drive a limited amount of miles with that key. You can't open the trunk. You can't open, you know, the glove department, and so on. So, bringing that to, to our, computer world. You see that there are, there are two types of keys, the master key that is the, that gives you full control to a resource. That could be your password for example, to your, you know, your Twitter account, or your, your, your, your domain password, yeah? And that's also the valet parking key which gives you limited access to a resource. And the whole idea of OAuth 2 is how can you or how can we create the valet parking key In an electronic transaction. So, in other words, how can the resource owner give the client a key to access the resources on the clients, sorry, on the resource's behalf, without giving the client a master key, a-k-a, a password. So, so that's the whole intention of OAuth. That's may sound a little abstract but we'll get to that. The Players The OAuth 2 players, so when we look at the protocol are really four players here. One is the resource owner, obviously that's the human. And that owns the resource on a resource server. Then we also have a thing called the Authorization Server, and that is the piece of software which can issue these limited keys, the valet-parking keys, and we have the clients. So, clients in, in these newer architectures come in, in in more shapes and forms as we might be used to them. So, there are typically the so called trusted clients and the idea of a trusted client is that they are built by the same party that also builds the resource server and the authorization server. Think of standard or classic enterprise software. But there mi, might be also no partially trusted clients where a third party builds the client, meaning that you might not have the same amount of control over the you know, the, the quality process of the software, for example. Then there are other things called the, the confidential and public clients. So public clients are typically it's client software which runs on client devices, yeah. For something like a mobile phone or a tablet or even a laptop and confidential clients are typically clients which are implemented as server side software where you have much more control over the security. So the resource owner uses some sort of client to access the, the resource on his behalf. Now, to be able to access that resource it needs to have a key, or an access key, now an access token. Think of the, the car. Now, since we don't want to give that, that client our master key we can use this authorization server component in OAuth2 to give us limited access keys or like the valet parking key. So, the way this works is that we are using what they call the OAuth Flow to talk to the authorization server, we allow access to the client for our resource. And then the authorization server keeps gifted. Gives that client a limited access key, and with that key the client can access our resource. That sounds very complicated and the first time you'll, you'll read up on the spec or on the protocol, it is complicated but believe me it, it gets easier quite quickly. So, Interesting here is what trusts So, by default, resource server and authorization server, they belong together, okay, so that the authorization server knows about the resources that you want to protect. And on the other on the other side, the resource server knows the, the, the, or knows how to validate the limited access keys, the access tokens, coming from the authorization server. So there, that's a very tight coupling between the resource server and the authorization server. Obviously the resource owner and the resource server have a trust relationship with each other. Since the resource owner uses the services of that resource server. And you see that by default, the client is not necessarily part of any trust zone, yeah? You can make him part of a trust zone. For example, in the trusted client scenario. But you don't have to. So you can always treat the client, if you want to, as partially trusted. And that's, I guess, the, the big thing that makes the, that does OAuth differently to the enterprise protocols like, you know, WS-Trust for example, where the client was implicitly always a trusted client. OAuth2 Flows Since OAuth is supposed to work with many different types of clients, there are so called flows which describe how a client together with the resource owner can access tokens from the authorization server. And I guess the most classic one is called the authorization code flow, which is built from an applications and of, of, for classical server ran that, that applications. For the more native or user agent based scenarios, there's a thing called the implicit flow. Now I, I call these two flows with user indirection, and that basically mean that there must be a human involved at some point that basically allows, explicitly allows access for the client to the resource. And we'll see in the next module, in much more detail how it works. And there are two more flows, I call them no user interaction because basically um, there is no separate authorization stage in the sense of that a human must give consent to some resource access, and that is called resource owner password credential flow, which basically means that, that is what comes closest to enterprise style of software with w trust, where the. Where the client application itself collects the credentials of the user, the master key, where there is no limited access key involved here and can use that to access the resource. And the last flow is called Client Credential Flow and that is really for client to service communication so there is no resource owner involved at all. So you can see the results on a password flow use the resource owner credentials to get access to a resource, whereas in the client credential flow, we use client credentials. So also applications can be forced to authenticate in OAuth. Again, we'll have a look at all these flows in much more detail in the next module. But just to give you an overview. There are four flows involved here and they are made for different scenarios for applications. Summary First, to summarize that, O-Auth is about delegated authorization, meaning you want to authorize a client. And that's a piece of software to access your resources on your behalf. Okay? So, the piece of software that actually does the resource access is taken into account here, and it's always the combination of resource owner and client that make up the resultant access token. With factoring out the component that does these authorization decision, like which client, with which resource owner, gets access to which you know part of our applications we, we a thing called the authorization server and this makes it much more easier to uh, manage these kind of security interactions when you have multiple clients. So again think of classic enterprise security There was typically one client application talking to the back end but with these app style architectures you might have you know you might have your internet version of that application. You might have a mobile one. You might have something in the app store that talks to a limited set of public end points and so on. So, so, so to make to, make this client management more feasible we have a thing called the authorization server. And as I already mentioned before, the spec is quite new so we are really working with very new technology here, which often means there's a bit of discussion around, certain part of the spec if they make sense or not. And I, I have summarized these discussion points in Appendix A so I can highly recommend going through that after you understood the basic OAuth concepts. OAuth2 Flows Overview Intro level I want to talk about the various workflow in much more detail and how they work and in which situations you want to use them. So we, talk about the authorization flow, the implicit flow, the resource owner credential flow and the client credential flow. Code Flow: Authorization Request Now the most classic flow of them all is the so called authorization code flow and the idea here is that we are talking about clients which are server rendered that applications. Meaning, you're going, you're opening the browser going to some application, and the application wants to access a resource that you own but you don't want to give that the application the password to that resource, while you want to use own of two retrieve an access token for that. Now the way this works is so that application can gain access to the resource that you own, it does a redirect to the so called authorization server. And you see here that this redirect here we're using a certain query string format here so you can see there's this thing called the client ID. That is basically the name of the client that's trying to access the results and clients are needed to be registered at your authorized server so there's a step zero, if you want. Where the client needs to register with the authorization server and from that point on it can make these interactions, so it is hey, I am the web app. I need, I want to gain access to a resource called resource, that's the scope parameter here, and when you are done call me back on this redirect line that I am providing here And what you, what, what this authorizations, whatever is sent back on, on that callback URI is a, a so-called authorization code, as we will see in a second. And there's also the state parameter, which is optional, but very recommended. And that it's basically that the client comes up with a random number. Stores that locally so that when the call back comes back under redirect uri the authorization server should send the state back so it can correlate the, the response so you can make sure that this this call back is really A result of the request you're making, so that's basically for a cross side request for protection. So, what happens now, when this get request arrives in your authorization server, is a number of things. The first of all, if the user is not already authenticated with the authorization server, he has to authenticate because otherwise the authorization server cannot know who the resource owner is, and cannot make any security decisions. So I, I'm using the Google, the Google implementation here as an example, because I think the Google implementation is one of the best OAuth implementations out there right now. So the, the user has to authenticate and the next thing is the so-called consent screen. So, what you see here is now, you see which, which client here, which application is making that request. And that in, in that case is, is Feedly which is a blog reader. And this blog reader wants to have access a, basic information about the, the user on Google like his name and URL and photo. And also access to his Google Reader data so it can show the blogs, the blogs and the, the posts. So the content screen really says like okay Dominique listen, here's an application called Feedly and it needs access to that data. Do you want to allow that access? And then you press allow, or no thanks. Okay? And when you press allow, then basically the authorization server will take care of giving this access token to Feedly so it can access my, my blogs. That's another example of a content screen. That's how Twitter, for example, does it. They combine the log on and the consent into a single screen. And you can also see that the application says, this will be able to read your tweets and see who you follow and update your profile, but it will not be able to see your Twitter password. So that's the whole idea, you give some client access to a resource you own without disclosing your password. That's a, that's an exam from Evernote, for example which is, is quite a nice content screen I think, or at least I like this feature that you can by default limit access to a certain amount of time. So for example in that scenario here you can say like if this application only access for one year, or shorter or longer. So, even when I forget about it, access, for in that, in that case BubbleBrowser, to my Evernote notes, will expire automatically as opposed to vice versa where you need to you know, manually rather revoke the access than renew it. So the consent screen is really, really important if you are building an authorization server yourself, you should put a lot of thought into your consent screen. It should be really, really obvious what this application is asking for. Which types of permissions and also who the application is thought as you can read here on, on this URL. That, that there's a guy who, who talks about the importance of consent screens and he used that Photoshopped example here, and I also showed that consent screen to a number of people. And it turns out that, some of them just take a raw because they kind of think they know what they are clicking to but, when you're closely reading the text here you might not really agree with what the application is doing. So that's a non-technical problem but if you are building more authorization servers you should make these consent screens really, really easy to understand for the users because actually when you click Allow, that's what you get. The authorization server will make it happen to give that application the,, the requested permissions. Okay. So let's assume the user has clicked allow, so then the authorization server will redirect back to the callback uri, presenting the application with a so called authorization code. That is not the actual access token, we first send an authorization so on the client so because that authorization code gets transmitted wire the user agent. We don't, transmit the ex token itself so it, it, doesn't leak over, over the agent, but only a so called code. And, and you can see that the state parameter is, is echoed back so that the client application can do it's antique cross-fire request measurement. Code Flow: Token Request For the last step here is that the client application, now has a direct communication between the Authorization Server and the Client Application. The Client Application has to authenticate with the Authorization Server, that, that credentials, get exchanged as part of the initial registration process I talked about earlier. And then the, the client application sends the authorization code to the authorization server that we've just seen. And then when the authorization server's happy with the, with the code, and makes sure that this is actually the application that requested authorization in the first place, and all these, you know, extra security checks that you have to implement. Then, the application sorry, the authorization server sends back a token response. And as you can see in this token response there are two types of tokens. One is the so called access token, that's a short-lived token that expires in, in this case, one hour, that's expires in it's the number of seconds this thing is good for. And a longer lived token, the so called refresh token. And the refresh token is optional and I'll tell about it in a second but with the access token now, the application, the client, can now access the resource server, so we see that here in this step. Code Flow: Access and Refresh Token But as you see as you can see the access token is short lived, one hour here. So what does the application do when the access token has expired? Well, it could start that round trip again to the authorization server and again the, the user gives confidence. One, that would be one option. Or there's this content of a so called refresh token. And the refresh token the idea is that this is a long lift token that the application can use to request new access tokens. So what would an access token look like? Well typically it would first of all, it obviously, contains things like the expiration date and the signature. And the issuer name and is one name, but it also typically contains things about the resource owner identifier for, like, who is the human on which we have that access is taken care of. Typically you would have a client identifier inside of that so you know which client actually does the request. You have something called scopes. So meaning for example you can say like in the scope parameter on the way in, you can say like I need read access to my Twitter feed or write access or I, I want to modify the profile, things like that. So again the, the user has consented to these permissions, so you put them in the token so the resource server actually knows the, the things that the user has allowed. Yeah. And you, you can put in anything else that makes sense to your application. And as I said, if that access token has expired and you enabled refresh tokens for that client, then the client can basically post the refresh token to the authorization server and can get back a new access token. So that's, that's a way how you can a, extend access over the short-lived access token lifetime. And also grant the application offline access to the, to the resource, like, for example, you know, the, the, the user shuts down the browser. But the web application in the background does some sort of batch processing on top of the resource data. So it can you know, maintain access to the result server. It can use the Refresh Token feature to get new tokens. Code Flow: Client Management Once the application has a Refresh Token, it basically can access the results forever and that's also something we typically don't want. So, what many authorization servers implement is kind of a self-service way, how the, the resource owner can revoke access again for the client application. So let's say, for example, in, in, in, that concrete example here, I gave, the Adobe PhotoShop Light Room application access to my Flickr album. And if I, at some point decided that I don't want it anymore, that PhotoShop can post to my Flickr album, I can click the remove permission button here which technically means that the Refresh Token gets deleted from Flickr's database. So, after now the short lift exit tone has expired, there's no way to get a new token for LightRoom in that case. And, that, that is very common practice, so that is for example how it looks at Dropbox. So, also Dropbox has this concept of you know, connecting applications that have access to the Dropbox resource on your behalf yeah. Or that is how it looks with Microsoft where you can give certain applications access to to your Microsoft account data like yeah, applications, for example. Code Flow: Summary Okay, so that's, the code flow, again, this is basically the way how server rendered web applications would use OAuth to orchestrate, the token request and token usage. Yeah? It's, it's designed for server applications. And that application is typically the, the client, the client, which is the web application has a user name and a password that he, that it can use to authenticate on the authorization server that it can use to refresh the access token once the, the short-lived token has expired. From a security point of view this is really good because the access token never is leaked to the client or the user agent. And everything is happening on a, on a potentially tightly secured sever environment. So this is this is the so called code flow and very commonly used in web applications. Code Flow: Demo Let me show you an example of the OAuth code flow. So this here is a client a vet client, and you can see here's a link to start an authorization handshake. And that is really It, to the, the round trip to the authorize endpoint. So you can see when you look at the bottom, the URL there's basically the client ID, just the scope of the resource we're trying to access just to redirect you And the response type equals code. So when I click that I get from the authorization server. Since I haven't logged on yet, I, I need to authenticate, and after I successfully authenticated there's the Consent Screen. So you can see whether such like that this thing called the cold flow client is requesting resource on your behalf. The resource name is that API security sample. And this here the client will be able to access the resource even when you're offline basically gives the hint that here are refresh tokens used, so I can say allow access. Now, the authorization server sends me back the authorization code into the client, and now I can exchange the authorization code with the actual access token. Okay. So you can see now that we have the access token, we, see the expiration and here, here's the refresh token. So now, as the last step, I can call the service, and basically the service echoes back the contents of the token, which has things like the audience, the issuer. Not before expiration, name, authentication method and so on. So the, the contents of the token is really up to you, in this case. There's might be more in it, then it might be actually, you know necessary. We can also click the renew token here, and then we making the round trip to the authorization servers, sending the refresh token and getting back a new access token, and in that case also a new refresh token. That's again, up to the implementation of the authorization server, if you make the refresh token one time, use only, or can reuse it. If you look at the page source you can also see here's the, the, actual access token, so let's copy that. There's a useful website and I will put the link into the reference appendix. But, this allows to decode so when you want to, when you play around with them, it's sometimes quite useful that you can look inside the tokens and they do the decoding for you. And you can see that basically here we have the same claims that our resource service I code back. Okay? So, another thing I want to show you is, let's go to the authorization server here, go to the administration, and then go to users and here, you, or, at least, the admin can see are there any tokens, that can be revoked. So I can go to the code slow sample and search and indeed, there are some tokens. One is from today, one is an older one. So, so what I just did is I basically deleted all the refresh tokens for that, for that user. So now we effectively revoked access for the client to the to the back end so the client can still call the service. But as soon as the access token has expired, once it tries to renew the token, this will fail. Okay, so that's the, the life cycle, if you want, yeah? And the client asks for authorization, the user grants authorization. We get back an access token and the refresh token. The returned access token can be used as long as the access token is valid and then it can be refreshed within the refresh token. And in the meanwhile, at any point, a client can revoke access by basically invalidating the refresh token. And from that point on, the client application can't access the data anymore, and has to go again through the consent cycle to get a new access token. Implicit Flow The next flow I want to talk about is the so called Implicit Flow and this is a very, very common scenario meaning that you're having applications which run completely locally, on the client device. That might be a native application, like something you've written you know in objective c on an rs device. But also more and more common are the, the like a packaged applications, like JavaScript applications, which run inside, inside of a user agent on a client device, which are, you know, very much like local clients, but they and not written natively. Now again we have the same challenge here, this, this this local application wants to access a resource on behalf of the resource owner. And again you might not be happy as the resource owner, to give that native or local application your master key or key your password, yeah. Think of think, think of a Twitter application for example, there are so many Twitter applications out there, Twitter clients which don't come from Twitter, so you, you don't really know what they're doing with your password. Like, are they storing that securely on, on my device? Or is it somewhere stored in clear text what happens if I lose my device. So in other words the Implicit Flow again, enables this scenario, where you don't have to give your master key to the application, but rather to the authorization server. And declined application, can retrieve an access token and can use the access token to access your resource. So again, the way this works is very similar to, to the code flow. The client application needs to be able to show that, that page, namely the authorization server, login, and Implicit Flow. And that is typically done by either popping up browser or by embedding a lep few into the application. I'm pretty sure you have seen that before on your mobile device that when either browser shows up and renders some log in or the login UIO shows up in line with the application. And again basically you pass in a gate request into this webview browser that goes to the authorize end point. un, again you specify which application we're talking about at this time, it's called the native app, you specify the scope meaning which resources you want to have access to. You specify a redirect URI, where the resource to authorization server goes back to after that is done. And this time, which is a little bit different, you don't specify a code here, but a token. Meaning we don't get back an access code here that we have to exchange using our credentials, but we get back the token directly. And the state parameter has the same purpose again as in the previous flow. Now once the user has clicked the allow access button this time the access token comes back directly inside the callback. So you see here that, that as, that to get to the callback, and you embed the access token as parameters on that URL. So we have the access token, we have the expires in, and we have the state and remember, an, and note the little difference here. We don't have a callback question mark, we have a callback hash, and that, that is called hash fragment encoded. Meaning these, that URL or, or this parameters on the URL will never be sent to some server. So the idea is that now, let, let's say, on the client you would, you would click a link, for example, these the access token wouldn't show up in, in the referrer, for example on the on, on, on, on the linked target, for example. So, to, today, I'm everything that's after the hash fragment is meant for local consumption and doesn't get sent to a server by a browser or a web view. So that is some, some protection that the token doesn't leak to a third party, for example. And then after that again, the client application uses that access token to, to request access to a resource, basically by, by putting it on your authorization header of the outgoing HTP request. So, you've seen that this flow is, is a simplified version, really, of, of the, the code flow. So there is no authorization code here, the token is exposed to the browser and the local operating system. So there are some security concerns here as well and since the client does not authenticate with the authorization server, to get the token, we also typically don't provide refresh tokens here. Because otherwise there would be no way to control the access to the refresh token and so on. Yeah so, and the, the, the other question would be, why doesn't the client authenticate to the authorization? That's because well then, that, that would mean we had to stall the client's credentials on the device, and again, that is a of questionable security if we have to install credentials on a client device that we can't control. There are situations where that might make sense, but that is more like in the area where you were, where you type the control to client hardware and operating system platform, but let's, let's say for the public and for a pubic app scenario, there's not a lot of good scenarios where you want to store hard coded client credentials on the, on the device. Now, since arguably this is a very common application scenario, yah? Like you're building a mobile application that needs access to a back end resource. And you don't want to give that application the master key. But refresh tokens are per spec not allowed here. Many people have build you know, variations of that flow and I put I put nonstandard here in quotation marks because the standard itself already provides a high number of variations. So, many people just, you know, push the, the boundaries or the limits in one or the other direction to make it work for their scenario. But for example, Google doesn't allow Google doesn't use refresh tokens but they use hidden iFrames to do the consent handshake again. So, in other words there, they using cookies which is, is some sort a refresh token, but yeah. So, there, there are many variations to that flow and this is actually the, the most heavily debated flow as well especially to its security properties, yeah. To spec does says exactly what I'm saying here. No client of indication, no refresh tokens, but there are situations where you want to have refresh tokens. And the way they are implemented is either using refresh tokens and breaking the spec or some other companies get around it by using other creative means like hidden web views to be fresh. The access tokens and then have a, a finite lifetime on the cookie that is used in the webview. So you have to re-authentic, like every two weeks, that is, for example, what Google is doing, yeah? You're getting, some sort of experience. But, you have to re-authenticate at a certain amount, after a certain amount of time. Just to make sure that if your device got stolen, for example, that you don't have, you know, unlimited access tokens on that device. Implicit Flow: Demo This is an example of the OAuth implicit flow. I'm using a Windows 8 store application here, and the reason I'm doing that is because I want to show you that Microsoft actually built operating system APIs now into Windows 8 to do this O, OAuth authorization server interaction. So, I've written a little method here, which is called DoImplicitFlowAsync, and I'm basically constructing my uri here. You see that client ID scope will redirect uri, I mean, nothing, nothing new here, yep. But what's interesting here is this class, the VIP Authentication Broker, that is actually a Vin RT API. So I basically can call, authenticate Async, pass in some options. Pass in the uri that I just constructed, and then Windows 8 will open a webview which is in a protected container. So my client application doesn't have access to, for example keystrokes in that container and so on. It also doesn't have access to the cookies, the, the, the cookie container's actually a separate one from the normal internet explorer cookie container at least by default. So, it, it's basically an operating system created webview that has some security features as well. And then, when we get back a success, that is called meaning, or we redirect your hit, then we get passed back the query string, and then we can extract the access token from that, and use that to talk to our resource server. Now the nice thing is now we can now store this access token using other Windows 8 API's locally on the machine or even roaming to other trusted computers. So let's say you are logging into this service on your windows 8 you know, tablet and, you're moving to your laptop and you don't have to re-authenticate and can you know, continue where you, where you left off. So that's quite nice so let me let me show you that. So the first time you run the application you see we don't have an access token here. So we can't even sign in, now this is triggering this round trip to the authorization server that is basically now the webview that I just described. So we sign in here, now we get to the consent screen, so, again Windows 8 Client, that, that is the same consent screen that we've just seen, With the code flow and we say allow access and you see now that what the application gives back is JSON token. And now I can call the service and I'm fine. So when I now close the application and at some later point come back and the token is still valid, you know, it's still here. I can call service and I don't have to re-authenticate and if I would have to re-authenticate again, I could say, use some of the of the techniques that I described earlier like popping up the authentication again. And maybe we maintain a cookie to the authorization service, so we don't have to type in the password again. There are other variations how we do that, but that would be one option. So, as I said, and as often is indicated, is another operating system, level API. So there are other applications which use of that as well, much as my own little sample here. So when you download the official Twitter application, you see they're doing exactly the same thing. Yeah, they are opening this web view here and rendering the consent as /log on screen in that case. So you I could sign in here now, and then, given my credentials are correct I can say authorize app, and from that point on, the application can use or can show me my twitter stream, and what, what activity to, to that line is doing. But the point is I didn't give that twitter application my path directly. It went via the implicit flow to the twitter back end and it will return, ultimately return a back end access token. Resource Owner Credentials Flow The resource owner password credential flow is typically what is considered for trusted applications, or even trusted devises. So the idea is, again, you have like some sort of client that might be a, that application client, that might be a client application like a, like a local device installed client application, that needs access to the resource. But this time the client application itself collects the credentials and not the authorization server. Okay. So, the scenario here is that you actually trust that client application so much that you want to type in your password into the client application and not in the authorization server's log-in URL, okay? That basically means that you are trusting the client application. You are maybe trusting the manufacturer of the client application, which might be your employer, for example, so that's fine. Because you are accessing a company resource, and you are also, I guess, trusting the developers of these, of the client application, that they you know, take certain responsibility to not store that password in, in clear text on the device, stuff like that. So in other words, you give your client application, your, your masterkey directly and you assume that it is in good hands. The way this works is that we skip the authorization and point altogether. And directly talk to the token end point, you see where we're going to talk end point here, the client application authenticates with the authorization server again. This assumes that the device, this thing is running on it's considered trusted enough that it, you can store client credentials here. You directly pass in the in the password of the user, and the, the name of the user, into this post request, you pass in the scope that you want to get access to. And what you get back, again, is the standard award of token response, the access token, the refresh token, and so on. Now, actually, you know, given a well written application that only collects the, the user's password at the first time of the login. Then it goes to the authorization and exchanges it directly with an access token and then forgets the password forever. That is much better than, than actually storing the password on the client device. So, this is a useful flow for scenarios yeah, so the application collects your password, it sends it to the authorization server, the authorization server sends you back an access token and then, you store the access token and the refresh token and forget about the client's password altogether. That is much better than actually storing that password, and then, after that of course the declined application can ask the resource and can refresh the token once the access token has expired. So this is, also a useful flow for many situations, you should just be aware that now the resource owner credentials are exposed to the client. And typically we shouldn't educate users to type in their password in too many applications, right? So, the rule of thumb is that they should be educated to just type in their password into their company's you know, logon UI. Yeah, like, like to think that the authorization server uses to authenticate the user, but that's not always possible. And obviously if users become too accustomed to typing in their password in to many UI's then that can become a phishing problem, so yeah we should limit usage of that flow to the right amount of applications, whatever that means yeah. And as I said earlier I still think it's better to to use that flow even if the user type's independently inclined, then to you know, so we can exchange the password with an access token refresh token then you know storing the raw password. Given that the developer is actually using that feature and that is part of the trust decision, right so we are trusting that application being stored locally on our device. You know, it's, it's maybe coming from our company, it's coming from a trusted third party. So we also trust the develop, the developer is using, the features in the right way, so he doesn't store that password but uses the access token refresh token feature. Resource Owner Credentials Flow: Demo There's an example of the resource owner password flow. There's a .NET C# application. Or you know test client and you can see we are basically having this this very typical two legs here. One is requesting the token from the authorization server, and one is recalling the service using that token. So let's have a look at the request token, method. So, I'm using something from something from Thinktecture Identity model and the link to that is in the, is in the resources appendix called the OAuth2Client. Basically what you pass in is the URL right to the OAuth2Token and point the Client name and the Client Secret and then we can request an access token using, the resource owner name, and resource owner password and the scope we want to access. What this thing does essentially is really nothing rocket science, it just creates a, a form URL encoded post body, sends that to the token endpoint, and passes The response back into a class called response and then from thought access token we can access the access token. There is also a thought refresh token and a thought expires in, and so on. Now, how to we call the service? We have the token as a string here. We are creating an HP client. Again, this little extension method comes from think texture identity model and just sets the authorization header with a scheme of bearer and that puts that token on the authorization header, and then we are just calling an end point. And again what this end pint is doing is it echoes back the, the claims that came, that the token contains. So when I round this, you can see that first we are requesting the token that is the round trip to the authorization server. Then we are calling the service and again we have here claims expiration issuer, audience, name of the name of the user, and other things the authorization server put into this access token. Just to show you, there's the official dropbox client for Windows. And it uses exactly the same approach here so. Again the, the whole idea of the results owner password flow is that the client application itself brings up a login UI, you type in name and password, and then under the covers, they're doing the resource owner flow. To the authorization server, exchange that password and name with an excess token and refresh token, and then can forget about the name and the password. And that, that's okay because, you know, that is the official DropBox client, so, I guess it's okay for them to say hey, you know, we know your password anyway so you can also type it into our client interface. Client Flow The last flow is the so called client credentials flow. That is really for machine to machine communication when there is no human involved at all. So you can see that basically here, the client goes to the token endpoint of the authorization server, authenticates itself here, but not resource owner is involved here. So basically that is the equivalent of, of, you know, classic service to service communication or client to service communication. And obviously the, the resulting token that will get issued here, also has no user meaning the client can never act on behalf of a user here, can, but can only act on behalf of itself. So that's again, you know, classic two silicon based lifeforms need to communicate, no carbon involved. Summary So to sort of summarize that, you've seen that the OAuth flows are really variations of how you can orchestrate the communication with the authorization server and the resource server for various application scenarios. Typically there are two parts of an OAuth2 communication. One is where authorization gets requested. So when a human is involved, that's where the human has to sign in, go through the content screens, say, it's okay, I allow application X to access my resources. And to read operation and write operation and you know, change my email addresses, you know, that's totally application defined. But the point is that a human gives permission you know, in a, in an, in an interaction for that client. And after this, this, this, this permission has been recorded by the authorization sever, then the, the, the client can do a direct communication with the token endpoint on the authorization server to request the, the corresponding access tokens. Now, you've seen that there were some variations one is the code flow where there's, there's in- intermediary code. Authorization code used to provide better accountability. One is the implicit flow, where they conflated your authorization and token round trip into a single one, because there are no client credentials involved. And there is also the resource owner flow where the password actually gets typed into the client application as opposed to the authorization server. And there's the client credential flow with is for service to service communication. And you basically pick and choose what, you know, is the, the best flow for your application scenario. Obviously the one that is heavily debated right now is the Implicit Flow because they are many variations how to do that. And again the Oath specification which cause itself a framework really gives you some you know, space for interpretation here really. There's also a separate specification which I didn't explicitly talk about called RFC 6750. And that is basically the thing that describes, once the client has got the token from the authorization server, how it can be transmitted to the actual resource server. That is, yeah, not very complicated. I skipped that part here, but typically what you do is you put that access token on the authorization header of an HTP request and then send it to the resource server. OpenID Connect Overview So, now we want to talk about OpenID Connect. So, OpenID Connect is really a specification that fits on top of OAuth2. Meaning it reuses its message format, like the query string format, like how token responses look like. But to implement authentication. Now you might wonder, why do I need a separate specification for that? And I first want to introduce you to why OAuth2 on its own is not enough for authentication. Then I want to show you what OpenID Connect adds to OAuth2 to make authentication secure. And then again, I want to show you or walk you through a typical OpenID Connect Flow, how to do authentication. OAuth2 and Authentication When you're reading the spec they make it very, very clear that OAuth is for authorization, or especially, they call it delegated authorization. And by now, we know what that means, yeah? We want to give an application access to a third party resource on your behalf. So, we are delegating an access token. So, we are delegating access and authorization decision AK the content view is involved so that the access token can hold information for the resource server can do access control what this application can do your behalf, yeah? So, that is delegated authorization and that is frankly not an easy to understand concept, yeah? It's, it, it the first time I, I read the spec, or maybe the first three times, maybe even five times I read that spec, my, my head really hurt, at the end, yeah? But thing about it, that's a very, very common scenario given this multi-apps, multi-client architectures we are doing today. But sometimes you just need, well, just in quotation marks because authentication is a really tough to solve problem. But maybe you, you don't need this access token thing for your back-end, because maybe you don't want to talk to a back-end, at least not in the first place. You just want to know who the user is so you can, you know, personalize the UI for him Or control access to application features which are built into the application. And I guess we've all seen this button, Sign in with Facebook, Sign in with Google. And, you know, that is what many people really want to implement and do the delegated authorization step, maybe as a second thing later in the application. But first of all, they want to know who the user is. Now, OAuth is regularly abused for that. And I'm saying abused because OAuth on its own, like what, what you'll find in spec doesn't have enough features to do that securely. and, I, added here two links which are really important to read that tell you many, many of the details why OAuth is not good enough. And I will show the main things here as well, but this gives you more information. The Problems With OAuth2 Authentication Let me quickly walk you through how OAuth if naively, or can be naively, used to do authentication. just to make it really clear. So, that is basically we are using the implicit flow here because it has more problems than the code flow. But think of it like this. An application wants to authenticate the user. So, basically it does a round trip to the authorize endpoint of, of two authorize endpoint, yeah? Says I'm the native app and they, they come up with some, you know, application defined scope for the authorization server nodes. This is not about authorization, yeah? This is about authentication, so some, some called the scope sign in, for example, yeah? That is that is you know, application defined. And the response type is, is a token meaning you get back a token for that user. Now, since OAuth is an authorization protocol, what they are really asking for here is that the user gives access to a so-called user info endpoint, yeah? And the user info endpoint is the thing that knows about what's the user's name and, you know, his email address, and other stuff like that. But the way people abuse OAuth is by saying, if I'm able to get an access token for the user info endpoint from the authorization server, the user must be authenticated somehow, yeah? So, in the second step, we get back the access token for the user info endpoint. And then the application uses the user info endpoint to fetch additional information about that user. Now, the problem here is that we didn't really do authentication at least not we ourselves, we just used some third party to give us an access token for an endpoint. And the access token for the endpoint and the authentication event are not really correlated with each other, yeah? So that leads to an interesting that, that leads to two interesting problems here really. First of all the user info endpoint is always like an application specific thing. So, Facebook has its own user info endpoint. Google has its own user info endpoint. And Twitter has its own user info endpoint. So basically depending on with whom you want to do authentication, you need to understand the semantics of their specific user info endpoint, which is bad for compatibility. But the much more, the bigger problem here is a security problem. So, think of this scenario here. You are basically using some malicious app, yeah? That might be a malicious web application. That might be a malicious application on your desktop or on your mobile device. And you start it and it says, like do you want to log in using Facebook, for example? I'm using Facebook here because that was a real problem with Facebook and you can read up on that in some of the links I provide you. And, you know, being a good, you know, a well education user, you say like, oh I won't give you know, this partially trusted application my, my Facebook password. Or, you know, some other password because, you know, I read about a threats on the Internet and I don't want to do that. So, what is application offers is you can login using Facebook, and you think like, oh, that's much better because now I type in my, my credentials into Facebook. And, you know, I have an existing, trusting relationship with Facebook, so that, that is okay. So, but what actually happens is as we've seen on the previous slide, mow what actually happens is that with these credentials, the malicious application gets back an access token to your user info endpoint, okay? So, now what this malicious application developer can do, is he goes to a legitimate application and just exchanges your valid access token or, or saying differently, he basically swaps out some access token with your access token. Now from the point of view of this valid application, this legitimate application, you've been impersonated, okay? So, so the application sees a token coming back from a trusted source, AK Facebook, for a trusted resource, AK the Facebook user endpoint. And there's no way the application can distwing, distinguish between the token that resulted from what the user just typed in into Facebook authorization server and a forged token from you know, a forged transmission of credentials, okay? So, that is the big problem with OAuth for authentication. And that is what many, many of these OAuth providers suffer from. So, as I said, Facebook had this problem, for example. And all of these companies that provide authentication based on OAuth had to add some protocol variations to it. Like extra token validation checks, for example, and so on. And it turned out that all of these protocol variations, A; made them incompatible and B; brought them much closer to what we call OpenID Connect anyway. So, they kind of implemented OpenID Connect you know, like, like in homegrown implementations to make it more secure. Now, the problem is now, that OAuth authentication is a very popular thing to do. And there are also, you know, like third party libraries, for example, that do away with all the incompatibility. So they know, for example, that you know, if the Facebook user info input works a little bit differently than the Google one. And they know that Facebook has added this extra, you know, protocol feature to make it more secure. Which basically, you know, brings us into a situation where we have to specifically write code for every OAuth provider to support their little flavor of authentication that they are providing. And also to use their extra security measures, because the raw OAuth flow is not good enough for authentication, as you've just seen. OpenID Connect What most of them are really doing, I just alluded to that, is something called OpenID Connect. So, when you go, for example, to the Google's API documentation page they said that yeah we use OAuth 2.0 for Login. But hold on, we are actually doing OpenID Connect but we, we're not calling it that way because we don't want to confuse people, okay? So, in other words OAuth2 itself is not good enough for authentication. You can make it good enough for authentication, but that involves two things. One is the user info endpoint. That should be in some sort of standard format. And one is the introduction of an extra token type, and that is all specified by OpenID Connect. So, OpenID Connect is a specification that is, that basically aims at the target that you don't need to know any specifics about the authentication provider A priori. Like you've just seen the screen that I've shown you from OAuth IO, they have support for 50 plus providers. The idea of Open, ID connect is that you don't need to have special case support for providers, because they are compatible with each other. So, Open, OpenID Connect builds on top of OAuth. They, they use the authorization code flow for server based applications and the implicit flow for client based applications. They add some, they add some constraints to OAuth2 as well. They, they add some new concepts like the user info endpoint I just talked about, and a new token type called the ID token which I'll show you in a second what that exactly is. And they added some, some other additional features which are missing from the OAuth core spec, like, for example, how can you discover an, an OpenID Connect provider. How can you a dynamically with an Open OpenID Connect provider. And also when we're talking about log in, we also need to talk about session management. So, for example, how do we log out again? And again, session management is not part at all of OAuth. So again, we need that that extra spec that is very, very similar to WS Federation, federated sign out or single sign out in, in the sample protocol for example, we just need these features. OpenID Code Flow So, let me show you the OpenID Connect Players. So you've seen here we have the user agent and the client. So, there's always a user agent involved. And either that's a browser, like a classical browser for Web applications, or it's of a few that is used in conjunction with a client application, like a native application or a, you know, a user agent based application. And you have the authorization endpoint and the token endpoint, and we know them already from OAuth. So, I said OpenID Connect is building on top of OAuth. So, when now an application like a client wants to initiate authentication, what it does is, it uses the standard OAuth messages to talk to an authorization endpoint. And the mindset here is really, do you want to allow the client to get access to your user profile and that includes authentication. So, when we're doing a get request to the authorized endpoint. We are passing in the client ID. We are passing in the callback URI. And now what OAuth does is it defines scopes. So, an OpenID Connect request must start with a scope called OpenID. And then there are more things you can attach to that, like profile or e-mail, and I have a table later on that it shows you which types of values you can put in there. But OpenID profile means that you get access to the user's profile, like first name, last name, email address, and these things. Then, response time equals code, meaning we're doing the code flow here, and the state parameters again for anti CSRF attacks. Now, if the user is not authenticated already, then we need to make a round trip to the IDP. And again, just for reference here, these are the values of the scopes, like profile, email, address, phone and offline access, which means refresh token. Then again they are all specified in the OpenID Connect specification. But much more importantly, if the user is not authenticated, now we are making the round trip to the identity provider, and again, the user types in his user name and password into a UI. Now when authentication has succeeded, the consent screen is shown, just like in extended OAuth. And as I said, the mindset here is really like, do you want to allow this application called WebApp access to your profile? And if you click Yes here, you get back the authorization code. And then you use the authorization code to get a token response. So again, declined authenticates with the token endpoint using his client id and secret passes in the authorization code. And when all that security checks have succeeded we get back, the token response. And now, you see here, there's something special. For the access token is the standard OAuth access token, which is basically, which can be used to talk to the user info endpoint. So, nothing special here with regards to OAuth2. Just the refresh token, which gives you longer lived access to the user info endpoint. But, there's a special token now called the ID token, and that one was missing from from the naive OAuth authentication implementations I showed you earlier. So the ID token is really a token that is meant for the client. So the client the client's responsibility is now to immediately validate this ID token. And what's inside of the ID token? Well, basically, there are four very important claims. A, where does the token come from? So, does it come from the OpenID Connect provider I just talked to. The subject identifies the user. The audience identifies for whom this token is for, and this token must be for the client that initiated the request. So, that allows the client to make sure that this token is actually for his own application. That was a feature that was missing in the naive implementation I showed you at the beginning. And obviously an expiration, so, you know, these tokens cannot be, kept alive forever. And the token is signed, obviously. And the client must validate the token, at this point. So, once the client has validated the ID token, he knows that the response that came back from the authorization server was actually really for his own application and is basically a fresh interaction because there's an expiration value involved, and so on and so forth. So basically this, this is the, the very, very important extra feature that OpenID Connect adds on top of OAuth. So, we can really do authentication and not just, you know, assume once we get back some token from the authorization server, then authentication must have succeeded. But we cannot check it. With the ID token, we can really validate that authentication succeeded. And that, you know, all, all of the players are the ones, are legitimate, and not some, you know, part got substituted in the process. Okay, so now, once we know that the response was legitimate we already know that's a very important point here. If you already know who the user is. That's the subject claim, yeah? And if, if that's all we need to know, like having a unique handle for that user, then we are done. But if we want to know more about a user, like his first name, last name, and so on, then you would go to user info endpoint. Would use the access token to access the user info endpoint and get back the additional profile information about the user. So, so that's OpenID Connect the authorization code flow. There's also an im, an implicit flow, which works exactly the same as the implicit flow with OAuth 2. Just adding the ID token user info endpoint to the mix. And that's basically how OpenID Connect works. And you can, you can see then I deliberately draw these different players into separate boxes, like the identity provider, the authorization endpoint and so on because OpenID allows you to basically separate them. So, like the identity provider could be like an Intranet server whereas the authorization endpoint is accessible for from the Internet or the user info endpoint and so on. Which also allows you, or allows for architectures where the credential database is separate from the profile database, for example. Okay, so, the last, really last step now would be the user info response. And again, this is a standardized format meaning the claims here, sub, name, email, they are, they are specified by OpenID Connect and the idea is that you simply get back a JSON encoded name value pair that includes the profile information. Summary You've seen that OpenID Connect builds on top of OAuth2. Adds a number of extra features, like standard scopes and claims. Like, that the token type is fixed to chart. The ID token concept is something they added as a standard spec component, and the user info endpoint, yeah? And the idea as, as, as I said earlier, is that once this all is in place, your application, you know, can use arbitrary OpenID Connect providers to authenticate without you having to write extra or special case code. Li, like it, it works today with OAuth2 authentication because there's no standard how to do authentication with OAuth2. OpenID Connect is not yet done. At least you know, there are a number of specs that make up OpenID Connect. One is called the basic profile. That is pretty stable now and it's, it's expected to not change substantially anymore until the spec is done. There are additional specs which are still under heavy development especially the things like dynamic registration. Discovery, and session management, and so on. But, yeah, going forward, for Internet-based applications OpenID Connect is the new protocol to do authentication. And, in the long term, will replace WS Federation, WS-Trust, and, similar 2p. OAuth2 Concerns Overview In the introduction I said that there's kind of a discussion going on right now about OAuth2 and that discussion was mainly triggered by the fact that the lead editor Aaron Hammer, left. The committee and was really, really vocal about the fact that he wants his name to be removed from the spec. And, and frankly had some, had some good arguments why the OAuth spec is not as good as it could be. This led to as I said a big discussion about the, the usefulness and the security properties of OAuth. And I want to, present you some of these, these points here and, how you should deal with them. Eran Hammer Aaron did this, quite famous, presentation at RealTime Conf. last year, where he said like, I am done with OAuth and here's why And he basically took a, or made a variation of the original logo and turned it into a little bit of a you know, a road kill cat. And he wrote a number of Pretty good, recommended, blog posts. Where he says, what he thinks is wrong with the OAuth 2 specification. And that, mainly, involves things like, he wasn't happy with the, the token format. And the lack of signatures. And, and, especially the around, this specification. And, Even if I don't agree with all of his points, or at least, you have to qualify them a little bit, I would recommend that you read all these blog posts, you look, you watch the video, and make sure you understand his points, yeah, because, I mean, they are valid points. But obviously also he looked at all of them a little bit from a doomsday scenario because basically he was not happy with, that he spent like three years and the result of that was that he left the committee because he couldn't stand it anymore. So here you maybe have to you know qualify them a little bit if these things apply to your environment. That, I guess, is an important point here. Specification Bloat One of his biggest complaints is that the whole specification is not really a specification any more. So you can see, in the upper part, the whole thing started as something called the Web Authorization Protocol, which you know has some semantics to it. You had a protocol. A protocol means that it's a very strict definition. And if everybody implements the protocol, then everybody is inter operable with each other. I told you earlier that because gain that that much traction that more and more companies got interested in that. And you know, when more and more companies sit together and everybody has its own ideas how things work, then we end up with a lot of variations. And for those people who did work with ws star or ws death star as many called them, they know what I'm talking about. Yeah, it's like You get very many you know, alternatives how to implement it up to a point where it is not a protocol anymore. But and that's what, what happened. They renamed it 2 D 0 off to authorization framework and you know, that is different, because now we have the framework to build protocols. And if you ever read a specification, you know that what they are qualifying that with, that, they're, they're using this special annotations like something should be implemented, something must be implemented, and something may be implemented, Yeah. And just, just to give you an idea, I, I searched the overall specifications for the word May, and found 69 hits. And here's a very A nice example that, that illustrates the problem here is they say like clients in possession of a secret may use HTTP basic authentication, or they may use some other authentication mechanism, or as you can see at, at the bottom, they may transmit their credentials as part of the payload. And that is that illustrates very nicely the problem of the specification. There is no basic profile in the sense of where you select, when you do this, this, this and this you have a good of implementation. There's no guidance whatsoever when you would use this or the other variation. And I guess worst part here is, that if you would, word by word implement the specification, you would ultimately end up with an insecure implementation, because you know, some of the, the maze here Obviously for devices which have lower security standards, or where you have, you know, where there is no use in direction. Possible where you can send a header around for example, ____ so I guess what I want to say here is You can't implement the specification because it is not a specification anymore. It's a framework. You have to find your own of things that you want to complement and then you turn it into a protocol, but the protocol is your protocol and not a standardized protocol any more. So, that, that, is not, the end of the world because they're talking about authorization here which is already very application specific but still I think that's a missed opportunity and there's much, much, room for you know, improvement. There should be in my opinion an 0 of 2. OA specification, or at, at least something like a basic profile, where they narrow down the choice, or basically don't give you any choices but select. Do it like this, and you have like a secure baseline implementation. This doesn't exist maybe it's coming, I hope so. But for now you are basically on your own here. Which also means that there are a number of you know, specifications out there that, that, that, are, that work together. Yeah? Like the OAuth2 authorization framework is just the core. And that's a proposed standard and that's the OAuth2 bearer token usage, which is describes how you use the access tokens to talk to a resource server. Then there's the threat model and security considerations, which I can highly recommend reading if you ever want to do any work, you find lots of good information in the threat model. That is totally missing from the core, specifications, and obviously Oauth sits on top of, you know, things like, ideas like tokens. We need to talk about Jason Lip token. Jason Lip token is again specified in at least 4 specifications. One is the core bond and we talk about encryptions algorithms. Then, on top of all of two there are additional specifications like the assertion framework which is highly debated. The short and error token profiles which was basically made for enterprise scenarios. Revocation of tokens. Mac tokens is one of the things I want to talk about in a second. And then we have things like dynamic registration and delegation that, that whole slew of extra specifications which, which don't make it easier and in my opinion, they should first get the core specifications straight. And then build on top of that and that is one of Aaron's main complaints, that there's a big bloat, especially the enterprise bloat in there which, you know, was not his intention right from the start and there's open ID connect sitting on top of that where again his point again is why didn't we just implement. Often the occasion features directly in OAuth by do we need to have this huge additional specification and again in in his mind that is politically motivated and maybe he's right I don't know but you know that's where much of his criticism is coming from because the spec that he was working on for many years could be so much better than it is and I agree. Bearer Tokens The next thing, is the concept of bearer tokens. So, what's a bearer token? Basically, a bearer token is, when you are requesting a token from an authorization server, then you can use that token to, authorize access to a, to a resource. But if that bearer token gets stolen from the cable, for example like, like by eavesdropping for example, That attacker can also use the error token to impersonate you. Or in other words, the, the token is not somehow bound to the HTTP request you are doing. So for example, in in we have this concept of, that you embed A key into the sender token. And you trans, you, you put that key once in the sender token and once to send it back to the client. And now the client can use this key to sign the request he's making, making to the resource server. And on the receiving end, the resource server can look inside the token. Retrieve that key, which is encrypted. And validate the signature. So in other words, the, the token alone wouldn't be enough to re, to, to craft new requests to the resource server. Now, again, Aaron was a big proponent of the of the, having additional effort to send a token along, then just bearer tokens, and again this is missing from the initial documents. The standards document is still up there, there's not much progress right now as far as I can tell. But right now we are stuck with bearer tokens, meaning the only, we have to put all of our security in one basket, meaning we have to protect the transport. And that means bearer tokens can only be securely transmitted if we are using SSL, and. Historically, developers and SL are not always you know, like you know, working perfectly together. So, for, for example, when you google form, just kind of easy to answer the question, how to handle SL validation error? What you get is many entries that talk about how to ignore SSL validation errors and obviously what that means is you are building an application that relies only on SSL to securely transmit tokens but you're not doing proper SSL checks. So think of this Scenario for example, where you are sitting with your tablet, or with your mobile device or with your laptop, in, in a hotel or in, you know, at an airport, or in, you know like a coffee shop whatever, and you are requesting a token and you are sending the token and. Actually, what you're doing is here you're just getting a man in the middle attack because someone next, you know, next door or somewhere in the same network, basically you reroute your traffic via his machine He gives you a fake SSL certificate on the fly but the declined application doesn't notice that because it turned of SSL checking. In other words this this man in the middle basically was able to steal your tokens or your password even. Yeah. And now can impersonate you. This wouldn't be so easy with what is called mac tokens for example where as I said earlier there's a separate signature involved that Makes the Tokens on their own useless, but only with this knowledge of this secret sign in key that was established, much, much earlier than the actual token. The token can be used. That is one part of the problem that developers still, Get SSL wrong, and that is especially the case when you are leaving the you know the secure realm of your admin controlled intranet where you know, the wild wild west of, of the internet and that is also a problem because. SSL is often also bypassed on the infrastructure level these days. So, for example, this was a big story from Nokia, where they, for their mobile devices they decrypted the SSL traffic in their back end so they could do things like optimization or caching and compression, and so on. And then re-encrypted it and sent it along. yeah, I mean, Nokia says, we, we decrypt your data but don't worry about it. The thing is that your pair of tokens will travel in clear while Nokia is doing that for example and again, could be stolen by you know, the disgruntled employees scenario for example. Stuff like that. So And I'm not saying that Nokia's doing that. I'm just saying that there are, there are many ways where SSL might not be end to end for your scenario. Like, when you are going through anything intermediary. When you are like in this case this one might be one. Or when your developers are not careful enough and ignore the SL errors like by swallowing an exception. Or for .NET developers there's the service point manager that you should never use in production. So yeah there are token's hefty problems. Again this is not the end of the world. But room for improvement for the SSL, for the spec. Security Theater The next, big point here, is now we're going through all these hoops here to, to show the web view and to show, you know, like the look and UI of your authorization server. And the contents screen as one. That's all good and fine for a applications. But for native applications, this might be a little bit of security theater. If you are not familiar with the term security theater. That is a thing that was popularly coined by Bruce Schnia. For example, after the, the, 911 attacks in New York, there were you know the army guarding the streets in the evening with machine guns and these machine guns didn't have bullets in it. So just, just to give people a secure feeling there was the army with you know big guns making sure the streets of New York are secure. In fact, you know, they didn't even have bullets in there, in there, in their gun You know that is, that is called security theater that, giving people a secure feeling and where in fact there's nothing extra secure here. Okay? So and, and the same goes for this yeah, this, this embedded browser scenarios, yeah? Like, you are seeing the screen here. It has the Google logo on it. Yeah, it says sign in. But, you know, a client application that you locally installed on your client device is showing that screen. And who is stopping them to basically just you know, spoof the Google log in? Screen, like showing you a window which looks like the Google screen, but in fact they're just harvesting your password. Or, and someone recently said to me, like, wouldn't it be much better if instead of showing that web view, they're showing a real browser. So I can have a look here, it's the Facebook dot com website, and. There's a little, you know, green padlock here so I can make sure it's really Facebook. And the point is, if the application is installed locally on your client, nobody stops the application from drawing a window which looks exactly like your browser. And which holds the Facebook log in UI. So again, you can never be 100% sure that on your client device, you know, something evil is going on in the sense that of that they are spoofing a log on UI. Yeah, but the point is really you installed that application on your client device, so that was already a trust decision you made, yeah? So, so one part of the discussion around is that's all this thing make sense or wouldn't it be much, much better if everybody was using the resource on their password flow. Giving that application the password, and, you know, since we are trusting the application, otherwise I wouldn't have installed it on our device, we, we just believe that the user is not storing the password, but storing the access token instead. You know. I think, my opinion here is. It's still, it's still useful to use the, the web fuse style approach because then the, the client developer doesn't need to deal at all with passwords. Yeah? And doesn't you know can't do anything wrong with that but obviously just because the Google UI is popping up or the Facebook UI is popping up You can't be 100% sure that this is really Facebook or Google you know. That doesn't mean you can run untrusted software and nothing will happen. So, yeah, just keep that in mind that you know There might be still spoof eyes out there. OAuth can't save you. OAuth just provides the framework how the tokens can be requested or the passwords could be transmitted. Attack Surface Ta-da, a big point of criticism here and that goes especially out to people who implement authorization service is that OAuth has quite a big attack surface. That this, that this isn't necessarily re, required. But the spec kind of steers you in that direction. So let's have a look at the authorized request in two. So you have to specify whose the client, where to go to after the consent is done. Which we source to excess, and which type of response you want to get back, okay? So and give that, you know, these are all part of the query string you're sending to the authorization server. Obviously what an attacker would do is he would start manipulating. These values here. Like what would, for example, happen if I do a, a roundtrip to the authorization server. But, as a redirect URI, I give them my web server and not the one that belongs to the application. So, that's now the authorization sent that access token to my, my server, so I can, I can harvest them from a legitimate user, for example, using a phishing attack. Or can I request access to scope, which I don't have access to, for example just by manipulating the scope. parameter, or can I have maybe turned er, a response of type authorization code into responsive type token for example. So In other words, there are many input parameters into the 2 protocol and, you have to make sure when you're implementing this authorization endpoint that you're validating them very thoroughly. So, typically what you do is when you research the client You all to register one or a set of valid redirect URI's. So, in other words, you wouldn't send the token to an arbitrary URI, it must be one of the pre-registered URI's for that client application. Typically, you also have, must have Some sort of access control around which client can request access to which resources. And you should also have an around which client can access which response types, or can request which response types. So in other words you basically must do very thorough input validation. And you need to have kind of a, a registration system for clients. But you can configure all these things very specifically. And then only allow the values That you have configured up to a point where in most real world implement, implementations I did, the only thing you really needed was, was the client id because everything else was already fixed. But, you know, you have to pass other values here. Also, make, make sure you think the state parameter. Otherwise again you would be open to sea surf attacks like phishing for example. At the bottom you can see a number of blog post. Some are from me. Some are from a guy named EqualHomocoast which did a lot of work with OAuth. Especially breaking it. One example here is it's around Facebook. As the Facebook was hacked quite frequently, because they're doing kind of relaxed input validation on the input parameter. So for example, to give an example one attack they did is so, when you register a client at Facebook, and can you that by, on Apps dot, no develop at Facebook.com. They only want to know the, the server name for the root, root directory And the, the, the whole URL portion after the server name is up to you. So for example they make sure the redirector URI is going to Facebook dot com but not to which page on Facebook dot com. So what this Igor Homokof found is basically a page on Facebook that has a vulnerability. So basically he would send a link to someone. This guy logged in, the, the, the redirect URI was going to this page on Facebook which had a cross site script vulnerability. And this basically used send the token to a third party website. So he could steal tokens from other people using, basically just the problem that Facebook was not properly validating the redirect URI, or was too relaxed to do that. And, you know, there are many, many variations of that attack, like trying to down create to token based responses. Whereas an authorization code was, should be requested, stuff like that. It all boils down to people have done OAuth implementations and didn't do proper input validation or Allow too many variations of the spec. Summary So to summarize that, in my opinion the OAuth2 approach is useful for many of the typical applications we build today. And I'm deliberately saying it very carefully here, the approach, Because, as I already told you, the specification is not a specification in the sense of that it gives you clear directions how to do things. It's a framework. They changed the name to a framework because that's what it is, yeah. But Even if you would forget about OAuth2 and would build some of the interactions today without knowledge of OAuth2, you would end up with something like OAuth2, at least for some of the scenarios. Yeah? So, so in other words, what I like, how I look at OAuth2 these days. It, it's more like An inspiration now how to architect certain types of in directions. And it helps once you understand what you're doing to use the o of two terminology. So you know we're talking about the same thing now. Unfortunately it is not as strict as I would like it to be. So I think this the Spec definitely needs refinement. So the basic profile I mentioned earlier where it gives you like, a very, very clear idea what to implement and what not. And I also would like to see a, a specification for MAC tokens so we can get away from tokens if we have mm, higher security requirements. And maybe want to run on environments where we cannot always rely on SSL being perfectly implemented. I guess also the fact that the spec is so lax and that there are so many iterations of the spec is also the reason why many of the implementations I have seen are lacking on one area or the other. And that also applies to the big guy's implementations. I mentioned Facebook several times. Let alone the many, many do it yourself implementations. And that's another kind of a strange problem, because, you know, back in the days, when we did WS-star or Kerberos, these were really, really complicated protocols. And people knew, That this stuff is complicated so they only leave it up to the experts, whatever that means, yeah, to do that part of the work. Now when you look at the OAuth specification there are so many, you know, people out there which say, well I can do that, it's, it's a great request and you know I'm creating a token and send it back and I can do that. yeah. I mean, still remember that you're building a security protocol here. And just because it is from a mechanics point of view, much, much easier than stuff we used to know. It doesn't mean that the problem we are trying to solve is trivial. And that I guess, is, is the reason why. There are so many suboptimal OAuth implementations out there as well. And part of the bad reputation, I mean, but yeah. We, I totally agree with Aaron that the spec or the, the state of the spec is, has a big responsibility as well. The last I guess, link I want to point you to is a very balanced view on OAuth, and how you should use it, and when to use it, and that it's not as bad as many people say, as long as you know your use cases. It's from Tim Brey, he works at Google and is involved in Google's O Auth implementation, which I think is a very good implementation. And he has written a good blog post about that, that you can see on the bottom of the screen here. Resources Resources The last appendix I want to give you some further reading links and resources that are, you know, worthwhile having a look at when researching these technologies. So let's start with JSON Web Token, so in one of the demos I used a JSON Web Token debugger, that's a website. We can copy and paste JSON Web Token and it gives you the decoded content, which is very useful. Then there's the Microsoft JSON Web Token library, that's on NuGet. Right now, as I'm recording this, that's still a prerelease but I'm pretty confident that once the course gets published there will be a 1.0 version. Then, there are the specs for JSON Web Token. There are more specs than that, but these are the three interesting ones. One describes the general format, one describes signatures, and one describes encryption. And if you are doing Java, or have Java interrupt scenarios, it has also a pretty popular library on Bitbucket that implements JSON Web Token. And by the way there are more libraries just search for JSON Web Token and php or JSON Web Token and Node.js and you will find many more libraries but since I'm not doing that much work in that space I don't want to recommend anything. Just have a look around, and see what works for your scenario. For OAuth obviously that there are the specs. The RFC 6749 and 6750. very, very recommended to read, especially if you plan to build an authorization server. Is the Threat model which is RFC 6819. Then I used throughout my demos, I used my own library and OAuth authorization server implementation called Thinktechure Identity server and Thinktechture Identity model, respectively. Also when you go into the Thinktecture Identity Model Repository on GitHub, there's a Samples Directory where you can find all the samples I am, I've been showing you in the modules. And also when you're going through the Thinktechure Identity server Github page, there's a Wiki that describes how to do all these interactions like code flow and resource owner flow and implicit flow with identity server. There's another library called OpenAuth which is youthbyasp.net but they are more like in the mind set of doing authentication, doing OAuth2, but yeah, you might still find this useful. And for OpenID Connect again, there's a jump page for all the specs on openid.net/connect. If you want to start reading up to specs, there's a thing called the basic profile. I can recommend reading that first, that describes the code flow that I've been showing you in the slides. Then I mentioned Google's OpenID Connect implementation, even if they don't call it like that, they call it OAuth2Login, which I don't agree with. Anyways, but here are the links to their documentations. There's one is more detailed. Documentation page one is a link to the Google cookbook which has an overview of the many technologies they are supporting and one of them is OpenID Connect. I don't know a reference implementation of OpenID Connect for .net, but I am personally working on one that will part of Thinktechure Identity server, but that's not ready yet. But if you want to have a look, there's reference implementation for Java. It's a spring Java implementation and the people that are contributing to that project are also on the OpenID Connect board. So that's a pretty good implementation. Okay, and then I would just recommend have fun and you know my twitter handle. Ping me if you have questions or need more information. Course author Dominick Baier Dominick works as an associate consultant for the Germany-based company thinktecture. His main area of focus is security in general and identity & access control in particular. Course info LevelIntermediate Rating (1175) My rating Duration2h 23m Released26 Jun 2013 Share course