OAuth 2.0 Extension for AI Model Access

hemanth.hm@gmail.com https://h3manth.com

Security OAuth Working Group OAuth AI API scopes delegation This document defines an extension to OAuth 2.0 for delegating scoped access to AI model APIs. It introduces a standardized scope syntax, resource indicators for AI providers, and token constraints suitable for AI workloads including spend limits and model restrictions.

Introduction The proliferation of AI model APIs (OpenAI, Anthropic, Google, Mistral, etc.) has created a need for secure delegation of API access. Current approaches involve sharing API keys directly with applications, which:

Exposes master credentials to third parties
Provides no usage limits or audit trail
Cannot be scoped to specific models or capabilities
Cannot be revoked without rotating the master key

This specification extends OAuth 2.0 to address these concerns by defining:

A standard scope syntax for AI model access
Resource indicators for AI providers
Token metadata for usage limits and spending caps
Security considerations specific to AI workloads

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

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 .

Scope Syntax

AI Scope Format AI-specific scopes follow this syntax: :: ]]> 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

Provider Identifiers

Provider	Identifier
OpenAI	openai
Anthropic	anthropic
Google AI	google
Mistral	mistral
Groq	groq
Together AI	together
Cohere	cohere

Capability Identifiers

Capability	Description
chat	Chat/text completions
embeddings	Vector embeddings
images	Image generation
audio	Audio transcription/synthesis
vision	Multimodal/vision
code	Code generation

Token Metadata

Token Introspection Response Extensions The token introspection response () is extended with:

Limit Fields

Field	Type	Description
monthly_spend_usd	number	Maximum spend per calendar month
daily_spend_usd	number	Maximum spend per day
requests_per_minute	integer	Rate limit (RPM)
requests_per_day	integer	Daily request limit
max_tokens_per_request	integer	Per-request token limit

Authorization Request

Additional Parameters

Parameter	Type	Description
ai_limits	JSON	Requested limits (as defined in Section 3.2)
ai_reason	string	Human-readable reason for access

Example authorization request:

Resource Server Requirements

Proxy Architecture The resource server (authorization server or dedicated proxy) MUST:

Validate the OAuth access token
Verify the requested operation matches token scopes
Check usage against token limits
Substitute the master API key
Proxy the request to the AI provider
Log usage for auditing
Update usage counters

Error Responses When limits are exceeded:

Security Considerations

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

DPoP ()
mTLS ()

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

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

IANA Considerations

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

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

References Normative References Key words for use in RFCs to Indicate Requirement Levels The OAuth 2.0 Authorization Framework OAuth 2.0 Token Introspection OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens OAuth 2.0 Demonstrating Proof of Possession (DPoP)

Example Flow | | | | scope=ai:openai:gpt-4:chat| | | | ai_limits={...} | Authorization | | | | Server | | |<-(2) Authorization Code-------| | | | +---------------+ | | | Client | +---------------+ | |--(3) Token Request----------->| | | | | Token | | |<-(4) Access Token-------------| Endpoint | | | + ai_limits metadata | | | | +---------------+ | | | | +---------------+ | |--(5) API Request------------->| | | | Authorization: Bearer ... | Resource | | | POST /v1/chat/completions | Server | | | | (Proxy) | | |<-(6) API Response-------------| | | | +---------------+ +--------+ ]]>

Acknowledgements The author would like to thank the OAuth Working Group for their foundational work on authorization frameworks.