Authentication verifies a claim about who or what is making a request. Authorization determines whether that identity may perform a particular action on a particular resource. Session management carries an authenticated relationship across requests without requiring a new sign-in each time.
These functions work together, but they answer different questions. A successful sign-in does not grant unrestricted access. A valid session does not mean every action is permitted. And removing a sign-in cookie from one browser does not necessarily revoke every credential that could still access the account.
Understanding these boundaries helps explain how accounts, websites, APIs, and connected workflows should handle access—and where apparently successful security checks can leave important gaps.
Three different functions
The distinction can be summarized through three questions:
- Authentication: What evidence supports this identity claim?
- Authorization: Is this identity allowed to perform this action on this resource under the present conditions?
- Session management: How is the authenticated relationship maintained, checked, and eventually ended?
Consider a website editor. Signing in establishes an authenticated account context. The application then checks whether that account may edit a particular article or publish it. A session lets the editor continue working without entering credentials for every page change.
Each function can fail independently. An attacker might take over an account through weak authentication, access another person’s records through broken authorization, or reuse a stolen session token without knowing the account’s password.
These are related parts of building secure websites, not interchangeable evidence that a website is secure.
Authentication: verifying an identity claim
Authentication evaluates evidence associated with an identity. That identity may belong to a person, an application, a service account, or a device.
A username or email address usually identifies the account being claimed; it does not prove that the requester controls it. Authentication requires additional evidence, such as a password, a cryptographic response from a passkey, or a credential issued to an application.
Even successful authentication has a scope. It commonly establishes control of an account or credential—not a person’s legal identity, intentions, or right to make every decision available through the software.
Different methods provide different assurance
Authentication methods are not equally resistant to theft, phishing, or misuse. Multi-factor authentication combines different kinds of evidence, such as knowledge of a password and possession of an authenticator. Two passwords do not become two factors merely because the system asks for both.
Phishing-resistant methods, including correctly implemented passkeys and security keys, can reduce risks associated with entering reusable credentials into fraudulent websites. They do not remove the need for authorization checks or secure session handling.
Account recovery and authentication assurance also belong together. A strong sign-in method can be undermined if an attacker can reset it through a weaker recovery process.
Machine identities need boundaries too
An automated publishing tool might authenticate with an API credential rather than an interactive sign-in. That credential should identify a suitably scoped application or account, not automatically inherit a human administrator’s full access.
Credential possession establishes a technical ability to make authenticated requests. It does not independently establish that a particular use has been approved.
Authorization: evaluating a specific action
Authorization applies rules to the requested action and resource. Depending on the application, those rules may consider:
- The account’s role or assigned capabilities.
- Ownership of the requested record.
- Membership in a team, organization, or customer account.
- The resource’s state, such as draft, approved, or archived.
- The requested operation, such as reading, editing, deleting, or publishing.
- Conditions such as recent authentication or time-limited access.
A role provides useful information, but it may not answer the whole question. Someone permitted to edit documents within one organization should not necessarily be able to edit documents belonging to another organization.
Enforce authorization at the trusted boundary
Hiding a button is not an authorization control. Neither is removing an administrative link from a menu. A requester can often send an HTTP request without using the interface that normally creates it.
The server or other trusted enforcement layer must evaluate protected operations, including requests from browsers, APIs, mobile applications, and background jobs. It should not trust a client-supplied account identifier, role, or resource identifier as proof of permission.
For example, changing a document ID in a request should never be enough to open another customer’s document. The application must check access to the requested document itself, not merely confirm that the requester is signed in.
Permission should fit the task
Least privilege means giving people and systems the access their work requires, within an appropriate scope and duration. A tool that creates drafts may need permission to submit content without permission to publish it, delete existing articles, or manage users.
This technical boundary supports a broader distinction: access, capability, permission, authority, and responsibility are different things. Software may permit an action while an editorial or organizational process still requires someone’s approval.
Session continuity: carrying authentication forward
Web requests do not inherently remember a previous sign-in. An application needs a mechanism to associate later requests with the authenticated context established earlier.
Two common approaches are:
- Server-side sessions: The client holds an opaque session identifier, often in a cookie. The server uses it to find session information it maintains.
- Token-based access: The client presents a token that the receiving service validates. The token may contain signed claims, or it may be an opaque value checked against an authorization service.
These categories can overlap. A cookie is a browser storage and transport mechanism; a token is a credential or data object. A cookie can carry a session identifier or a token.
Likewise, a JSON Web Token, or JWT, is a token format—not a complete authentication or session-security design. Its signature can protect integrity when correctly validated, but the signature does not ordinarily hide the token’s contents or prove that its permissions remain current.
A session represents continuity, not continuous proof
After sign-in, possession of a session credential often becomes the evidence accepted for subsequent requests. If that credential is stolen, another party may be able to use it without repeating the original authentication.
This is why session protection matters even when the initial sign-in uses strong multi-factor authentication.
A session also has a context: the application, account, authentication method, issuance time, and other relevant conditions. An identity provider’s session may be separate from a connected application’s session. Signing out of one does not necessarily end the other.
Following a request through the boundaries
Consider an editor signing in to update an article:
- The editor claims an account. The application receives an account identifier or begins an identity-provider sign-in flow.
- Authentication is completed. The system verifies the required evidence.
- Session continuity is established. The application issues or establishes a session credential with defined limits.
- The editor requests an article. The application validates the session and checks whether the account may read that article.
- The editor submits changes. The application checks permission to edit that resource and applies relevant protections to the state-changing request.
- The editor attempts publication. Publishing receives its own authorization decision. Permission to edit does not automatically imply permission to publish.
- The session ends or access changes. Later requests must reflect expiration, revocation, account restrictions, and applicable permission changes.
The same reasoning applies to an automated connector. Authentication identifies the integration; authorization bounds its operations; credential handling governs how access continues. A successful connection test does not establish that every available operation is appropriate.
Protecting sessions and credentials
Cookies and session security require several controls working together. No single cookie attribute or storage choice resolves every threat.
Use encrypted transport and deliberate cookie settings
HTTPS protects requests and responses in transit. For browser session cookies, relevant settings include:
- Secure: Restricts cookie transmission to secure connections.
- HttpOnly: Prevents page scripts from directly reading the cookie through ordinary JavaScript cookie APIs.
- SameSite: Limits when browsers include the cookie in cross-site requests, depending on the selected policy.
- Appropriate scope: Avoids unnecessarily broad cookie domains and other exposure beyond the intended application.
These protections have limits. An HttpOnly cookie does not prevent injected scripts from making requests within the compromised page. SameSite can reduce cross-site request forgery exposure, but it is not a universal replacement for deliberate CSRF protections on state-changing requests.
Keep credentials out of incidental records
Session identifiers, access tokens, and refresh tokens should not appear in ordinary logs, analytics events, screenshots, published examples, or shared troubleshooting files. Putting credentials in URLs can expose them through browser history, infrastructure logs, and other records.
Browser storage choices also involve tradeoffs. Tokens in JavaScript-accessible storage can be exposed by malicious scripts running in the same origin. Cookie-based designs need appropriate protections against unwanted authenticated requests. The choice should follow the application’s architecture and threats, rather than a blanket claim that one storage mechanism is always safe.
Renew session identifiers at security transitions
Applications should renew session identifiers after authentication and relevant privilege changes, invalidating superseded identifiers as appropriate. This helps prevent session fixation, where an attacker tries to make a victim authenticate into a session whose identifier the attacker already knows.
Expiration, logout, and revocation
Session continuity needs an ending as well as a beginning. Different mechanisms serve different purposes:
- Idle timeout: Ends a session after a defined period without qualifying activity.
- Absolute lifetime: Limits total session duration even when activity continues.
- Reauthentication: Requires fresh identity evidence for a sensitive action or changed condition.
- Revocation: Withdraws continued use of a session or credential before its normal expiration.
Appropriate durations depend on the sensitivity of the application and the consequences of access. Shorter sessions can reduce some exposure, but unnecessarily frequent interruptions can obstruct work. Where practical, warn users before expiration and preserve work safely without retaining access that should have ended.
Logout must match the session architecture
Deleting a browser cookie removes that browser’s copy. For a server-managed session, logout should also invalidate the corresponding server-side session. Otherwise, another copy of the credential may remain usable.
Self-contained access tokens require an explicit revocation strategy. Depending on the design, a token may remain valid until expiration unless the receiving service checks revocation or current session state. Revoking a refresh token can stop new access tokens from being issued without immediately invalidating access tokens already issued.
Password changes, account disabling, and role removal also need defined effects on existing sessions. Systems should not assume that updating an account record automatically cancels every token or cached permission.
Make device and session boundaries understandable
“Sign out here” and “sign out everywhere” describe different actions. An application should distinguish them clearly and explain any relevant limits, such as independent API credentials or sessions maintained by another service.
Device labels and network addresses can help someone recognize sessions, but they are imperfect evidence of who is using them. They should support investigation rather than be treated as definitive identity proof.
Checking each boundary separately
A useful review tests authentication, authorization, and session behavior independently. Within an authorized test environment, questions include:
- Does the sign-in process reject invalid, expired, and inappropriate credentials?
- Can one ordinary account access another account’s protected resources by changing a request identifier?
- Are organization boundaries enforced as well as account roles?
- Are editing, publishing, deletion, and administration checked separately?
- Does a removed permission stop working within the intended time?
- Are session identifiers renewed after sign-in?
- Do logout, expiration, and revocation prevent the intended subsequent requests?
- Are credentials excluded from logs and other routine records?
The conclusion should stay within the verification scope. A successful sign-in test establishes something about the tested authentication path. It does not prove correct authorization. A working logout button does not, by itself, prove that a previously issued credential can no longer be used.
Authentication establishes an identity context. Authorization bounds what that context permits. Session management preserves—and eventually ends—the continuity between requests. Keeping these responsibilities distinct makes access easier to explain, implement, test, and maintain.