RFC 8707

Definition

Here is a security problem that catches many developers off guard: you request an OAuth token to access one API, but that same token could potentially be used to access a completely different API if they share the same authorization server. RFC 8707 addresses this vulnerability by letting you explicitly specify which API (resource) a token should work with.

Think about it this way: when you request an access token from Google, should that token work with Gmail, Google Drive, YouTube, and every other Google service? That would violate the principle of least privilege. RFC 8707 introduces the “resource” parameter, letting you say “I only want a token that works with Gmail” - nothing else.

This is especially important in enterprise environments where a single identity provider manages access to dozens of internal APIs. Without resource indicators, a token issued for the HR system might theoretically work against the payroll system or the customer database. With RFC 8707, each token is locked to specific APIs, dramatically reducing the blast radius if a token is compromised. The token itself carries an “audience” claim that the target API validates - if the audience does not match, access is denied.

Example

Multi-API platforms: Slack has APIs for messaging, files, user management, and admin functions. When an app requests a token, RFC 8707 lets it specify exactly which APIs it needs: resource=https://api.slack.com/messages&resource=https://api.slack.com/files. The token is useless against admin APIs.

Microservices architectures: In a system with separate services for orders, inventory, shipping, and billing, each service has its own resource indicator. A token issued for the orders service cannot be used to access inventory data, even if both services use the same auth server.

Banking APIs: Open banking regulations require precise access control. A budgeting app might get a token only valid for resource=https://bank.com/accounts/read - it cannot initiate transfers even if the token leaks.

Third-party integrations: When a company allows third-party apps to integrate, resource indicators ensure those apps can only access the specific APIs they were approved for - not browse around the entire system.

Analogy

The Building-Specific Access Badge: Instead of a master key that opens every door in a corporate campus, you get a badge programmed only for specific buildings. Even if someone steals your badge, they can only access the buildings you were authorized for - not the executive tower or the data center.

The Airline Class Ticket: Your economy ticket gets you on the plane, but it does not get you into the business lounge or the first-class cabin. Each privilege is explicitly specified. RFC 8707 tokens work the same way - access is explicitly scoped.

The Concert Zone Wristband: At large venues, different wristbands grant access to different zones: general admission, VIP, backstage. You cannot use your GA wristband to get backstage, even though you are “in” the venue. Resource indicators create these zones for APIs.

The Car Rental Category: When you rent a car, you are authorized for a specific vehicle category. Your compact car reservation does not let you drive off in a luxury SUV, even though they are all in the same lot. Resource indicators restrict you to specific “categories” of APIs.

Code Example

// Token request with resource indicator
POST /token [HTTP/1.1](https://reference.apios.info/terms/http-1-1/)
Host: auth.example.com
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&
resource=https://api.example.com&
resource=https://files.example.com

// Response includes audience claim
{
  "access_token": "eyJhbGc...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read write"
}

// JWT payload includes aud claim
{
  "aud": [
    "https://api.example.com",
    "https://files.example.com"
  ],
  "iss": "https://auth.example.com",
  "sub": "user123",
  "exp": 1516239022
}

Security Notes