Authentication & Authorization Basics

These are two different questions that are easy to conflate. Authentication (authn) answers "who are you?" (proving identity). Authorization (authz) answers "what are you allowed to do?" (permissions), and it only makes sense once identity is already established.

• -API keys: a static secret the client sends with every request. Simple, but hard to scope finely and awkward to rotate.
• -Session cookies: the server keeps session state (in a shared store, per Module 2) and hands the client an opaque reference to it.
• -JWTs (JSON Web Tokens): a signed, self-contained token holding the user's identity and claims. No server-side lookup needed to validate it, at the cost of harder revocation.
• -OAuth2: a protocol for delegated access ("let this app read my calendar without giving it my password"), which is how "Sign in with Google" flows work under the hood.

Once you know who someone is, RBAC (Role-Based Access Control) assigns them one or more roles ("admin," "editor," "viewer"), and each role carries a set of permissions. Checking authorization becomes a lookup ("does this user's role permit this action?") instead of hardcoding per-user rules that don't scale past a handful of users.