The Authentication-Authorization Separation

OAuth 2.0 is fundamentally an authorization protocol that delegates permission management, while OpenID Connect layers identity verification on top by introducing the ID token. This distinction matters in production because OAuth alone tells you "what can this client access," but OIDC tells you "who is this user." When building token-based APIs, conflating these two creates security vulnerabilities and scalability issues. The ID token in OIDC includes claims like subject (sub), issuer (iss), and audience (aud), which enable stateless verification of user identity without hitting the authorization server on every request. This is critical for distributed microservices where maintaining session state becomes expensive.

Authorization Code flow with Proof Key for Code Exchange(PKCE) adds proof-key cryptographic binding to prevent authorization code interception in mobile and single-page applications. The attacker cannot replay a stolen code without the code_verifier, making this flow mandatory for public clients. PKCE is not optional anymore for production SPAs, even though many legacy implementations treat it as such.

Scope Granularity and Refresh Token Rotation

Scopes are not just strings, they define the exact boundary of what a client can request. This granularity prevents the "asking for all permissions" antipattern and reduces blast radius when tokens leak. A well-designed scope strategy uses hierarchical naming like api:read:users instead of broad scopes like admin.

Refresh token rotation improves security by issuing new refresh tokens with each use. When a client exchanges a refresh token for a new access token, the authorization server simultaneously revokes the old refresh token and returns a new one. This forces attackers to continuously interact with the server, enabling anomaly detection if multiple refresh attempts occur in quick succession.

Token Introspection vs Self-Contained Verification

Token introspection endpoints allow resource servers to validate tokens with the authorization server in real-time, trading latency for certainty. This is necessary when revocation needs to be instant (like when a user gets fired) or when scopes change mid-session. However, introspection adds network hops and fails silently if the auth server is down, making it unsuitable for critical path operations.

Self-contained tokens (JWTs with cryptographic signatures) enable resource servers to verify tokens offline without calling back to the authorization server. The tradeoff is that revocation becomes eventual and requires caching strategies. Production systems often use both: issue short-lived access tokens (5-15 minutes) for offline verification and use introspection only for long-lived operations or sensitive permissions. This hybrid approach minimizes latency while ensuring security boundaries are enforced.

Applied Insight: When to Architect What

Use Authorization Code with PKCE for all public clients (mobile apps, SPAs) and enforce refresh token rotation as default behavior. Never issue refresh tokens without rotation, static refresh tokens are debt. For resource servers, design around the token lifetime: if access tokens live 5 minutes, introspection on every request is overkill. Cache the introspection result or batch validation. Implement scope hierarchies early because retrofitting them into a system with broad scopes like "full access" becomes a breaking change. If your API needs instant revocation (financial systems, access control), plan for introspection overhead and consider issuing shorter access tokens instead. Lastly, always validate the audience (aud) claim in your resource server even with OIDC, because a token valid for service A should never grant access to service B.