Visual RFC.
ALL RFCs / RFC 6749
Read the RFC ↗

RFC 6749 / START HERE

OAuth 2.0, before the details

OAuth 2.0 authorization framework

OAuth is a framework for delegated authorization: giving an app limited permission to use another service. It is not, by itself, a login identity protocol.

Start the guide See the 11 chapters ↓

The idea in one picture

  1. You approve permission

  2. The app gets an access token

  3. The service allows limited access

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

Sharing your password gives an app too much power. OAuth separates your account credentials from the permission the app receives.

A familiar example

A calendar app asks permission to read your calendar. You approve at the calendar service, which gives the app an access token instead of your password.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

HTTPRFC 9110 · beginner overview ↗URI syntaxRFC 3986 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Four roles, one delegationAn app receives limited authority instead of the resource owner’s password.
  2. Public and confidential clientsAn app’s ability to keep credentials confidential determines its client type.
  3. Two endpoints, two channelsThe browser requests permission. The client exchanges grants at the token endpoint.
  4. Authorization code grantA short-lived code travels through the browser; tokens come from the token endpoint.
  5. Implicit grant: historical behaviorThe original framework allowed the authorization response itself to deliver an access token.
  6. Password grant: now prohibitedThe original password grant passed resource-owner credentials through the client. Later guidance prohibits it.
  7. Client credentials and extension grantsA client can obtain access on its own behalf, without an interactive resource-owner redirect.
  8. Token responses and failuresA successful token response describes the credential. An error response must not be mistaken for one.
  9. Refresh without another promptA refresh token returns to the authorization server, never to the resource server as an access credential.
  10. Scope and protected resourcesThe client asks for privileges; the server decides what it actually grants.
  11. Native apps and security boundariesThe framework’s original native-app choices and TLS advice were narrowed by subsequent security RFCs.
Start with chapter one →

This introduction explains RFC 6749 (2012). Read the original RFC ↗