OAuth 2.0 Extension for AI Model Access

1.1. Terminology

AI Provider

A service offering AI model APIs (e.g., OpenAI, Anthropic)¶

Model

A specific AI model (e.g., gpt-4, claude-3, gemini-pro)¶

Capability

A function offered by a model (chat, embeddings, images, audio)¶

Master Key

The user's API key for a provider¶

Delegated Token

An OAuth access token with AI-specific scopes¶

1.2. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶

2.1. AI Scope Format

AI-specific scopes follow this syntax:¶

ai:<provider>:<model>:<capability>

Examples:¶

• ai:openai:gpt-4:chat - Chat completions with GPT-4¶
• ai:anthropic:claude-3-opus:* - All capabilities for Claude 3 Opus¶
• ai:openai:*:embeddings - Embeddings with any OpenAI model¶
• ai:*:*:chat - Chat with any provider/model¶

2.2. Provider Identifiers

2.3. Capability Identifiers

3.1. Token Introspection Response Extensions

The token introspection response ([RFC7662]) is extended with:¶

{
  "active": true,
  "scope": "ai:openai:gpt-4:chat",
  "ai_limits": {
    "monthly_spend_usd": 100.00,
    "daily_spend_usd": 10.00,
    "requests_per_minute": 60,
    "requests_per_day": 1000,
    "max_tokens_per_request": 4096
  },
  "ai_usage": {
    "spend_this_month_usd": 23.45,
    "spend_today_usd": 2.10,
    "requests_this_minute": 3,
    "requests_today": 156
  }
}

3.2. Limit Fields

4.1. Additional Parameters

Example authorization request:¶

GET /authorize?
  response_type=code&
  client_id=app123&
  scope=ai:openai:gpt-4:chat&
  ai_limits={"monthly_spend_usd":50}&
  ai_reason=Code+assistant+for+IDE

5.1. Proxy Architecture

The resource server (authorization server or dedicated proxy) MUST:¶

1. Validate the OAuth access token¶
2. Verify the requested operation matches token scopes¶
3. Check usage against token limits¶
4. Substitute the master API key¶
5. Proxy the request to the AI provider¶
6. Log usage for auditing¶
7. Update usage counters¶

5.2. Error Responses

When limits are exceeded:¶

{
  "error": "ai_limit_exceeded",
  "error_description": "Daily spend limit of $10.00 exceeded",
  "ai_usage": {
    "spend_today_usd": 10.23,
    "daily_spend_usd": 10.00
  }
}

6.1. Token Binding

For high-security deployments, tokens SHOULD be sender-constrained using:¶

• DPoP ([RFC9449])¶
• mTLS ([RFC8705])¶

6.2. Prompt and Response Handling

Resource servers:¶

• MUST NOT log prompt or response content by default¶
• MUST encrypt any logged content at rest¶
• SHOULD provide configurable retention policies¶
• SHOULD support zero-logging mode¶

6.3. Master Key Protection

• Master keys MUST be encrypted at rest¶
• Master keys MUST NOT be exposed in logs or error messages¶
• Key rotation SHOULD be supported without token invalidation¶

7.1. OAuth Scope Registration

This specification registers the "ai" scope prefix in the OAuth Parameters registry.¶

7.2. AI Provider Registry

This specification requests the establishment of a registry for AI provider identifiers.¶

8.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC6749]

Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[RFC7662]

Richer, J., "OAuth 2.0 Token Introspection", RFC 7662, October 2015, <https://www.rfc-editor.org/info/rfc7662>.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, February 2020, <https://www.rfc-editor.org/info/rfc8705>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, September 2023, <https://www.rfc-editor.org/info/rfc9449>.