Authentication vs. Authorization: what is the difference?

Authentication is a check of who you are; authorization is the per-request decision of what you may do. Every secure system needs both. The hotel makes it concrete: your ID at the front desk is authentication; the keycard that opens room 412 — and only room 412 — is authorization. They are different questions, asked at different times, answered by different machinery, and they fail in different ways — which is why systems that blur them ship both kinds of breach.

Key takeaways

How Authentication and Authorization Run on One Request

1  POST /login  (credentials + MFA)          ── AUTHENTICATION, once
   ← session token / cookie: identity established

2  GET /documents/xKd91m                     ── every request thereafter:
   a · token validated        → identity re-established     (authn machinery)
   b · permission evaluated   → may ADA read THIS document? (authz decision)

   → 200  both passed
   → 401  no/invalid token — WWW-Authenticate challenge; logging in fixes it
   → 403  token fine, permission denied — logging in again fixes nothing
   → 404  some APIs hide forbidden objects entirely (RFC 9110 allows it)

The same split in application code — log in once, get judged per operation:

// JavaScript / Node.js — Back4app JS SDK
// Authentication: once — who are you?
const user = await Parse.User.logIn('ada', password); // session token issued

// Authorization: every request — may YOU do THIS?
const doc = await new Parse.Query('Document').get('xKd91m');
// found if an ACL entry grants ada read · "not found" if not

doc.set('title', 'Renamed');
await doc.save(); // succeeds only if an entry grants ada WRITE

// Flutter / Dart — Back4app Flutter SDK
// Authentication: once — who are you?
final user = ParseUser('ada', password, null);
await user.login(); // session token issued

// Authorization: every request — may YOU do THIS?
final response = await QueryBuilder<ParseObject>(ParseObject('Document'))
    .query(); // returns only rows whose ACLs grant ada read

final doc = response.results!.first as ParseObject;
doc.set('title', 'Renamed');
await doc.save(); // succeeds only if an entry grants ada WRITE

// iOS / Swift — Back4app Swift SDK
// Authentication: once — who are you?
let user = try await User.login(username: "ada", password: password)
// session token issued

// Authorization: every request — may YOU do THIS?
guard var doc = try await Document.query("objectId" == "xKd91m").first()
else { return } // found only if an ACL entry grants ada read

doc.title = "Renamed"
_ = try await doc.save() // succeeds only if an entry grants ada WRITE

// Android / Kotlin — Back4app Android SDK
// Authentication: once — who are you?
val user = ParseUser.logIn("ada", password) // session token issued

// Authorization: every request — may YOU do THIS?
val doc = ParseQuery.getQuery<ParseObject>("Document").get("xKd91m")
// found if an ACL entry grants ada read · "not found" if not

doc.put("title", "Renamed")
doc.save() // succeeds only if an entry grants ada WRITE

Authentication vs. authorization, side by side

Two rows deserve their footnotes. Where it runs: authentication naturally concentrates at the edge — one login flow, one identity provider — while authorization belongs next to the data it protects, because “may this user touch this object” needs the object. Fails as: the threat models are disjoint — credential stuffing and phishing attack authentication (which is why MFA is the highest-leverage authn defense), while broken object-level authorization tops API security lists as the signature authz failure: logged-in user, wrong object, nobody checked.

401 and 403, precisely

The status codes are the distinction wearing numbers, and RFC 9110 is exact about it. 401 Unauthorized is history’s most durable misnomer: it means unauthenticated — the request “lacks valid authentication credentials,” the response must carry a WWW-Authenticate challenge, and presenting credentials can fix it. 403 Forbidden means the server understood exactly who was asking and refuses anyway — re-authenticating is pointless by definition. And the spec blesses a third move security teams love: answering 404 instead of 403, so a forbidden resource doesn’t confirm its own existence. Getting the codes right isn’t pedantry; clients build retry and re-login logic on them, and a 403 that should be a 401 sends users into a wall instead of a login form.

OAuth, OIDC, and the eternal confusion

The confusion has a spec-shaped answer. OAuth 2.0’s title is “The OAuth 2.0 Authorization Framework” — it moves scoped permissions, and the OpenID Connect spec exists precisely because OAuth alone “is incapable of providing information about the authentication of an end-user.” OIDC adds the identity layer: an ID token asserting who authenticated, distinct from the access token asserting what the bearer may do. Every “Sign in with…” button is OIDC doing authentication over OAuth’s authorization plumbing — one flow, both concepts, cleanly layered rather than confused.

The three mistakes that ship

Client-side authorization. Hiding the delete button is interface design; the server deciding whether delete executes is security. Per OWASP: deny by default, enforce server-side, and treat client checks as UX hints. Logged-in ≠ allowed. Checking authentication but not object ownership — /documents/42 served to any valid session — is broken object-level authorization, the most common API vulnerability class. The check is per-object, per-request, no exceptions. Middleware order. Authenticate first, authorize second, in code as in concept: the identity middleware establishes who, then handlers ask whether — and an authorization check that runs before identity is established silently authorizes the anonymous.

Common use cases

• App login + data permissions — the everyday pairing: one auth flow, per-object rules on everything after.
• API design — 401/403 semantics, scoped tokens, and object-level checks as the contract’s error language.
• Multi-tenant SaaS — authentication shared across tenants; authorization scoped hard inside each one.
• Admin and support tooling — step-up authentication and elevated authorization, deliberately separate events.
• Public + private content — anonymous read as an authorization rule, proving the two concepts run independently.

Which check are you missing? A decision matrix

Limitations and trade-offs

• The split is conceptual, not always architectural. Small apps reasonably run both in one middleware stack; the discipline is keeping the checks distinct, not the servers.
• Strong authn can’t rescue weak authz. Passkeys and MFA verify identity flawlessly for a system that then lets anyone read anything — the failures are independent.
• Per-request authorization has a cost. Caching decisions, pushing rules into the data layer, and indexing permissions are how “check everything” stays fast.
• Step-up blurs the timeline. Sensitive actions re-authenticate mid-session — authentication isn’t strictly “once,” it’s “once per assurance level.”
• Vocabulary drift causes real bugs. Teams saying “auth” for both halves write tickets, tests, and error codes that conflate them; the words are the cheapest defense.

Authentication and authorization on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The platform’s architecture is the split: the User class, sessions, social login, and the MFA adapter answer who you are, producing a revocable session token — and then ACLs, class-level permissions, and roles answer what you may do, evaluated server-side on every REST, GraphQL, and Live Query request, exactly as the code tabs show: log in once, get judged per operation. The mistakes section becomes structural: authorization can’t be client-side because Back4app enforces it behind the API, unauthorized objects come back as not-found rather than confirming their existence, and deny-by-default is one checkbox on a class. The two questions stay separate because the platform never lets them merge.