OAuth 2.0

OAuth 2.0 enables a resource owner to grant limited access to their protected resources to a third-party application without sharing their credentials. The client receives an access token representing the delegated permissions, which can be revoked at any time without changing the owner's password. This decouples authentication from authorization, allowing services like "Sign in with Google" to grant profile access without exposing the user's Google password to the requesting site.

The framework specifies four distinct roles that interact in the authorization flow:

• Resource Owner: The user or entity that can grant access to a protected resource
• Resource Server: The API hosting the protected data, which validates access tokens
• Client: The application requesting access on behalf of the resource owner
• Authorization Server: The server that authenticates the resource owner and issues access tokens

This separation of concerns allows each component to be implemented and scaled independently.

Access tokens are opaque or structured bearer tokens that represent the authorization granted to a client. Rather than granting blanket access, OAuth 2.0 uses scopes to define fine-grained permissions. A client might request read:profile scope to view user details but be denied write:posts scope. The resource server validates the token and its associated scopes on every API call, enforcing least privilege access at the endpoint level.

OAuth 2.0 defines several authorization grant types to accommodate different client profiles and security contexts:

• Authorization Code Grant: The most secure flow, used by server-side applications, involving an intermediate authorization code exchange
• Client Credentials Grant: Used for machine-to-machine communication where no user is involved
• Device Authorization Grant: Designed for input-constrained devices like smart TVs that lack a full browser
• Refresh Token Grant: Allows clients to obtain new access tokens without re-prompting the user

Each grant type addresses a specific trust model and client capability.

A network component that activates, executes, and monitors access decisions for each connection request. In an OAuth 2.0-secured AI infrastructure, the PEP intercepts API calls and validates bearer tokens before forwarding requests.

• Sits inline between clients and protected resources like model inference endpoints
• Extracts the OAuth 2.0 token and forwards it to the Policy Decision Point (PDP) for evaluation
• Enforces decisions by allowing, blocking, or redirecting traffic based on authorization outcomes

The ongoing process of re-authenticating and re-authorizing identity and security posture throughout an active session, not just at initial login. Extends OAuth 2.0's point-in-time token model with real-time posture checks.

• Monitors device health, geolocation, and behavior patterns during active AI workload sessions
• Triggers step-up authentication or session termination when contextual risk signals change
• Addresses the limitation that OAuth 2.0 bearer tokens remain valid until expiration regardless of compromised sessions

A reverse proxy acting as the single entry point for all API calls to AI services. The gateway centralizes OAuth 2.0 token validation, rate limiting, and request routing for model endpoints.

• Validates OAuth 2.0 access tokens at the perimeter before requests reach internal services
• Enforces rate limiting per client ID to prevent abuse of expensive inference resources
• Composes multiple backend calls while preserving the original caller's authorization context
• Common implementations include Kong, Envoy, and AWS API Gateway