Authentication & Identity

A secure channel tells you that nobody tampered with the request. It says nothing about who sent it, or whether they were allowed to. This domain covers the two questions that follow — who are you and what may you do — which are routinely confused, and whose confusion is behind a large share of real breaches. Authentication is a claim you verify once. Authorization is a decision you make on every single request, and getting the first one right buys you nothing if you skip the second.

The domain runs the identity story end to end. It starts where a password actually lives: a slow hash, a rate limiter, a second factor, and the account recovery flow that is so often the softest way in. It then follows that proven identity as it travels — a cookie with the right flags, a stateless token, a Kerberos ticket issued by a KDC, an OAuth authorization code redeemed by an app that never sees the password, an OIDC id_token carrying verified claims. You will verify a JWT by hand and then break it twice, with alg:none and with key confusion, before fixing the verifier. Finally the question turns to permissions: RBAC, ABAC and ReBAC as three ways of writing the same decision, policy documents where an explicit deny must win, and cloud IAM where an over-broad grant is the normal way things go wrong. A capstone ties the three pillars into one authorization decision that holds up.