-
Notifications
You must be signed in to change notification settings - Fork 1
Introduction to OAuth
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.
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 a big driver of the protocol, and it went to the IETF in 2008 and became an RFC 5849 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 1.0 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 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 OAuth. It's a bit controversial, because the, the main editor involved at some point redraw from all of its duties and and let 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 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 from a technical point of view but that all these companies had 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 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 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 6750. That describes bearer token usage.
So do I think that OAuth2 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.
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, 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 OAuth 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.
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 expensive and important Ferrari and 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. 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 lane.
Obviously, in this movie what happened is that this guy 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, 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 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, you know, your Twitter account, or 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 resource's behalf, without giving the client a master key, a-k-a, a password. So that's the whole intention of OAuth2. That's may sound a little abstract but we'll get to that.
The OAuth 2 players, so when we look at the protocol are really four players here.
1. Clients(Trusted/Untrusted, Confidential/Public) -
2. Authorisation Server - It issues limited access key - Valet Parking keys
3. Resource Owner - "owns" a resource in the Resource Server
4. Resource Server - "trusts" Authorisation server
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 these newer architectures come 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 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 confidential and public clients.
So public clients are typically it's client software which runs on client devices.
For example 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 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 side, the resource server 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 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-
With User Interaction
* Authorisation Code Flow
- Web application clients
1. Request Authorisation
2. Request token
3. Access resource
* Implicit Flow
- Native/local client
1. Request Authorisation & Token
2. Access resource
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 for classical server ran that, that applications.
For the more native or user agent based scenarios, there's a thing called the implicit flow.
OAuth2 Flows -
No User Interaction
* Resource Owned Password Credential Flow
- "Trusted Clients"
1. Request token with resource owner credentials
2. Access resource
* Client Credential Flow
- Client to Service Communication
1. Request token with client credentials
2. Access resource
Now I call these two flows with user interaction, 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, 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 WS 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.
1. OAuth2 makes it HTTP/JSON friendly to request and transmit token
- typically for delegated authorization(access tokens)
2. Takes "multiple client" architectures into account
- clients can have varying trust level
3. Since v2 of the spec is quite new, there is currently quite a discussion aboit its pros and cons. See Appendix A.
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 a thing called the authorization server and this makes it much more easier to 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 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 have summarized these discussion points in Appendix A so I can highly recommend going through that after you understood the basic OAuth concepts.