Authentication

Keeping the token on the server and giving the browser only a short-lived code shrinks the surface for token theft in the URL or the log. The browser gets a code, not a token The browser is deliberately the wrong place for the access token. In the authorization-code flow the browser goes to the authorization server, sees the consent screen, and comes back at the redirect URI carrying only a short authorization code, never the token. The token stays off the browser’s URL history and out of its logs, because it is the backend that presents the code together with the client secret to the token endpoint. That split of labour — the browser carries the code, the server owns the secret — is the entire point of the flow. ...

The browser holds a cookie and the server holds the state the cookie stands for. Confusing the two — or letting the cookie carry more meaning than it should — is where authentication bugs start. The cookie is an identifier, not the authority A session cookie is usually a high-entropy random value the server mints, stores server-side, and later looks up to find the matching session. It exists only as a pointer: the cookie identifies a session; the session holds the authority. That split matters because the browser sees and can re-send the cookie verbatim on every request, so putting meaningful data inside it — a user id, a role, an email — means giving the client every value it would need to forge or tamper with state. Keep the cookie opaque: a long random string with no structure the client is meant to read, and let the server resolve it to the actual privileges. ...

Single sign-on is a relay, not a password handover. The user proves their identity to an identity provider once, and that provider hands each app a signed assertion or token. The app never stores a password; it stores the provider’s public key, the issuer it expects, and the audience it answers to. ...

A reusable access token grants whoever possesses it some defined access. Putting it in a URL exposes that capability to systems that routinely copy URLs: access logs, monitoring records, browser navigation history, bookmarks, and shared links. The exact exposure depends on the request and policy, but a secret-looking query parameter is not automatically protected by its name. Treat transport placement as part of the credential’s disclosure boundary. ...