Authentication vs Authorization

Two words that sound alike and do different jobs. Getting them straight clarifies both your code and your status codes.

The difference

Authentication (authn) — who are you? The client proves its identity with a credential: an API key, a session cookie, or a bearer token.
Authorization (authz) — what are you allowed to do? Given a known identity, the server decides whether this caller may perform this action on this resource.

Authentication comes first; authorization builds on its result. A request can be authenticated (we know who you are) yet unauthorized (you still may not do that).

Their status codes

401 Unauthorized — authentication failed or was missing. The client should supply or refresh credentials. Conventionally accompanied by a WWW-Authenticate header.
403 Forbidden — authentication succeeded, but the caller lacks permission. Sending different credentials will not help.

Carrying the credential

Identity travels in the Authorization header:

GET /me HTTP/1.1
Authorization: Bearer eyJhbGciOiJI...

A minimal auth gate

JavaScript

const KEYS = new Set(['key-abc', 'key-def']);
const ADMIN = new Set(['key-abc']);

// authn: is the key valid?
app.use('*', async (c, next) => {
  const key = c.req.header('Authorization')?.replace('Bearer ', '');
  if (!key || !KEYS.has(key)) {
    return c.json({ title: 'Unauthorized', status: 401 }, 401, { 'WWW-Authenticate': 'Bearer' });
  }
  c.set('key', key);
  await next();
});

// authz: is this key allowed here?
app.delete('/articles/:id', (c) => {
  if (!ADMIN.has(c.get('key'))) {
    return c.json({ title: 'Forbidden', status: 403 }, 403);
  }
  return c.body(null, 204);
});

Common mistakes

Returning 403 instead of 401 when there’s no token Symptom:

A request with no Authorization header gets a 403
The client doesn’t realize it needs to log in — it looks like a permissions problem
No token or an invalid token → 401; authenticated but lacking permission → 403

Incomplete authorization checks Symptom:

Permission is checked at the route level but not at the resource level
GET /orders blocks unauthorized callers, but GET /orders/\{id\} never checks whether that order belongs to the caller
Check both the action permission and resource ownership

💡 Real-world examples

GitHub API:

401 when the token is invalid or expired

403 when the token is valid but lacks permission for that operation (e.g. pushing to a repo you don’t own)

AWS API:

Authentication via SigV4 — every request is signed

Authorization via IAM policy — which actions are allowed on which resources

Sources: GitHub REST API — troubleshooting, AWS IAM policies