Authentication vs authorization
Authentication verifies who a user or a system is: a password, a passkey, a one-time code, or delegating the check to a provider such as Google. Authorization decides what that authenticated identity is allowed to do: view a project, edit an invoice, invite a colleague. The first answers “who are you?”, the second “may you do this?”, and each needs its own checks.
Why it matters for a PM
Confusing the two leads to classic security flaws, such as a signed-in user who opens another customer's data by changing an ID in the URL. PMs make many of the decisions involved: which sign-in methods to offer, how long sessions last, when to require a second factor, which roles exist and what each one can do.
Example
An employee signs in to an expense tool with their company account: that is authentication. They can submit expenses but only their manager can approve them, and finance alone can export the month's report: those rules are authorization, checked on each request.
Key points
- After sign-in, a session or a token (often a JWT) carries the identity with each request.
- Multi-factor authentication and passkeys reduce account takeover far more than complex password rules.
- OpenID Connect handles sign-in with an external identity provider; OAuth 2.0 handles delegated access to APIs.
- Authorization is enforced on the server for every request, not only reflected in the interface.
Common mistakes
- Hiding a button and assuming the action is protected.
- Long-lived sessions with no way to revoke access when an employee leaves.
- Treating enterprise SSO as an afterthought when selling to large companies.
Go further with Module
The courses and lessons that cover this concept: