OAuth2 Security_unknown property 'security.oauth2.resource.loadbal-优快云博客

本文探讨了 OAuth2 当前面临的安全问题，包括规范过于宽松、看似简单的实现背后隐藏的安全隐患、广泛的攻击面等问题，并提出了一些改进建议。

Right now there are many good “discussions” on OAuth2 security happening. Some are constructive, some rather destructive – and some simply hack one or the other website to prove the point.

In my opinion there are a number of reason OAuth2 has a rather bad reputation right now. In this post I want to focus on the problems, in the next post what we can learn and how IdentityServer (hopefully) mitigates them.

The spec is too relaxed
When you read the spec, you’ll see a lot of “out of scope” or “at the discretion of the implementer” phrases and many “SHOULDs” and “MAYs”. Or in other words, while writing the specs there were too many interests clashing, resulting in too many ways to achieve the same thing. This lead to changing the name from “OAuth2 Protocol” to “OAuth2 Framework”. WS* anyone?

Also the lack of a token type specification lead to many homegrown token formats that were missing one or the other important security features (like audience checking, encapsulated tokens…). Writing your own token format/implementation is hard, try to avoid that!

I think we really need something like a “basic” profile that hits the 80/20 use cases with exact instructions and guidance for the implementer.

OAuth2 looks too easy
Well – what I mean here is, in WS* world we all knew shit’s hard. In the mind of many people OAuth2 is just a bunch of redirects and HTTP posts. easy. job done.

All I can say is, we are still trying to solve the same non-trivial (read: hard) problems, just using different technologies. Just because one knows HTTP does not mean he also knows how to implement security protocols.

Even the big guys like Facebook got it wrong several times – and some are still playing a dangerous game (see redirect URI based attacks later in my reference links).

Lots of attack surface
Every aspect of OAuth2 can be controlled via input parameters (like query strings or the post inputs). If I were the security tester – of course the first thing I’d try is fuzzing them and see what happens. And catastrophical things happened.

Input is still evil, even when it comes via some specified protocol. Things like response types and redirect URI should come from the authorization servers configuration database, not from external input.

Security Theater
Security theater is a “technique” to make you feel secure/safe while actually doing nothing (see here).

While the OAuth2 flows for native/mobile apps have all the best intentions – namely the developer does not need to deal with the user’s password (and thus not store it) etc. – it does not help you to distinguish between good and bad apps.

No one can make sure that this windows with the authorization server UI is really the authorization server, even when it looks exactly like a browser window!

So in other words, the moment you installed an application on your device, you already made a trust decision. OAuth2 cannot safe you here.

That said, IMO developers should use the implicit flow because that’s (even with a little awkward user experience) still better than dealing with credentials yourself. Windows 8 is a very good example of a modern approach to the problem. The WebAuthenticationBroker API that is built right into the operating system allows for an easy way to do OAuth2 style authorization (and OpenID connect style authentication).

OAuth2 in not an authentication protocol
OAuth2 is an authorization protocol – that’s a huge difference. Everybody who confused the two terms has learned the hard way. Don’t follow them.

OpenID Connect specifies how authentication works on top of OAuth2 – just eight more specs to read.

But – Google, Facebook and friends do authentication with OAuth2 – what do you mean? Well they all do it either using some custom extension, or like Google, OpenID Connect and call it OAuth2 sign-in.

Bearer Tokens
Bearer tokens means that there is no binding between the access token and the HTTP request. In other words whoever manages to steal a token from you (e.g. on the wire) can use that token to do requests on your behalf.

All OAuth2 security currently relies solely on SSL/HTTPS to protect access token transmission. This would be OK in a perfect world. In the real world developers and/or infrastructure like to bypass SSL.

I can only speak for developers – NEVER EVER disable SSL certificate validation. NEVER EVER.

Unfortunately when you search for “how to handle SSL validation errors” on the internet, it is more likely to find information on how do disable validation (in any popular programming language) than a real answer to the question. Shame on them.

An alternative to bearer tokens would be MAC tokens. Yes they are a little harder to program against – but not much. We need this alternative – but there is currently no spec.

References
Here’s some further reading material. Many of the above points were inspired by the following articles. I totally recommended reading every single one: