n4nAI
Open console →
API integrationDefinitionOAuth2 & Bearer Token Auth for LLM Platforms

How OAuth2 authorization code flow works for LLM APIs

Defines the OAuth2 authorization code flow for LLM APIs: how delegated token issuance works, why it beats API keys, and a minimal Python example with PKCE.

n4n Team5 min read1,014 words

Audio narration

Coming soon — every post will get a voice note here.

The oauth2 authorization code flow llm api pattern is an authorization protocol where a user grants a client app limited access to an LLM resource server by authenticating with an identity provider and returning a short-lived code that the client exchanges for an access token. It issues scoped bearer tokens to the client without exposing user credentials, making it the standard for delegated access in multi-user LLM applications.

What the OAuth2 authorization code flow actually is

OAuth2 defines four roles: resource owner (the user), client (your app), authorization server (the IdP), and resource server (the LLM API). The authorization code flow is one of several OAuth2 grants; it is designed for clients that can keep a secret or use PKCE, typically server-side web apps and native apps.

Core roles in an LLM context

  • Resource owner: A developer or end user who has an account with the LLM platform and owns quota or data.
  • Client: Your service that calls the LLM API on the user’s behalf (e.g., a RAG dashboard).
  • Authorization server: The entity that authenticates the user and issues tokens. This could be the LLM vendor’s auth system or your own Keycloak/Auth0 tenant.
  • Resource server: The LLM inference endpoint that validates bearer tokens and returns completions.

Token lifecycle

The access token is a bearer credential, usually a JWT or opaque string, with an expiry of minutes to an hour. A refresh token may be issued for offline access. The LLM API validates the token on every request, checking signature, audience, and scope.

How the flow works step by step

1. Authorization request

The client redirects the user’s browser to the authorization endpoint with response_type=code, a client_id, a redirect_uri, and a scope (e.g., models:read completions:write). For public clients, a code_challenge derived from a PKCE code_verifier is required.

GET /authorize?
  response_type=code&
  client_id=app_123&
  redirect_uri=https://app.example.com/callback&
  scope=completions:write%20models:read&
  code_challenge=XYZ123&
  code_challenge_method=S256
HTTP/1.1
Host: auth.llmprovider.com

The authorization server presents a login and a consent screen listing the requested scopes. The user approves or denies.

3. Redirect with authorization code

On approval, the server redirects back to the redirect_uri with a code parameter. The code expires in seconds to minutes.

HTTP/1.1 302 Found
Location: https://app.example.com/callback?code=AUTH_CODE_456

4. Token exchange

The client sends the code to the token endpoint over a back-channel (server-to-server). Confidential clients authenticate with client_secret; public clients send the original code_verifier for PKCE.

import requests

token_resp = requests.post(
    "https://auth.llmprovider.com/token",
    data={
        "grant_type": "authorization_code",
        "code": "AUTH_CODE_456",
        "redirect_uri": "https://app.example.com/callback",
        "client_id": "app_123",
        "client_secret": "secret_abc",  # omit for PKCE, add code_verifier
        "code_verifier": "random_string_used_in_step_1",
    },
)
tokens = token_resp.json()
# {'access_token': 'eyJ...', 'refresh_token': 'rt_...', 'expires_in': 3600}

5. Calling the LLM API

The client presents the access token as a bearer token in the Authorization header. The LLM API validates it and returns a completion.

completion = requests.post(
    "https://api.llmprovider.com/v1/chat/completions",
    headers={"Authorization": f"Bearer {tokens['access_token']}"},
    json={"model": "gpt-4o", "messages": [{"role": "user", "content": "Hello"}]},
)

Why it matters for LLM APIs

API keys are simple but blind: they grant full account access and leak easily in frontend code or logs. The oauth2 authorization code flow llm api approach binds access to a specific user, limits scope, and supports revocation.

For multi-tenant SaaS that calls an LLM per end user, the flow lets you enforce per-user quotas and audit trails. The access token carries identity claims; the resource server can reject requests lacking completions:write.

When you front multiple model providers with a gateway, the OAuth2-issued bearer token becomes the uniform credential the gateway validates before forwarding requests. n4n.ai, as an OpenAI-compatible endpoint covering 240+ models, honors such client routing directives and forwards provider cache-control hints while metering per-token usage. The gateway doesn’t care how the token was minted as long as it validates.

Concrete example: minimal Python web app

Below is a stripped-down Flask app using PKCE (no client secret). It stores the verifier in the session and exchanges the code.

from flask import Flask, session, redirect, request, url_for
import requests, hashlib, base64, os

app = Flask(__name__)
app.secret_key = "replace-with-env-secret"
AUTH_BASE = "https://auth.llmprovider.com"
CLIENT_ID = "app_123"
REDIRECT_URI = "http://localhost:5000/callback"

def gen_pkce():
    verifier = base64.urlsafe_b64encode(os.urandom(32)).rstrip(b"=").decode()
    challenge = base64.urlsafe_b64encode(
        hashlib.sha256(verifier.encode()).digest()
    ).rstrip(b"=").decode()
    return verifier, challenge

@app.route("/login")
def login():
    verifier, challenge = gen_pkce()
    session["verifier"] = verifier
    return redirect(
        f"{AUTH_BASE}/authorize?response_type=code"
        f"&client_id={CLIENT_ID}&redirect_uri={REDIRECT_URI}"
        f"&scope=completions:write&code_challenge={challenge}"
        f"&code_challenge_method=S256"
    )

@app.route("/callback")
def callback():
    code = request.args.get("code")
    verifier = session.pop("verifier", None)
    tok = requests.post(f"{AUTH_BASE}/token", data={
        "grant_type": "authorization_code",
        "code": code,
        "redirect_uri": REDIRECT_URI,
        "client_id": CLIENT_ID,
        "code_verifier": verifier,
    }).json()
    session["access_token"] = tok["access_token"]
    return redirect(url_for("ask"))

@app.route("/ask")
def ask():
    at = session.get("access_token")
    r = requests.post(
        "https://api.llmprovider.com/v1/chat/completions",
        headers={"Authorization": f"Bearer {at}"},
        json={"model": "llama-3-70b", "messages": [{"role": "user", "content": "Explain PKCE"}]},
    )
    return r.json()["choices"][0]["message"]["content"]

This demonstrates the oauth2 authorization code flow llm api integration without leaking a secret to the browser. The verifier never leaves the server session except as the challenge hash.

Common misconceptions

OAuth2 is the same as authentication

OAuth2 is authorization, not authentication. It answers “can this client act on behalf of a user?” not “who is this user?” For login, layer OpenID Connect on top, which adds an ID token.

PKCE is only for mobile apps

PKCE is mandatory for public clients (SPAs, native apps) and recommended for all authorization code flows since RFC 7636. A confidential web client that neglects PKCE is vulnerable to authorization code interception.

Access tokens belong in localStorage

Browser localStorage is readable by any JavaScript, making tokens prey to XSS. Server-side sessions or short-lived in-memory storage with refresh via HttpOnly cookies are safer. The oauth2 authorization code flow llm api pattern assumes the token lives where the client can use it securely, not in the DOM.

LLM APIs don’t support OAuth2

Many LLM vendors still issue static API keys, but enterprise gateways and platforms increasingly expose OAuth2 endpoints for delegated access. If you build internal tooling against a gateway, expect to implement the flow rather than hardcoding keys.

Refresh tokens never expire

Refresh tokens can be rotated, revoked, or scoped with absolute expiry. Treat them as long-lived credentials stored encrypted at rest. If a user revokes consent, the refresh token stops working.

The authorization code is a token

The code is a one-time, short-lived pointer. It cannot be used to call the LLM API. Only the exchanged access token is a bearer credential.

Scopes and least privilege

Define scopes narrowly: completions:write for inference, models:read for listing. Avoid a single admin scope for a web app. The LLM API should map scopes to endpoint permissions. When the oauth2 authorization code flow llm api grant includes fine_tuning:write, the token can trigger training jobs; keep that out of default consent.

Token introspection and revocation

Resource servers may call the authorization server’s introspection endpoint to check token status without local JWT validation. For opaque tokens, this is required. Revocation endpoints let your app terminate a session when a user logs out.

curl -X POST https://auth.llmprovider.com/revoke \
  -d token=eyJ... \
  -d client_id=app_123

Use this on logout to invalidate the refresh token.

Closing notes on implementation

Use a vetted OAuth2 client library instead of hand-rolling the redirect and exchange. In Python, authlib or requests-oauthlib handle PKCE, state validation, and token storage. State parameters prevent CSRF during the redirect. Always validate the redirect_uri against a whitelist on the authorization server.

The oauth2 authorization code flow llm api model shifts trust from a copied key to a mediated, scoped, revocable credential. For any LLM integration that serves more than one user, it is the correct baseline.

Tagsoauth2authorization-code-flowllm-apidefinition

Written by

n4n Team

The team building n4n — a single OpenAI-compatible API in front of 240+ models, with automatic fallback, load balancing and pay-per-token metering.

More from n4n Team →
API integrationOAuth2 client credentials flow for server-to-server callsImplement the OAuth2 client credentials flow for server-to-server calls to LLM APIs with runnable Python code, token caching, and end-to-end verification.API integrationOAuth2 scopes for fine-grained LLM API access controlLearn how to implement OAuth2 scopes for fine-grained LLM API access control with step-by-step token issuance, gateway enforcement, and verification.API integrationSecuring multi-tenant LLM APIs with OAuth2A practical guide to securing multi-tenant LLM APIs with OAuth2: tenant isolation, token design, scopes, introspection, and common pitfalls.API integrationBearer tokens explained: authenticating LLM API requestsBearer tokens explained LLM API auth: definition of the scheme, token flow over HTTP, a real request example, and common mistakes to avoid.API integrationBuilding an OAuth2 authorization server for LLM appsStep-by-step tutorial for building OAuth2 authorization server for LLM apps with FastAPI and Authlib, issuing scoped JWTs for model access.API integrationDebugging OAuth2 token expiry in production LLM appsHands-on step-by-step guide for debugging oauth2 token expiry production in LLM apps: reproduce expiry, inspect JWTs, fix refresh races, and verify.

All oauth2 & bearer token auth for llm platforms posts →