Authentication is proving who you are. Authorization is deciding what you can do.
When you log in to a website, that's authentication — the server checks your email and password and says "yes, you're Alice." Once the server knows you're Alice, it can decide what you're allowed to see or do — that's authorization.
Because they're independent. You can have one without the other.
Remember the capability URL from the previous chapter? Anyone with the link could see the results — no login required. That was authorization without authentication. The URL itself was the permission.
The reverse happens too. You can authenticate a user — confirm they're Alice — but still deny access because Alice doesn't have admin privileges. That's authentication without authorization.
Separating the two lets you pick the right tool for the job. Sometimes a link is enough. Sometimes you need to know who's visiting. Sometimes you need both.
report:read permission." or "No, she doesn't have admin access."Authentication answers identity. Authorization answers whether that identity can perform a specific action on a specific resource.
In practice, authentication is the harder problem — passwords, sessions, tokens, email verification. Authorization can start as a simple admin-only check, then grow into roles, ownership rules, and fine-grained policies.
That's why when developers say "auth," they often mean authentication — and why authorization is a natural extension once you know who's there.