Authentication vs Authorization: How Identity and Access Control Work Together

Authentication vs Authorization: How Identity and Access Control Work Together

Authentication and authorization solve different security problems:

• Authentication (AuthN): Who are you?
• Authorization (AuthZ): What are you allowed to do?

Authentication Comes First for Protected Identities

Authentication may use passwords, MFA/passkeys, secure sessions, certificates, or federated identity such as OpenID Connect.

A successful login establishes a trusted principal. It does not imply unlimited access.

Authorization Is Resource-Specific

Suppose a logged-in user requests:

DELETE /projects/42

The backend may need to verify:

user is authenticated
AND user has project.delete permission
AND project 42 belongs to the correct tenant
AND current policy permits deletion

OWASP recommends validating authorization on every protected request and denying by default.

Roles Are Only One Input

Authorization can use:

• RBAC roles
• attributes
• object ownership
• tenant/workspace membership
• relationships
• contextual policy

Do not accept role or tenant authority from client-controlled request fields.

Re-Authentication Is Different Again

A user may already be authenticated and authorized, but a sensitive action can still require fresh authentication—for example changing MFA, exporting secrets, or approving a high-value transaction.

This confirms recent possession of the required authenticator; authorization still decides whether the user is permitted to perform the action.

Common Mistake

Bad:

Logged in? → allow endpoint

Better:

Authenticated identity
→ authorize action
→ authorize specific resource
→ execute

Final Takeaway

Authentication establishes identity; authorization applies policy to that identity, action, and resource. Keep the two concepts separate in code and architecture so a valid login can never accidentally become universal permission.

References

• OWASP Authentication Cheat Sheet
• OWASP Authorization Cheat Sheet