Authentication vs authorization: what's the difference?

Authentication answers "who are you?" Authorization answers "what are you allowed to do?" A hotel is the classic example: showing your passport at the front desk is authentication; the key card that opens your room, and not anyone else's, is authorization.

Every secure application does both, in that order: first establish who the user is, then check each action against what that user may do.

At a glance

Authentication

Authentication proves an identity. Common methods:

• Passwords, ideally with MFA (a second factor such as a TOTP app or SMS code).
• Passkeys (WebAuthn), which replace passwords with a key pair on the user's device.
• One-time codes and magic links by email or SMS.
• Single sign-on through an identity provider over OpenID Connect or SAML, so apps delegate the whole job.

The output is something the app can trust for the rest of the session: a session cookie, or an OpenID Connect ID token.

Authorization

Authorization decides, for each request, whether this user may perform this action on this resource. Common models:

• ACL: a list of who may do what with each object.
• RBAC: permissions belong to roles, such as editor or admin, and users get roles.
• ABAC: rules on attributes of the user, the resource and the context, such as "owners may edit their own documents during business hours".
• ReBAC: access follows relationships, such as "viewers of a folder may read the documents in it".

Apache Casbin explains these models side by side with examples.

Where OAuth 2.0 fits

OAuth 2.0 is an authorization protocol: it gives an application an access token to call an API on a user's behalf, limited by scopes. It was not designed to tell the app who the user is; OpenID Connect adds that authentication layer on top. See OAuth 2.0 vs OpenID Connect.

Where each check belongs

• Authenticate once, at the edge: at the identity provider, with the app or API gateway verifying sessions or tokens.
• Authorize close to the data: in the service that owns the resource, on every request. A token's scopes or roles say what an app or user is broadly allowed; the service still checks the specific record ("is this your invoice?").
• Never trust the client for either: hide a button for usability, but enforce on the server.

Doing both with Casdoor and Casbin

Casdoor is an open-source identity provider for authentication (passwords, passkeys, MFA, social and enterprise SSO over OIDC, SAML, CAS, LDAP and RADIUS). It's built around Casbin, the authorization library, so you can define roles and permissions with ACL, RBAC or ABAC models in Casdoor's console and check them from your apps, or embed Casbin directly in your code.

Self-host Casdoor for free, or run it on Casdoor Cloud from $24/month billed yearly. See also What is an identity provider and What is MFA.

FAQ

Which comes first? Authentication. You can't decide what someone may do until you know who they are, although some resources allow anonymous access.

Why does HTTP 401 say "Unauthorized" when it means unauthenticated? A historical naming quirk. RFC 9110 defines 401 as missing or invalid authentication credentials and 403 as understood but refused.

Is a JWT authentication or authorization? It's a token format used for both: an OIDC ID token is authentication; an OAuth access token carrying scopes or roles is authorization.

Is SSO authentication or authorization? Authentication. SSO lets one sign-in cover many apps; each app still decides what the user may do.