RFC 6749

Definition

Have you ever wanted to let an app access your photos on Facebook, or let a website post tweets on your behalf, without giving them your actual password? That is exactly the problem RFC 6749 solves. It is the official specification that defines OAuth 2.0, the most widely used authorization framework on the internet today.

Before OAuth 2.0, the only way to let third-party apps access your accounts was to literally hand over your username and password. This was a security nightmare. If that app got hacked, or if it was malicious in the first place, your entire account was compromised. You would have to change your password everywhere, and there was no way to limit what the app could do with your credentials.

RFC 6749 introduces a much smarter approach: instead of sharing passwords, you authorize apps to receive special tokens that grant limited, time-restricted access to specific features of your account. Think of it as the difference between giving someone your house key versus giving them a temporary access card that only works for the garage during business hours. The specification defines four different “grant types” (ways to obtain these tokens) to cover different scenarios - from web apps to mobile apps to server-to-server communication.

Example

Signing in with Google on Spotify: When you tap “Continue with Google” on Spotify, the app redirects you to Google’s login page. Google asks if you want to let Spotify see your email and profile picture. When you approve, Google gives Spotify a special token - Spotify never sees your Google password, but can read your basic profile information.

Connecting Instagram to a scheduling tool: Social media managers use tools like Buffer or Hootsuite to schedule posts. These tools use OAuth 2.0 to get permission to post on your behalf. You log into Instagram directly, approve the permissions, and the scheduling tool receives a token that lets it post for you - nothing else.

Smart home devices: When you link your Nest thermostat to Google Assistant, OAuth 2.0 handles the authorization. Google Assistant gets a token that lets it control your thermostat, but it cannot access your Nest camera footage unless you explicitly grant that additional permission.

Banking apps using fintech services: When you connect your bank account to apps like Mint or YNAB for budgeting, many banks now use OAuth 2.0. The budgeting app gets read-only access to your transactions without ever knowing your banking password.

Analogy

The Valet Key: Many luxury cars come with a special “valet key” that only starts the engine and locks the trunk - it cannot open the glove box or access the full capabilities of the car. OAuth 2.0 is like giving an app a valet key instead of your master key. You are granting limited access for a specific purpose, and you can revoke that key anytime without changing your main credentials.

The Hotel Room Key Card: When you check into a hotel, you do not get a master key - you get a card that opens your room, maybe the pool area, and the gym, but nothing else. And it expires when you check out. OAuth tokens work the same way: they grant access to specific resources and have an expiration date. If you lose the card, you just deactivate it at the front desk (revoke the token).

The Babysitter Authorization: Imagine you leave your kids with a babysitter. You might give them authorization to order pizza, pick the kids up from school, and access the medicine cabinet - but not to throw a party or drive your car. You are delegating specific permissions. OAuth 2.0 lets users delegate specific permissions to apps in exactly this way.

The Building Security Badge: In an office building, different badges grant access to different areas. An employee badge might open the front door and your office floor, but not the server room or executive suite. OAuth scopes work like these badge permissions - each token comes with a specific set of access rights.

Code Example

// [Authorization Code Flow](https://reference.apios.info/terms/authorization-code-flow/) (most secure)
// 1. Client redirects user to authorization server
GET https://auth.example.com/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=https://app.com/callback&
  scope=read:profile&
  state=xyz123

// 2. User approves, server redirects back with code
https://app.com/callback?code=AUTH_CODE&state=xyz123

// 3. Client exchanges code for access token
POST https://auth.example.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTH_CODE&
redirect_uri=https://app.com/callback&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

// 4. Response with access token
{
  "access_token": "eyJhbGc...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0..."
}

Security Notes