What is the Access Token pattern (JWT/OAuth2) for service-to-client authentication?

The Access Token pattern uses short-lived cryptographically signed tokens — most commonly JWTs issued via OAuth 2.0 / OpenID Connect — to authenticate client requests to microservices. The client authenticates once with an Authorization Server (Keycloak, Okta, Cognito) and receives a JWT. Subsequent requests carry this token; any service that holds the corresponding public key can validate it locally without calling the Auth Server on every request.

JWT structure — three Base64URL-encoded segments separated by dots (header.payload.signature):

// Header (algorithm and token type)
{ "alg": "RS256", "typ": "JWT" }

// Payload (claims)
{
  "sub": "user-42",
  "iss": "https://auth.example.com",
  "aud": "order-service",
  "exp": 1714003200,   // expiry Unix timestamp
  "scope": "orders:read orders:write"
}

// Signature: RS256(base64(header) + "." + base64(payload), privateKey)

// HTTP request
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Validation at the receiving service (API Gateway or service itself):

1. Decode the header to get the signing algorithm and key ID (kid).
2. Fetch (or cache) the public key from the Auth Server's JWKS endpoint.
3. Verify the signature using the public key.
4. Check exp (not expired), iss (trusted issuer), and aud (this service is the intended audience).
5. Extract sub and scope claims to enforce authorisation.

Short token lifetimes (5–15 minutes) limit the blast radius if a token is stolen. Refresh tokens (longer-lived, stored securely by the client) are exchanged for new access tokens when the old one expires, without requiring re-authentication.