Backend
Authentication
Proving identity — verifying you are who you claim, via passwords, magic links, OAuth/OIDC, passkeys or multi-factor. It answers 'who are you?' and issues a session or token on success. Store passwords only as salted, slow hashes (bcrypt or argon2), and keep it clearly separate from authorization, which decides what you may do.
Purpose
Authentication establishes who a caller is — verifying a claimed identity through passwords, magic links, social login (OAuth/OIDC), passkeys or multi-factor — and issues a session or token that later requests present. It answers 'who are you?', the prerequisite for every access decision.
When to Use It
Every application with accounts needs it, and the method scales with risk: passwords plus MFA for consumer apps, OIDC/SSO for enterprise, passkeys for phishing-resistant login.
Once requirements grow, delegate it to a dedicated identity provider (Keycloak, Auth0, Cognito) rather than rolling your own.
Trade-offs
Building it yourself means owning password storage, reset flows, MFA and session management — a large, security-critical surface. Outsourcing to an identity provider lowers risk but adds a dependency and integration work. Keep it strictly separate from authorization.
Implementation
Never store raw passwords — use a slow, salted hash (bcrypt or argon2). Issue an opaque session cookie or a signed token on success with HttpOnly, Secure, SameSite attributes, and rate-limit login attempts. Prefer standards (OIDC) and a hardened provider over bespoke flows.