How is authentication different from authorization? Where should you check permissions in a web application?

Authentication answers the question "who are you?", for example signing in with an email and password. Authorization answers "what are you allowed to do?", for example only the author may edit posts. The two are separate, and the most common mistake is to treat the first as if it included the second.

A concrete example: a blog writes the rule "anyone who is signed in may edit posts", because it assumes that only the author has an account. If the sign-in service also lets people sign up on their own, anyone can create an account, sign in validly and edit posts. That person was authenticated correctly, but never authorized.

As for where to check permissions, a good answer names three layers and what each one is for:

1. The interface (hiding buttons, redirecting): only so users see what they can use. It protects nothing, because people call the API directly.
2. The server (API routes, Server Actions, middleware): every point that receives a request must check again by itself, and not rely on which pages the user went through.
3. The database (for example PostgreSQL Row Level Security): the last layer, still correct when a layer above forgot a check somewhere.

Two more points that show you have done this for real:

• The information used for authorization must live somewhere the user can't edit. With Supabase, that is app_metadata, not user_metadata.
• On the server you must verify the token's signature and not just read the cookie, because users can set cookies in their own browser.

Bonus points: mention the codes 401 (not authenticated) and 403 (authenticated but not allowed), and the fact that a newly granted or revoked permission only takes effect when the token is refreshed.