Authentication establishes which principal is making a request using evidence such as a session, key, or signed challenge. Authorization decides whether that principal may perform a specific action on a specific resource in the current context. Successful sign-in never grants every permission. Both checks belong on trusted server boundaries, with denial as the default when evidence is absent or ambiguous.
Who this is for: Application developers who need to design sign-in, permissions, and protected operations without confusing identity with access.
- Model identity evidence and permission policy as separate concerns with separate failure outcomes.
- Authorize the action and resource on the server, even when the interface hides unavailable controls.
- Use short-lived, scoped credentials and auditable policy decisions for consequential operations.
Authentication establishes a principal
A principal may be a person, service, device, or workload. Authentication verifies presented evidence and binds the request to that principal. Passwords, passkeys, client certificates, API keys, and external identity providers offer different security and recovery properties. The application should not infer identity from an editable user identifier in the request body.
After verification, the system normally issues or recognizes a credential such as a server session cookie or access token. Protect credential transport, storage, rotation, expiration, and revocation. Multi-factor authentication can strengthen account access, but recovery and enrollment paths require equal care because attackers target the weakest way to obtain a valid identity.
Authorization evaluates a request
Authorization asks whether this principal may do this action to this resource now. Inputs can include role, ownership, organization membership, resource state, plan, device posture, or an explicit grant. A role such as editor is only a compact policy input. It should not become a scattered collection of client-side string comparisons.
Check permission close to the protected operation and after loading enough trusted resource context. A project member might read a document but not change billing. An administrator in one organization has no authority in another. List endpoints must also filter unauthorized records; protecting detail endpoints alone can leak names and metadata.
Failures should reveal only what is safe
Missing or invalid authentication generally calls for an authentication challenge or sign-in path. An authenticated principal without permission receives a denial. For private resources, returning not found can sometimes avoid confirming existence, but teams should document that policy consistently. Error detail must not reveal another user's membership, secret identifier, or internal policy structure.
Client interfaces may disable or hide unavailable actions to reduce confusion, but that is presentation, not enforcement. Attackers can call an endpoint directly or change client code. Server-side authorization must cover every path that reaches the same effect, including background jobs, bulk tools, imports, and administrative scripts.
Policy needs tests and operations
Create an access matrix for principal types, resources, actions, and important states. Test allowed and denied cases, cross-tenant identifiers, stale membership, suspended accounts, and indirect references. Central helpers can improve consistency, but each call must provide the correct resource rather than authorizing only a broad route category.
Record consequential authorization decisions with principal, action, resource reference, outcome, and policy version while minimizing sensitive data. Alert on unusual denial spikes or privilege changes. Review service credentials and roles for least privilege. When policy changes, test existing sessions and queued work so old authority does not persist unexpectedly.
Protect an invoice download
An authenticated user requests an invoice by changing the identifier in a download URL.
- Authenticate the session from a protected cookie and obtain the server-trusted user and organization identifiers.
- Load the invoice by identifier within the trusted organization scope instead of loading globally and comparing client input later.
- Authorize invoice reading based on membership, billing permission, invoice state, and any support delegation policy.
- Return the file with safe headers only after approval, and use a non-revealing denial when the invoice is outside the scope.
- Test valid ownership, another organization's identifier, removed membership, expired session, and support access expiration.
Access decision worksheet
Use one row per consequential action when reviewing access control.
- Principal: identity type, authentication evidence, credential age, tenant, and account state.
- Action: exact read, create, change, delete, approve, export, impersonate, or administrative effect.
- Resource: trusted identifier, owner, tenant, lifecycle state, sensitivity, and related objects.
- Policy: roles, grants, conditions, default denial, safe error, audit event, and policy owner.
- Tests: allowed case, ordinary denial, cross-tenant reference, stale authority, and alternate execution path.
Common mistakes
- Treating a valid session as permission to access any object whose identifier the caller knows.
- Enforcing permissions only by hiding buttons in the browser interface.
- Giving a background service broad administrative credentials when it needs one narrow operation.
Try one
A signed-in team member can edit any workspace by changing workspaceId in a request. Explain the root cause and the complete correction.
The application authenticated the caller but failed to authorize the requested resource. The correction derives identity from trusted session evidence, loads the workspace within an authorized membership scope, checks edit permission and state on the server, and denies cross-workspace access without revealing private details. Tests must cover another workspace, removed membership, read-only roles, and alternate edit endpoints.
Sources
- MDN HTTP authenticationMDN guidance on HTTP authentication schemes and access restrictions.
- GitHub authentication guidanceGitHub's overview of authentication methods and credential handling.