To fix it, I had to untangle the truth about API tokens and OAuth 2.0. Not the vague, high-level explanation. The real thing. How tokens work, how they expire, how scopes keep them in check, and why the entire system is more brittle than most assume until it breaks under load.
API tokens are strings of power. They grant machines access to resources, bypassing username and password prompts. In OAuth 2.0, they come in different flavors: access tokens, refresh tokens, and sometimes ID tokens. An access token is the short-lived pass for the API. A refresh token is the longer-lived credential that can mint new access tokens without asking the user to log in again. ID tokens, often used in OpenID Connect, carry information about the authenticated user.
The standard OAuth 2.0 flow starts with an authorization request. The client sends the user to an authorization server. The user confirms consent. The server issues an authorization code. The client exchanges the code for an access token, and sometimes a refresh token. From then on, every API request carries the access token in the authorization header. The server checks it, validates its signature, parses its claims, and approves or rejects the request.
Security lives in the details. Access tokens must have strict expiration times. Refresh tokens should be stored securely and rotated to reduce risk. Scopes must be minimal, granting only what the client needs. Never log tokens. Never send them over unencrypted channels. Validate them at every request. Revocation endpoints are not optional—they are your emergency brake when a token leaks.