THE SHORT ANSWER
Authentication uses evidence such as a password, passkey or trusted identity provider to establish identity. A session carries that identity between requests. Authorization then applies permissions to a specific action and resource. Roles can group permissions, but protected operations still need server-side checks and least-privilege access.
Separate identity from permission
| Concept | Question | Example |
|---|---|---|
| Account | Which identity is represented? | A learner or administrator profile |
| Authentication | Can this person prove that identity? | A verified sign-in |
| Session | How is identity carried across requests? | A short-lived, protected session |
| Authorization | May this identity perform this action? | An administrator may edit a program |
| Role | Which permissions are grouped together? | Learner, editor or administrator |
A signed-in user is not automatically allowed to see every record or call every operation.
Evidence & context: OWASP Foundation
Write a permission model before building admin features
- List the people or systems that need access.
- List the actions each identity needs: view, create, edit, approve, export or delete.
- Identify whether access applies to all records or only owned records.
- Decide which operations require stronger confirmation or an audit trail.
- Remove permissions that are convenient but not required.
Evidence & context: NIST
Enforce protected decisions on the server
Hiding an admin button in the interface is useful presentation, but it is not authorization. A user can alter browser requests. The server or database policy must independently confirm identity, permission and the specific resource before reading or changing protected data.
Keep private credentials in protected server configuration. Avoid placing secret keys in browser code, URLs, public repositories or logs.
Evidence & context: OWASP Foundation · OWASP Foundation
Test access as carefully as the happy path
- Signed-out access to protected pages and operations
- One user attempting to read or edit another user's data
- A normal user attempting an administrator action
- Expired and revoked sessions
- Changed roles taking effect
- Direct API requests that bypass the visible interface
Connect these checks to the broader pre-launch testing plan.
Sources & further reading
- Authorization Cheat Sheet
OWASP Foundation. Security guidance emphasizing least privilege, deny-by-default behavior and authorization checks on every request. Implementation details depend on the application's threat model.
- Secrets Management Cheat Sheet
OWASP Foundation. Security guidance on secret creation, storage, distribution, rotation and revocation. It supports the principle that private credentials do not belong in public client code.
- Secure Software Development Framework
NIST. Outcome-based secure-development guidance covering preparation, protection, secure production and vulnerability response. It is a framework, not a product-specific checklist.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗