OAuth1, OAuth2, OAuth..? (2013)

http://homakov.blogspot.com/2013/03/oauth1-oauth2-oauth.html

by neverminder • 12 years ago

139 37 12 years ago

homakov.blogspot.com

thomasfl2• 12 years ago

This article is just technical enough for me. As a developer implementing security can be a pain in the ass. All I wan't is someone to tell if a protocol is secure, and get done with it.

smt885• 12 years ago

That's the kind of attitude that leads to massive security flaws. Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people.

IgorPartola• 12 years ago

Agreed, but there is a difference between understanding, let's say, how PKI works and how it applies to HTTPS vs knowing how to implement AES. Sometimes, we just need to know that SSL 3 is broken, and don't need to know the exact details. All we then need to know is to stop using it.

untog• 12 years ago

I only partly agree with you. Every developer does not need to know exactly how HTTPS encryption algorithms work, just whether they are secure or not.

smt885• 12 years ago

To the downvoters: if you stick your head in the sand, you'll do things like using MD5 for password hashing and logging into remote servers as root. I see basic mistakes like that all the time.

I'll reiterate (and this is a general comment, not necessarily about HTTPS): if you aren't willing to understand how software works and how people attack it, don't write it professionally. It's part of your job and your responsibility to your customers and their users.

When systems are cracked, it can leak financial info, passwords, addresses, children's names, medical info, etc., etc. You may have a totally innocuous site that helps someone get into one of your user's more sensitive accounts.

Security is really important and failing to understand it can ruin people's lives. I've personally seen it happen.

It worries me that saying something as simple and unassailable as "understand the security implications of your code" got downvoted on a "hacker" site so many times.

thomasfl2• 12 years ago

You are probably right. I would be pleased to be directed to some good sources about cryptography.

cobralibre• 12 years ago

I don't know about that — it helps to have more than superficial knowledge of the topic at hand so that you can adequately assess rants such as this one.

Personally, while I feel that Igor Homakov has done good work, this article is the product of frustration and is a disservice to its audience. Most if not all of his criticisms of OAuth 2 come down to implementation problems, and a more positive contribution would be an implementers' guide or a threat model document. For example, https://tools.ietf.org/html/rfc6819 and http://leastprivilege.com/2013/03/15/common-oauth2-vulnerabi....

higherpurpose• 12 years ago

Will this be of any help once browsers implement it?

http://cowl.ws/

ademarre3• 12 years ago

With the exception of vector #6, this is pretty much a list of implementation flaws, not protocol flaws. It's as if he's trying to say that the protocol isn't written defensively enough or foolproof enough for implementors, and he might have a good point if he simply said that, but he never did.

Even with an OAuth library for the nuts and bolts, to implement an OAuth2 authorization server requires grokking the spec.

Vector #6 (Phishing by spoofed client) has always been particularly interesting to me, and it applies to both OAuth2 and OAuth1. I dont see it as a protocol flaw but an attack vector service providers need to be more aware of.

While OAuth2 was in draft, I reported it to Facebook, Google, Twitter and the OAuth WG. Facebook addressed it by displaying the domain name of the client on their authorization dialog, but they eventually got rid of that. Google also acknowledged the vulnerability and said they would rely on policing registered clients to catch it. Twitter never responded. The WG asked me to propose text for the security considerations document, but I dropped the ball (too swamped) and couldn't do it in time.

nijiko2• 12 years ago

Thank you for this, was about to post the exact same reply.

dmak• 12 years ago

How does Google police registered clients? Does anyone else do this?

ademarre3• 12 years ago

Good question. I dug up the e-mail from 2012 and here's what the Google Security Team told me:

We're deploying some abuse detection and reactive measures to deal with impostors that might try to abuse this sort of attack.

Surely any OAuth2 service provider will disable clients that are caught misbehaving.

homakov3• 12 years ago

this is pretty much a list of implementation flaws, not protocol flaws

I can agree with that but problems outlined are very common so it doesn't really matter. Say, Facebook is major oauth2 provider and doesn't follow most of the spec. As well as lots of popular libraries.

ademarre3• 12 years ago

You're probably right; spec conformance is a problem. What should be done about it? If the spec itself isn't all that bad, then we should try to improve implementations. Maybe tools can be developed to help detect implementation flaws. Or if the letter of the spec is the problem, but the protocol/framework itself is good, then why not rewrite an alternative spec, similar to what was done recently for HTTP/1.1?

paulannesley• 12 years ago

Article looks familiar, and was published March 1, 2013.

sctb• 12 years ago

Thanks, we updated the title.

cratermoon• 12 years ago

OpenID-Connect (which is really OAuth2 with a specified auth/profile flow)

peter_l_downs2• 12 years ago

I've written an OAuth2 server implementation and to be honest, I still don't really understand why people use OAuth2 instead of OAuth1.0a. The minimum amount of work you have to do to write an implementation that complies with the spec leaves you open to all sorts of security issues (as Homakov continues to detail), no two providers implement the same parts of the spec so writing clients isn't really all that easy, and the "security" features don't really seem all that secure. For example, refresh tokens, what the fuck? If an attacker can steal your access token why would you assume that your refresh tokens are safe? How is it ok to say "well, even if your access token is stolen at least it will expire eventually, so don't worry"?

/rant.

nijiko2• 12 years ago

It requires the client id and secret to obtain a refresh token, some also choose to skip this and ask the user to re-authenticate completely.

I agree that people implement it differently so vastly different that it takes almost 40 sources to compile a decent down-to-earth explanation of common practices (same for OAuth 1.0a). However, that doesn't make the protocol bad, it makes the implementation bad, you can avoid XSS, OOS Origin Attacks, and the others with the exception of Vector attacks, but both are vulnerable to this.

peter_l_downs2• 12 years ago

That's fair, I guess what I'm trying to say is that if the spec leads to broken/vulnerable implementations in the majority of cases there might be reason for concern. One thing I think OAuth 2 gets right is the entire concept of scoped authorization; although not unique to OAuth2, it's now familiar to users largely because Facebook and Google adopted it through OAuth 2.

tboyd47• 12 years ago

I had to write one too, and feel exactly the same way.

The common argument for OAuth2 seems to be, "Well, Google and Facebook are doing it, so it must be worth something." Of course Google and Facebook are doing it; it lets them play the role of the official identity keepers of the internet.

Those companies are known to pick the best and the brightest engineers, yet exploits were found in even their versions of OAuth2. If they couldn't produce a secure implementation, then can anyone?

tveita• 12 years ago

The point of refresh tokens is not to be more secure than access tokens, but to make some implementations more convenient.

- It's easier to change the format of short-lived access tokens, since you know there are no valid tokens hanging around after the expiry time. In contrast you may want refresh tokens to be valid for months or years.

- Every endpoint in your system must read access tokens, but only your authorization endpoint needs to read refresh tokens.

- In some cases it is acceptable to do checks only when verifying refresh tokens, e.g. checking for revocation only when refreshing the tokens, while access tokens are trusted implicitly while valid.

For a simple implementation you can just issue long-lived access tokens, use of refresh tokens is optional.

oautholaf• 12 years ago

As someone who was present at Google working at OAuth at the time OAuth 2.0 was negotiated: the way to interpret refresh tokens is in the context of a large organization like Google or Facebook, not a small website. A refresh token, which is powerful, would only be presented to a single endpoint which could had different logging and security considerations.

But yes, a lot of damage can be done in an access token timeout.

ryusage• 12 years ago

My understanding from my research into OAUTH2 is that most of the vulnerabilities in it are only issues in a naive implementation. They can be made secure, but it's not easy and you have to know to do it in the first place.

Doesn't OpenID Connect address those issues? I know that's what Google is using now.

Luker88• 12 years ago

I have written an implementation for OAuth1 and OAuth2.

I liked the protocol/framework so little that I started implementing a new one. But soon I realized that a lot of the difficulties come from having this thing run on top of HTTP, and that I could not access any security feature of the lower levels.

So (IMHO) everything implemented on top of HTTP, or the whole idea of having isolated layers of security is doomed to have problems and will cause headaches to anyone working with it, aside from requiring developers to be security experts.

But I still didn't stop and my master thesis now is a complete secure rewrite of protocols from tcp, tls to OAuth.

The project is on fenrirproject.org if you want to comment it. Lots of work, I am aiming to an implementation in half a year. Please feel free to drop me a line.

sandstrom• 12 years ago

I know Homakov is very talented, I really like his work!

But I find the article difficult to parse. Anyone know of a technical but more accessible article on the 5-6 points he mentions?

homakov3• 12 years ago

Check oauthsecurity.com

chris_wot• 12 years ago

A comment was made the other day here:

https://news.ycombinator.com/item?id=8831504

I was confused as to whether OAuth was authentication or authorization... so which is it?

homakov3• 12 years ago

This is relevant oauthsecurity.com

OAuth1, OAuth2, OAuth..? (2013)

Related Stories