Skip to content

OAuth2 Concerns

Jump to bottom
Adarsh Kumar Maurya edited this page Dec 10, 2018 · 2 revisions

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 Eran Hammer, left. The committee and was really vocal about the fact that he wants his name to be removed from the spec. And, and frankly 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

Eran 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, especially the bloat 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 oAuth gain that much attraction 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 oAuth2.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, 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 searched the overall specifications for the word May, and found 69 hits. And here's a very a nice example 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 room for you know, improvement. There should be in my opinion an oAuth-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 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 JSON Web token. JSON Web 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 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 Eran'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 authentication features directly in OAuth by do we need to have this huge additional specification and again 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 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 bearer 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 SAML we have this concept of, that you embed A key into the SAML token. And you transmit, 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, Eran was a big proponent 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 SSL 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 SSL 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 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 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 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 SSL 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 login 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 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 one part of the discussion around is that's all this thing make sense or wouldn't it be much better if everybody was using the resource-owner 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 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 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 required. But the spec kind of steers you in that direction. So let's have a look at the authorized request in Oauth2.0.

Attack Surface
GET /authorize?
    client_id=nativeapp&
    redirect_uri=http://localhost/cb&
    scope=resource&
    respone_type=token&
    state=123

So you have to specify whose the client, where to go to after the consent is done. Which we source to access, 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 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 turn a response of type authorization code into responsive type token for example.

So In other words, there are many input parameters int oAuth 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 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 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 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 Egor Homakov 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.

Some Facebook Hacks

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 Egor found is basically a page on Facebook that has a cross site vulnerability. So basically he would send a link to someone. This guy logged in 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

- The OAuth2 approach is useful for many typical applications scenarios
- Spec needs some refinement
 -- basic profile
 -- MAC tokens
- Current implementations are lacking
 -- even by the big guys
 -- let alone the myriad of DIY implementation
- Very good and balanced view
 -- https://www.tbray.org/ongoing/When/201x/2013/01/23/OAuth

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 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 oAuth2 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 specification for MAC tokens so we can get away from Bearer tokens if we have 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 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 a GET 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 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 Eran 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 Bray, 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.

Clone this wiki locally