Authorization-code flow moves access-token delivery to the token endpoint rather than returning an access token in the browser-facing authorization redirect. That distinction reduces exposure in URLs, but does not mean a browser can never hold a token. The client architecture determines who exchanges the code and where the resulting credentials live. ...
A cookie is a browser storage and transport mechanism. A server-side session is one application design that uses a cookie value to locate stored state. Keeping those responsibilities separate makes login, expiry, and logout testable. This article follows an opaque session identifier, rather than repeating the host, path, or SameSite matching rules. ...
Single sign-on lets an application rely on an identity provider’s authentication result. The user does not need to hand that provider password to each application. The application still owns its authorization decisions, local sessions, and integration configuration; confidential clients may also hold client credentials. Delegating authentication does not remove the application’s security boundary or guarantee that every future login can skip user interaction. ...
A reusable bearer access token grants its holder defined access; sender-constrained tokens additionally require proof tied to the sender. 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. ...