OAuth 2.0

From MgmtWiki
Jump to: navigation, search

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. See the page Bearer Tokens Considered Harmful on this wiki.
  • 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 explicitly defined, so there is no way to determine what a scope actually means.
  • Discovery is not well defined, but always leaks information.

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
    2. Justin Richer, Moving On from OAuth 2: A Proposal. https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade