Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionarySSession ID
AdministrationIntermediate

Session ID

A Session ID in Salesforce is the unique authentication token issued to a user after they sign in.

§ 01

Definition

A Session ID in Salesforce is the unique authentication token issued to a user after they sign in. The token represents an active session and is sent on every subsequent API call to prove identity. The Session ID is the user's bearer credential: anyone holding it can act as that user until the session expires or is revoked.

Salesforce issues a Session ID through every login channel: the standard username and password login, SAML or OpenID Connect single sign-on, OAuth 2.0 web server and client credentials flows, and the Apex UserInfo.getSessionId() method inside an active interactive context. The token expires based on the session settings configured at the org or profile level; the default is 2 hours of inactivity and 12 hours absolute. Refresh tokens (issued in OAuth flows) let an application request a new Session ID without re-authenticating the user.

§ 02

How Session IDs authenticate Salesforce API and UI calls

How Salesforce issues a Session ID

A Session ID is the result of a successful authentication. Every login channel produces one: the standard interactive login at login.salesforce.com, the SAML or OpenID Connect single sign-on flow that hands a token to Salesforce from an identity provider, the OAuth 2.0 web server flow that exchanges an authorisation code for a token, the OAuth 2.0 client credentials flow used by server-to-server integrations, and the Apex UserInfo.getSessionId() method inside an active interactive context. Each channel produces a token with the same purpose: to identify the user on subsequent API calls and UI page loads.

Session expiration and timeout settings

A Session ID expires based on two timers. The inactivity timeout starts when the user stops interacting and resets on each API call or page interaction; the default is 2 hours and the admin can set it as low as 15 minutes. The absolute timeout starts when the session is issued and runs to a hard ceiling regardless of activity; the default is 12 hours and can be configured up to 24. Either timer expiring kills the session and invalidates the Session ID. Admins configure both timers under Setup, Security, Session Settings. Profile-level overrides can apply tighter timeouts to specific user populations.

What the Session ID looks like and how to use it

A Session ID is an opaque string, usually around 100 characters long, starting with a code that identifies the org and the session type. Applications send it in the Authorization header of REST calls (Authorization: Bearer followed by the session ID) or in the sessionId field of SOAP envelope headers. The token is opaque from the application's perspective: there is no decoding or signature verification, the application simply passes it back to Salesforce on each call. Salesforce validates the token internally on every call and rejects expired or revoked tokens with a 401 Unauthorized response.

Apex UserInfo.getSessionId() and async context behaviour

Apex code running inside an interactive context (a controller method called from the Lightning UI, a synchronous trigger handler firing on a user-initiated DML) can retrieve the current session ID with UserInfo.getSessionId(). The same method returns null when called from any asynchronous Apex context: batch jobs, future methods, queueable jobs, scheduled Apex, platform event triggers. The reason is that async contexts run under a system context, not a user session, so there is no Session ID to return. Code that needs a Session ID in async paths must use named credentials or external credentials instead.

Session ID and OAuth refresh tokens

OAuth 2.0 flows in Salesforce issue a Session ID (sometimes called an access token in OAuth parlance) and optionally a refresh token. The access token is short-lived; the refresh token is long-lived and can be used to request a new access token without forcing the user to log in again. The refresh token is the basis of long-running integrations: an integration logs in once with a user, stores the refresh token, and uses it to mint new access tokens for years until the user revokes the connected app. The refresh token itself can also be revoked from Setup, Connected Apps OAuth Usage, which terminates every active Session ID issued under that connected app.

Security implications and IP restriction settings

A Session ID is a bearer credential, which means anyone holding it can act as the user. Leaking a Session ID is the equivalent of leaking a username and password until the session expires. Salesforce mitigates this with IP-range restrictions: a Session ID issued to a user logging in from one IP range can be tied to that range, so an attacker who captures the token cannot use it from another network. The restrictions are configured at the profile (Login IP Ranges) and at the org level (Setup, Security, Network Access). Mobile and remote-worker policies often loosen these restrictions; tight Login IP Ranges narrow the attack surface significantly.

How to invalidate a Session ID before it expires

There are three ways to invalidate an active Session ID. The user can log out manually, which kills only the session in that browser tab. An admin can use the User Session Information page (Setup, Security, Session Management) to see active sessions and end any of them, which kills only the chosen session. To invalidate every active session for a user, the admin can reset the user's password or use the End All Sessions option on the user record. For connected app sessions, revoking the OAuth refresh token in Setup invalidates every access token issued under that grant.

§ 03

Configure session settings and inspect active Session IDs

Session ID behaviour is governed by Session Settings in Setup, plus profile-level overrides for specific user populations. The steps below cover the most common configuration tasks and the inspection of active sessions for troubleshooting.

  1. Open Session Settings in Setup

    Go to Setup, Security, Session Settings. The page covers org-wide session policies: inactivity timeout, absolute timeout, force re-login on browser close, IP locking, and high-assurance session policies for sensitive operations.

  2. Set the inactivity and absolute timeouts

    Configure the Timeout Value to the inactivity timeout you want (15 minutes to 24 hours). Configure the Maximum Session Length to the absolute timeout (1 hour to 24 hours). Tighter values reduce the window an attacker has if a token is leaked.

  3. Tighten profile-level overrides where needed

    For profiles that need stricter timeouts (admin profiles, finance team), open the profile, edit Session Settings, and pick a tighter Session Timeout from the picklist. Profile settings override org settings for that profile's users.

  4. Configure IP ranges on the profile or org

    On the profile, set Login IP Ranges for the allowed IP space. On the org, configure Setup, Security, Network Access for IP ranges that bypass the verification challenge. Network Access ranges loosen the policy; profile IP ranges tighten it.

  5. Inspect active sessions and end them when needed

    Open Setup, Security, Session Management to see the list of active sessions across the org. Filter by user or source IP. Use the End Session action on any row to invalidate that Session ID immediately. Reset the user's password to force re-login on every session for that user.

Key options
Timeout Valueremember

Inactivity timeout in minutes. The session expires after this much idle time. Range: 15 minutes to 24 hours.

Lock sessions to the originating IPremember

Org-wide setting that binds a Session ID to the original IP address. Leaked tokens cannot be used from other IPs.

Require MFA for high-assurance sessionsremember

Forces re-authentication when a user attempts a high-assurance operation like Setup access or password change. Raises the bar for compromised sessions.

Gotchas
  • UserInfo.getSessionId() returns null in any asynchronous Apex context: batch, future, queueable, scheduled, platform event triggers. Code that needs a Salesforce HTTP callout from async should use a Named Credential pointing to the org with the right OAuth configuration.
  • Session ID is a bearer credential. Leaking it is the equivalent of leaking a password until the session expires. Never log Session IDs to debug output or third-party log aggregators.
  • Tightening session timeouts is retroactive on the next session creation, not on currently active sessions. To force every user to a new policy immediately, run End All Sessions on the affected profiles.
§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Session ID.

Keep learning

Hands-on resources to go deeper on Session ID.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.

§

Test your knowledge

Q1. What is a Session ID?

Q2. When does it expire?

Q3. What's the modern equivalent?

§

Discussion

Loading…

Loading discussion…