OAuth 2.0

OAuth 2.0 is how I certify identity and delegated access across systems. I choose the right flow for the right client — authorization code with PKCE for browsers and SPAs, client credentials for service-to-service, and refresh-token rotation where sessions outlive short-lived access tokens.

Security discipline sits around the protocol: scopes kept to least privilege, token expiry and rotation enforced, and a clear separation between what OAuth authorises (access) and what OpenID Connect certifies (identity).

The seams matter as much as the flow — token introspection at services, consistent validation of audience and issuer, and revocation paths. I wire it into gateway layers so individual services never hand-roll auth.

Choosing the right grant is the first decision. Public clients like SPAs get authorization code with PKCE — no client secret in the browser, a short-lived access token, and a refresh token that can be rotated. Server-to-server calls use client credentials with a bounded scope.

Scopes are the access-control vocabulary. I grant the minimum a client needs, never all-or-nothing, so a compromised token can only touch what its scope allows. Least privilege is a design target, not an afterthought.

Tokens are short-lived by default, and sessions survive on refresh tokens that rotate on use. That bounds the blast radius of a leak, and it is how standing sessions stay standing without exposing long-lived bearer credentials.

The distinction between authorisation and identity matters. OAuth 2.0 says what a caller may do; OpenID Connect adds who the user is. I layer OIDC on top for identity claims rather than overloading access tokens with identity intent.

Enforcement happens at the gateway, not in every service. A central auth boundary validates tokens, checks scopes, and introspects where needed, so downstream services can trust the request and focus on their own logic instead of each re-implementing auth.

I keep provider portability in mind: the flow is the same whether the authority is a self-hosted IdP, a cloud issuer, or a third party, so identity infrastructure can change behind a stable contract without touching every client.

I pick the grant by the client, not by habit. SPAs and browsers get authorization code with PKCE, service-to-service gets client credentials, and third-party access gets the appropriate delegated flow.

Scopes are least-privilege by construction. Every client gets the minimum scope it needs, so a compromised token can only touch what its scope allows.

Tokens are short-lived by default, and sessions survive on refresh tokens that rotate. That bounds the blast radius of a leak and keeps standing sessions without exposing long-lived bearer credentials.

Identity and authorisation stay separate. OAuth 2.0 says what a caller may do; OpenID Connect adds who the user is — I layer OIDC on top rather than overloading access tokens with identity intent.

Enforcement lives at the gateway. A central boundary validates tokens and scopes, so downstream services trust the request and never each re-implement auth.

Issuer, audience, signature, and expiry are all checked. A token that is signed but aimed elsewhere is rejected, not trusted.

Revocation paths are real. For a leaked or compromised token I have a way to kill it early, not just wait for expiry.

Provider portability is kept in mind. Whether the authority is self-hosted or a cloud issuer, the flow stays constant behind a stable contract.

I treat security as configuration, never as magic. Every flow and scope is understood and documented, because an auth surface nobody can reason about is a liability.