Difference between revisions of "OAuth 2.0"
From MgmtWiki
(→Problems) |
(→Problems) |
||
| Line 8: | Line 8: | ||
* OAuth 2.0 still depends on shared secrets between services on [[Web Site]]s and other internet devices;<ref>Justin Richer, ''What's Wrong With OAuth 2?'' https://twitter.com/justin__richer/status/1023738139200778240</ref> while most sites are protected by public keys and certificates, at least until quantum computing arrives. | * OAuth 2.0 still depends on shared secrets between services on [[Web Site]]s and other internet devices;<ref>Justin Richer, ''What's Wrong With OAuth 2?'' https://twitter.com/justin__richer/status/1023738139200778240</ref> 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. | * 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. | ||
==Solutions== | ==Solutions== | ||
Revision as of 10:45, 30 July 2018
Full Title or Meme
The OAuth 2.0 Authorization Framework
Context
In OAuth 2.0
Problems
- 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.
Solutions
References
- RFC 6749 The OAuth 2.0 Authorization Framework specification
- RFC 8252 OAuth 2.0 for Native Apps Specification
