Difference between revisions of "OAuth 2.0"

From MgmtWiki
Jump to: navigation, search
(Problems)
(Problems)
Line 13: Line 13:
 
* Security UX is complicated and not described in the spec.
 
* Security UX is complicated and not described in the spec.
 
* State parameters are needed for security, but not required by 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.
  
 
==Solutions==
 
==Solutions==

Revision as of 10:48, 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.
  • A bunch of specs implemented other ways to enable secure, such as UMA, PCKE, etc.

Solutions

References

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