Authentication and Authorization: Identity Before Permission

Logging in and receiving permission are related, but they are not the same operation.

Authentication asks who or what is making a request. Authorization asks what that identity may do to a particular resource.

A system can authenticate someone correctly and still make a dangerous authorization decision.

A concrete example: an employee badge

At an office entrance, a badge and PIN may prove that a person is employee Mira Rao. That is authentication.

Mira's role may allow access to the design floor but not the payroll archive. That is authorization.

The guard should also consider context:

• Is the badge active?
• Is access allowed at this time?
• Is the door appropriate for this role?
• Was the badge reported lost?

Identity is an input to the access decision, not the whole decision.

Authentication evidence

Authentication can use:

• Something you know, such as a password
• Something you have, such as a security key
• Something you are, such as a biometric characteristic
• A trusted device identity
• A cryptographic certificate or key
• A previously established session

Evidence quality varies. A text message to a phone number and a hardware security key are both possession-related, but resist different attacks.

Authentication strength should match the risk of the action.

Human and service identities

Systems authenticate more than people.

Identities can represent:

• Users
• Applications
• Servers
• Devices
• Scheduled jobs
• External organizations

A backup process may use a service identity allowed to write backups but not delete source data.

Sharing one service account among many applications makes attribution and least privilege difficult. Separate identities make permissions and revocation clearer.

Enrollment establishes trust

Before an authenticator proves identity, the system must connect it to the right subject.

Enrollment may involve:

• Verifying an email address
• Checking an identity document
• An administrator creating an employee account
• Registering a security key
• Issuing a device certificate

Weak enrollment undermines strong login. If an attacker can register their own factor through an insecure recovery flow, robust MFA at normal sign-in does not help.

Account recovery deserves protection comparable to authentication.

Sessions preserve authenticated state

Users should not re-enter credentials for every request.

After authentication, a server may create a session and give the browser a random session cookie. Later requests present the cookie.

Sessions need:

• Unpredictable identifiers
• HTTPS transport
• Secure cookie settings
• Expiration
• Revocation
• Rotation after privilege changes
• Protection against cross-site attacks

Anyone who steals a valid session may act as the user without knowing the password. Session security is part of authentication security.

Tokens carry claims

Some systems issue signed tokens containing claims such as:

• Subject identity
• Issuer
• Audience
• Expiration
• Authentication method
• Scopes or roles

The receiving service verifies the signature and claims.

A valid signature proves the trusted issuer created the token. It does not prove the request is authorized for every resource.

Services must check audience, expiration, issuer, and applicable permissions rather than merely decode the token.

Authorization models

Common models include:

• Role-based access control: Permissions attach to roles such as editor or auditor.
• Attribute-based access control: Decisions use properties such as department, location, sensitivity, and time.
• Access control lists: A resource lists allowed identities or groups.
• Relationship-based control: Access follows relationships such as document owner, team member, or organization administrator.
• Capability-based control: Possession of an unforgeable reference grants specific authority.

Real systems often combine models.

Choose one that expresses business rules clearly and can be reviewed.

Least privilege and default denial

Least privilege grants only required actions.

Default deny means access is rejected unless a rule explicitly allows it.

This is safer than assuming new resources or actions are public until someone adds a restriction.

Permissions should be narrow across:

• Action: read, create, update, delete, approve
• Resource: one project, tenant, or record
• Time: temporary versus permanent
• Environment: development versus production

Administrative access should be rare, monitored, and separated from everyday accounts.

The confused deputy problem

A service may have powerful access and be tricked into using it for an unauthorized caller.

Suppose an image service can read every customer file. A user asks it to resize a path belonging to another customer. If the service checks only that the caller is logged in, it becomes a confused deputy.

The service must verify authorization for the requested object, not merely rely on its own backend permission.

User input should never select a privileged resource without an ownership or policy check.

Object-level authorization

A common vulnerability occurs when an application checks whether a user can access the orders page but not whether they can access order 9001.

Changing a URL from:

/orders/9001

to:

/orders/9002

must not reveal another customer's order.

Authorization belongs on every operation at the trusted server boundary. Hiding a button in the user interface is useful design but not enforcement.

Authentication can change during a session

Risk changes over time.

Systems may require step-up authentication before:

• Changing a password
• Viewing recovery codes
• Sending a large payment
• Adding an administrator
• Exporting sensitive data

The user proves stronger or more recent identity evidence for the high-impact action.

Sessions should also react to password reset, account disablement, factor removal, and suspicious activity.

Logging and privacy

Authentication and authorization logs can record:

• Successful and failed sign-ins
• Factor changes
• Permission grants
• Privileged actions
• Denied access
• Session revocation

Logs support detection and accountability, but can reveal identifiers, locations, resource names, and behavioral patterns.

Protect them, limit retention, and avoid recording passwords, session tokens, or unnecessary personal data.

Common design failures

Watch for:

• One shared administrator account
• Authorization only in the client interface
• Permanent broad service credentials
• Tokens accepted without issuer or audience checks
• Recovery flows weaker than login
• Permissions that accumulate after role changes
• No way to revoke sessions
• Public access as the default

Identity systems are security-critical infrastructure. Simplicity, tested libraries, and centralized policy often reduce inconsistent decisions.

Knowledge check

1. How does authentication differ from authorization?
2. Why can account recovery undermine strong MFA?
3. What does a valid signed token prove, and what does it not prove?
4. What is object-level authorization?
5. How can a privileged service become a confused deputy?

The one idea to remember

Authentication establishes an identity; authorization evaluates that identity's permission for a specific action and resource. Strong systems verify both at trusted boundaries and deny access unless it is deliberately granted.