OAuth 2.0

From MgmtWiki
Revision as of 11:53, 30 July 2018 by Tom (talk | contribs) (Problems)

Jump to: navigation, search

Full Title or Meme

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.



  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