Authentication · Verified identity
Authentication: establishing a verified identity
Follow credentials, handlers and principals through the question “Who are you?”
Understand the concept
Authentication verifies an identity claim using trustworthy evidence. Typing a name or email is not authentication. A request may present a cookie, bearer token, client certificate or another credential. A selected handler validates that evidence and, on success, creates a principal with claims. The scheme and source of those claims matter.
Authentication does not grant every permission. A valid employee identity still needs permission to read another employee’s salary. Evaluate the resource, operation, tenant and policy separately. CORS does not authenticate, HTTPS does not grant resource access, and decoding a JWT does not validate it.
Design the full lifecycle: initial login, failed attempts, expiry, renewal, logout and account closure. Passwords need appropriate hashing rather than plaintext storage. This course describes the security model rather than providing a complete login implementation. Subsequent lessons examine challenges, cookies, JWT validation and delegated access.
When separating login from API resource protection.
Trusting a client-supplied userId rather than a verified principal.
One topic. Three levels of depth.
Request → credential → authentication handler → principalThe identity chain; invalid credentials do not establish a verified principal.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
Can everyone with an HTTPS connection read /admin?
Show the solution and explanation
HTTPS ≠ authentication ≠ authorizationNo. An encrypted connection does not grant identity or administrator permissions.