EXPLAINER

API Authentication: Keys, Sessions and OAuth

Choose API keys for server-to-server access, session cookies for browser users, and OAuth when acting on a user's behalf at another provider. Always keep secrets on the server.

Short answer: Pick auth by situation: API keys for servers, sessions for your logged-in users, OAuth for delegated access — and never embed secrets in the browser.

What is it?

Authentication proves who is calling an API; authorisation decides what they may do. Common web patterns:

  • API keys / bearer tokens — secret strings your server sends to a vendor.
  • Session cookies — browser users logged into your app.
  • OAuth access tokens — delegated access to a third-party account (OAuth for AI Agents).

Why it matters

AI features are expensive and privileged. A leaked model key burns money; a leaked Google refresh token leaks mail. Putting secrets in front-end code is the most common failure (JavaScript for AI Applications).

How to do it

  1. Model vendor key → environment variable on the server only.
  2. End-user calls your /api/* → require your session/JWT; then your server uses the vendor key.
  3. User's Gmail → OAuth; store refresh tokens encrypted (Gmail and Google Integration for AI Agents).
  4. Rotate keys; scope them; never commit .env.
  5. Prefer short-lived access tokens where providers offer them.

Example

Browser sends Cookie: session=… to your API. Your API checks the session, then sends Authorization: Bearer sk-… to the model vendor. The browser never sees sk-….

When to use it

Always authenticate AI proxy routes. Public unauthenticated demo endpoints need strict rate limits and abuse plans if you must run them at all.

Practical notes

Rotation and least privilege close the loop. Issue separate keys per environment (dev/stage/prod) and per service. Prefer keys that can be limited by IP or by allowed models if the vendor supports it. For user sessions, set cookie flags ('HttpOnly', 'Secure', 'SameSite') appropriately. For OAuth, practice revoking tokens when employees leave. Security reviews should ask where every secret lives and who can read it. If a key leaks in a chat log, rotate first and investigate second. This topic connects directly to OAuth for AI Agents for delegated access and AI Privacy and Security: What to Know Before You Paste Data for data handling once calls succeed. Work through one real request end to end, write down the failure modes you observed, and add a regression test so the next change does not silently drop validation, auth, or logging. Prefer boring, reviewable code over a clever abstraction until the second or third product needs the same pattern. Work through one real request end to end, write down the failure modes you observed, and add a regression test so the next change does not silently drop validation, auth, or logging. Prefer boring, reviewable code over a clever abstraction until the second or third product needs the same pattern. Work through one real request end to end, write down the failure modes you observed, and add a regression test so the next change does not silently drop validation, auth, or logging. Prefer boring, reviewable code over a clever abstraction until the second or third product needs the same pattern. Work through one real request end to end, write down the failure modes you observed, and add a regression test so the next change does not silently drop validation, auth, or logging. Prefer boring, reviewable code over a clever abstraction until the second or third product needs the same pattern.

Common mistakes

  • VITE_OPENAI_KEY in client bundles.
  • Long-lived keys shared across all environments.
  • Logging full headers including Authorization.