Authentication vs Authorization

Two distinct security steps. Authentication (AuthN) verifies identity, confirming the caller is who they claim to be, via passwords, tokens, certificates, or biometrics. Authorization (AuthZ) verifies permission: given a known identity, deciding whether they may perform a specific action on a specific resource, via roles (RBAC), attributes (ABAC), or policies.

Systems need to both establish identity and enforce boundaries. Authentication answers 'who are you?', and without it, anyone is anonymous. Authorization answers 'are you allowed to do this?', and without it, any authenticated user could do anything. Separating them keeps each concern clean: you authenticate once and authorize on every sensitive action.

AuthN: the user presents credentials; the system verifies them and issues a token (a signed JWT, or an opaque session id stored server-side). Standards like OAuth2 (delegated access) and OIDC (identity on top of OAuth2) handle this for third parties. AuthZ: on each request, the system reads the identity from the token and checks it against a policy: RBAC maps users to roles to permissions; ABAC evaluates attributes (department, resource owner, time); policy engines (OPA) externalize the rules. The gateway or service enforces the decision before doing the work.

• Separating identity from permission keeps each concern clean and independently testable
• Standards (OAuth2/OIDC, JWT) mean you rarely build authentication from scratch
• RBAC/ABAC let permission rules evolve without touching authentication

• JWTs are hard to revoke before expiry: a stolen token is valid until it expires unless you add a denylist
• Authorization logic sprawls: scattered ad-hoc checks across services drift and create security holes
• OAuth2/OIDC are notoriously easy to misconfigure (redirect URIs, scopes, token validation) into vulnerabilities

• Payment Gateway →

  API-key authentication identifies the merchant; authorization scopes restrict which operations and accounts that key may touch

• URL Shortener →

  The API gateway authenticates the JWT and authorizes whether the user may create or manage a given short link

• Google Docs (Realtime Collab) →

  Authentication identifies the editor; per-document authorization (owner/editor/viewer) decides who can read vs write each doc

• AuthN and AuthZ are not the same check. 'You're logged in' never implies 'you may do this'; a valid token still has to pass an authorization check on the specific resource.
• Stateless JWTs trade revocability for scalability: you can't easily kill one mid-life. Use short expiries plus refresh tokens, or keep a revocation list, for anything sensitive.
• Centralize authorization. Ad-hoc 'if user.role == admin' checks copied across services inevitably drift, so push the decision to a gateway or a policy engine (OPA) with one source of truth.
• Always validate token signature, issuer, audience, and expiry on every request. Skipping any of these is the classic JWT vulnerability; trusting an unvalidated token is no security at all.