Difference between revisions of "OAuth 2.0"

Revision as of 11:53, 30 July 2018

The OAuth 2.0 Authorization Framework

In OAuth 2.0

OAuth 2.0 still depends on shared secrets between services on Web Sites and other internet devices;^[1] while most sites are protected by public keys and certificates, at least until quantum computing arrives.
It is still just a collection of parts that can be configured in a wide variety of combinations; most of which are not particularly secure.
Token type "bearer" is still the only one used in real-world implementations.
The redirect URL is not well specified in the spec and is subject many exploits. The problem is poor implementations and reuse of each client id across many implementations.
HTTP refer header is usually sent in the clear and contains way too much information in Front Channel implementations.
Security UX is complicated and not described in the spec.
State parameters are needed for security, but not required by the spec.
A bunch of specs implemented other ways to enable secure, such as UMA, PCKE, etc.
Implicit flow was added to enable javascript, but recent innovations in browser has weaken the existing very weak security.
Resource Owner password turned into a really bad idea. It should be banned.
Scopes were created, but not defined, so there is no way to determine what a scope actually means.

RFC 6749 The OAuth 2.0 Authorization Framework specification
RFC 8252 OAuth 2.0 for Native Apps Specification
↑ Justin Richer, What's Wrong With OAuth 2? https://twitter.com/justin__richer/status/1023738139200778240

@@ Line 16: / Line 16: @@
 * Implicit flow was added to enable javascript, but recent innovations in browser has weaken the existing very weak security.
 * Resource Owner password turned into a really bad idea. It should be banned.
+* Scopes were created, but not defined, so there is no way to determine what a scope actually means.
 ==Solutions==