API Authentication Patterns
Implement the three authentication patterns that cover almost every real API — service-to-service API keys, JWT bearer tokens, and the OAuth 2.1 authorization code flow with PKCE — and understand exactly what each one protects against.
Prerequisites: comfort with HTTP and basic cryptographic concepts (hashing, signatures); Node.js; a REST API to protect (the one from the first project in this roadmap works well).
Version note: verified against the OAuth 2.1 Authorization Framework (draft-ietf-oauth-v2-1-15, an active IETF Internet-Draft last published March 2026, set to expire 3 September 2026 unless resubmitted) and RFC 7519 (JSON Web Token). Flag clearly: OAuth 2.1 is still a draft, not a published RFC, as of July 2026 — its core rules (PKCE required for every authorization-code client, no implicit grant, no resource-owner-password-credentials grant) have already been widely adopted in practice because they consolidate security fixes from several existing OAuth 2.0 RFCs, but check the datatracker link for the current draft number before building anything that must track the spec precisely.
Authentication answers "who is this?"; authorization answers "what are they allowed to do?" — APIs need both, but they're solved by different mechanisms, and conflating them is where a lot of insecure designs start.
This project covers three patterns in order of increasing complexity: static API keys for trusted service-to-service calls, JWT bearer tokens for stateless session-like auth, and the OAuth 2.1 authorization code flow for the case that actually needs it — a third-party application acting on behalf of a human user without ever seeing their password.
Test what you just learned
Self-testing is one of the best ways to retain new skills. Unlock project quizzes to check your understanding.
Log in to unlock0 / 7 complete