Auth

Authentication schemes available across the API and demo credentials for each.

Authentication Methodology

This playground demonstrates four authentication schemes across its endpoints. Each scheme maps to a different API group to illustrate when and why each pattern is appropriate in a real integration architecture.

API Key

Long-lived opaque token, simplest to implement

Experience
Header
X-Api-Key: pk_demo_a1b2c3d4e5f6a7b8c9

Used by: Experience endpoints (GET /api/v1/experience, GET /api/v1/experience/:id)

Advantages

  • Zero client complexity — one string, one header
  • Easy to rotate without user impact
  • Suitable for server-to-server M2M calls

Trade-offs

  • No built-in expiry — rotation is a manual process
  • If leaked, valid until explicitly revoked
  • Carries no identity claims — just a shared secret

Not implemented — and why

Two common enterprise patterns are deliberately absent from the live demos. Here's the reasoning.

mTLS (Mutual TLS)

mTLS requires both parties to present X.509 certificates during the TLS handshake, providing cryptographic proof of identity at the transport layer. It's the gold standard for zero-trust service meshes (e.g. Istio, Linkerd) where every pod must prove its identity before any TCP connection is accepted. The reason it's not demonstrated here: Vercel's edge network terminates TLS before traffic reaches a serverless function, so there's no way to inspect the client certificate at the application layer without a dedicated load balancer or a non-serverless runtime. In a production microservices environment, I'd use mTLS via a service mesh for east-west traffic and reserve API key / OAuth for north-south (external) clients.

OpenID Connect (OIDC)

OIDC is an identity layer on top of OAuth 2.0 that introduces the ID Token — a JWT containing identity claims (sub, email, name) issued by an Identity Provider. It enables single sign-on across multiple services and is what Auth.js uses under the hood for the LinkedIn OAuth integration elsewhere on this platform. The reason it's not in the playground: OIDC requires a redirect-based browser flow (Authorization Code + PKCE) and an IdP callback. That's better demonstrated by the LinkedIn auth integration itself than by a synthetic endpoint. The playground focuses on headless M2M patterns where a client programme, not a user, is the caller.