Authentication vs Authorization

Authentication and authorization are the two fundamental pillars of access control, yet they are routinely conflated in system design discussions. Authentication (authn) is the process of verifying that an entity is who it claims to be. When a user provides a username and password, or when a service presents a TLS client certificate, the system is performing authentication. The output of authentication is a verified identity: 'this request comes from user alice@example.com' or 'this request comes from the inventory-service.'

Authorization (authz) is the process of determining whether an authenticated identity is permitted to perform a specific action on a specific resource. After authentication establishes that the caller is alice@example.com, authorization checks whether Alice can read document 12345, delete user bob, or invoke the admin API. Authorization is inherently contextual: it depends on the action, the resource, the caller's roles or attributes, and potentially environmental factors like time of day or IP address.

The distinction matters architecturally because authn and authz scale, evolve, and fail differently. Authentication is typically centralized: all services delegate identity verification to a single identity provider (IdP) like Okta, Auth0, or an internal OAuth server. Authorization is typically distributed: each service (or a sidecar policy agent) makes its own permission decisions because it understands its own resource model. A document service knows what 'editor' means for a document; an inventory service knows what 'read-only' means for a warehouse.

In microservice architectures, authentication usually happens once at the API gateway (verify the JWT, extract the identity) and the verified identity is propagated to downstream services via headers or token forwarding. Authorization happens at each service boundary, because each service has different resources and permission models. This separation of concerns is essential: centralizing authorization in the gateway creates a single point of failure and forces all services to share a single permission model.

The most dangerous antipattern is encoding authorization decisions in the authentication token. Putting 'role: admin' in a JWT means the role is frozen for the token's lifetime (often 15-60 minutes). If you revoke the admin role, the user retains admin access until the token expires. Proper architecture keeps identity in the token and checks permissions in real-time against a policy store.

When you check into a hotel, the front desk verifies your identity (authentication) by checking your ID and reservation. They then issue a key card that opens specific rooms and facilities (authorization). The key card does not prove who you are -- anyone holding it can open the door. Similarly, a JWT proves identity was verified at issuance, but the token itself can be stolen. The hotel can also re-key your card if you extend your stay (dynamic authorization), but if permissions were written permanently onto the card at check-in, changing them would require issuing a new card (the JWT revocation problem).