Identity & SSO: SAML, OAuth, and Access Management

Identity management answers a core question: who is this user and what can they do? In enterprise ecosystems, CTA scenarios require end-to-end identity solutions spanning Salesforce, external systems, portals, and mobile apps, with the right protocols, flows, and configurations for each.

Identity Architecture Overview

Figure 1. Identity architecture separates three distinct roles: who authenticates (IdP), who trusts that authentication (SP), and who grants API access (authorization server). Each role maps to a different protocol and Salesforce configuration object.

SAML 2.0 Deep Dive

SAML (Security Assertion Markup Language) is the standard for web-based single sign-on. In enterprise Salesforce deployments, SAML is almost always part of the architecture.

SAML Roles

Role	Who Plays It	What It Does
Identity Provider (IdP)	Corporate IdP (Okta, Azure AD, ADFS, Ping)	Authenticates the user, issues SAML assertions
Service Provider (SP)	Salesforce	Trusts the IdP’s assertion, grants access
Principal	The user	Requests access, gets redirected

SAML SSO Flow

Figure 2. SP-initiated SAML SSO begins at Salesforce, which sends an AuthnRequest to the IdP. The browser acts as intermediary, carrying the signed SAML assertion back to Salesforce, which validates the signature before granting access.

SAML Configuration Decisions

Decision	Options	Recommendation
SP-initiated vs IdP-initiated	SP-initiated (user goes to SF first) or IdP-initiated (user starts at IdP portal)	Support both. SP-initiated for bookmarks, IdP-initiated for portal.
User matching	Federation ID, Username, or Custom attribute	Federation ID. Decouples from Salesforce username changes.
JIT provisioning	Standard JIT or Custom JIT (Apex handler)	Custom JIT when you need to set profile/role/permission sets dynamically
Single Logout	Enabled or disabled	Enable. Prevents orphaned sessions across systems.
Certificate	IdP cert in Salesforce, SF cert for signed requests	Always validate IdP certificate; sign AuthnRequests for sensitive orgs

Salesforce as Identity Provider

Salesforce can also act as the IdP, authenticating users for other SPs.

Scenario	Use Case
SF as IdP to custom apps	Internal tools that need SF user authentication
SF as IdP to partner portals	Partners authenticate via Salesforce credentials
SF as IdP in multi-org	One SF org authenticates users for other SF orgs
SF as IdP with Connected Apps	External apps use SF login for SSO

CTA Pattern: IdP vs SP Decision

When the scenario has an existing corporate IdP (Okta, Azure AD, ADFS), Salesforce should be the SP. When Salesforce is the system of record for users (common in customer-facing portals), Salesforce can be the IdP. In multi-org scenarios, designate one org as the IdP.

OAuth 2.0 Flows

OAuth 2.0 is the authorization framework for API access. Each flow is designed for a specific use case. Choosing the wrong flow creates security vulnerabilities.

OAuth Flow Selection

Figure 3. OAuth flow selection hinges on two questions: is a human user involved, and what credentials does the client have? Using the wrong flow, such as Client Credentials for a user-facing app, creates both security and functionality problems.

Detailed walkthrough

The tree splits at two core questions. Getting either wrong leads to a flow that fails technically or creates a security hole.

The first question is whether a human user is involved. Human-user flows must redirect to Salesforce’s login page and obtain consent. Server-to-server flows must never open a browser; they authenticate programmatically using a pre-configured credential.

On the human-user side, the second question is whether the client has a secure backend that can hold a secret. A web application with a server-side component (Node.js, Java, .NET) can store the client secret safely, so use Authorization Code. The server exchanges the short-lived code for tokens without ever sending the secret to the browser.

If the client cannot store a secret (mobile app or single-page application) use Authorization Code with PKCE. The Field Service Mobile app is the board’s go-to example. PKCE replaces the client secret with a one-time cryptographic verifier generated fresh per request. The classic failure mode is using plain Authorization Code for a mobile or SPA client: the client secret ends up in the app binary or JavaScript bundle where it can be extracted.

For devices with no browser input capability (IoT sensors, CLI tools, kiosks) the tree routes to Device Flow. The device displays a short code, the user approves on any browser, and the device polls for the token.

The dashed SAML Bearer arrow is a bridge, not a primary flow. When SAML SSO already exists and the app needs an OAuth token, an existing SAML assertion from the corporate IdP can be exchanged directly for a Salesforce access token without re-authenticating.

On the server-to-server side, if the server has a certificate and private key, use JWT Bearer. The server signs a JWT assertion and Salesforce validates the signature against the uploaded public certificate. No client secret is ever transmitted and the private key never leaves the integration server.

If there is no certificate, the tree routes to Client Credentials. The second classic failure is using Client Credentials for an integration that needs user-level data access. Client Credentials runs as the Connected App’s designated execution user, so CRUD, FLS, and sharing all apply to that service account’s profile, not to any human user. If the scenario requires per-user sharing rules or running as different users at different times, Client Credentials is wrong. JWT Bearer with a sub claim pointing to the appropriate user is correct instead.

Flow 1: Authorization Code

The standard web server flow for applications with a backend.

Figure 4. The Authorization Code flow keeps the client secret on the server and never exposes it to the browser. The short-lived authorization code is exchanged for tokens in a server-to-server call, making this the correct choice for web apps with a secure backend.

When to use: Web applications with a secure backend server that can store the client secret.

Security note: The client secret must never be exposed to the browser. Always use HTTPS for redirect URIs.

Flow 2: Authorization Code with PKCE

Enhanced authorization code flow for public clients (mobile apps, SPAs) that cannot securely store a client secret.

Figure 5. PKCE replaces the client secret with a one-time cryptographic proof: the app generates a random verifier, sends its hash in the authorization request, then proves knowledge of the verifier at token exchange. This prevents code interception attacks on public clients.

When to use: Mobile apps, single-page applications, desktop apps, or any client that cannot securely store secrets.

Flow 3: JWT Bearer

Server-to-server authentication using a signed JWT. No user interaction required.

Figure 6. JWT Bearer flow requires no user interaction and no client secret. The integration server signs a JWT with its private key; Salesforce validates the signature against the uploaded public certificate. This is the preferred flow for middleware and scheduled server-to-server integrations.

When to use: Backend integrations, middleware (MuleSoft, Dell Boomi), scheduled jobs that run as a specific user.

Key details:

• Requires pre-authorized Connected App with uploaded certificate
• The sub claim specifies which Salesforce user to impersonate
• No refresh token is issued; generate a new JWT when the access token expires
• The Connected App must have “Use digital signatures” enabled

Flow 4: Client Credentials

Server-to-server flow where the integration authenticates as itself, not as a specific user.

Figure 7. Client Credentials flow authenticates the application itself, not a user. All API operations run as the Connected App’s execution user, so CRUD, FLS, and sharing permissions apply to that user’s profile and permission sets.

When to use: Service-to-service integrations where no specific user context is needed. The integration runs as the Connected App’s execution user.

Client Credentials Limitations

• GA in Spring ‘23 (API v57.0)
• Runs as the Connected App’s execution user; all CRUD/FLS applies to that user
• No refresh token issued
• Must be explicitly enabled on the Connected App

Flow 5: SAML Bearer

Exchanges a SAML assertion for an OAuth access token. Bridges SAML-based SSO with API access.

Figure 8. SAML Bearer bridges existing SAML infrastructure to OAuth API access. When an enterprise already has SAML SSO in place, this flow avoids re-authenticating the user just to get an API token. The existing SAML assertion serves as the credential.

When to use: When SAML infrastructure already exists and API access is needed without re-authenticating the user. Common in enterprise middleware scenarios.

Flow 6: Device Flow

For devices with limited input capabilities (IoT devices, CLI tools, smart TVs).

Figure 9. Device flow decouples authentication from the constrained device. The device displays a short code; the user approves on any browser-capable device. The original device polls until the token is issued, making this the correct pattern for IoT, CLI tools, and kiosks.

When to use: IoT devices, CLIs, TVs, kiosks, or any device where typing credentials is impractical.

OAuth Flow Comparison

Flow	User Interaction	Client Secret	Refresh Token	Best For
Authorization Code	Yes	Yes (server-side)	Yes	Web apps with backend
Auth Code + PKCE	Yes	No	Yes	Mobile, SPA
JWT Bearer	No	No (uses cert)	No	Server-to-server
Client Credentials	No	Yes	No	Service accounts
SAML Bearer	No (uses existing SAML)	Yes	No	SAML-to-OAuth bridge
Device	Yes (separate device)	No	Yes	IoT, CLI

OpenID Connect (OIDC)

OpenID Connect adds an authentication layer on top of OAuth 2.0, providing an ID token (JWT) with user identity information. Use SAML 2.0 for enterprise web SSO with existing IdPs, OAuth 2.0 for API-only authorization, and OIDC for modern web/mobile apps needing both login and API access.

CTA Decision Framework

• Enterprise web SSO with existing IdP: SAML 2.0
• API access for integrations: OAuth 2.0 (JWT Bearer or Client Credentials)
• Modern web/mobile app needing both login and API: OpenID Connect
• Legacy system integration: SAML Bearer to bridge to OAuth

Multi-IdP and Hub-and-Spoke SSO Patterns

Enterprise scenarios often involve multiple identity providers. Different business units, acquired companies, or partner organizations may each have their own IdP. The CTA board expects familiarity with these patterns.

Multi-IdP Routing Architecture

Figure 10. Login Discovery enables a single Salesforce org to support multiple identity providers simultaneously. Users are silently routed to the correct IdP based on their email domain, with direct login as a fallback for accounts without SSO. This is a common post-M&A architecture pattern.

Hub-and-Spoke SSO (Identity Broker)

When an organization has many SPs and IdPs, an identity broker centralizes authentication routing and protocol translation.

Figure 11. An identity broker centralizes protocol translation: multiple identity sources speak different protocols (LDAP, OIDC, SAML) but the broker normalizes all of them into standard assertions. This is the recommended pattern when an org has multiple IdPs from M&A or partner relationships.

CTA Pattern: When to Recommend an Identity Broker

Recommend a centralized identity broker when: (1) multiple IdPs exist across business units or partner organizations, (2) different IdPs use different protocols (LDAP, Kerberos, SAML, OIDC), (3) centralized MFA enforcement is required, or (4) the organization is consolidating after M&A activity. The broker translates all protocols into a single standard (usually SAML 2.0) that Salesforce consumes.

Token Lifecycle

Understanding the OAuth token lifecycle is necessary for diagnosing integration issues and designing secure token policies.

Figure 12. The token lifecycle shows why refresh token policies matter: a compromised refresh token grants persistent API access until revoked. Enabling refresh token rotation (Spring ‘24+) limits the exposure window by invalidating the old token each time a new access token is issued.

Token Policy Configuration

Policy	Options	Security Impact
Refresh token expiry	Never / After X time / If unused for X time	Shorter = more secure, more re-auth friction
Refresh token rotation	Enabled (Spring ‘24+) / Disabled	Rotation invalidates old tokens, limiting the window of compromise
Session timeout	15 min to 24 hours	Controls access token effective lifetime
Token revocation	Per user / Per Connected App / All tokens	Emergency response to compromised credentials

Connected Apps

Connected Apps are the configuration object in Salesforce that controls OAuth and SAML integration points.

Connected App Settings That Matter

Setting	Impact	When to Change Default
Permitted Users	All users / Admin approved	Set to Admin approved for sensitive integrations
IP Relaxation	Enforce IP restrictions or relax	Relax for mobile apps that roam networks
Refresh Token Policy	Expiration, rotation	Set expiration for security; rotate for compromised tokens
Scopes	API, refresh_token, full, web, etc.	Grant minimum required scopes
Callback URL	Where tokens are sent	Must match exactly; use HTTPS
Digital Signatures	Certificate for JWT Bearer	Required for JWT Bearer flow
Run As	Execution user for Client Credentials	Set to an integration user with minimum access

My Domain

My Domain is required for SSO, Lightning components, and API access. It provides a unique, branded login URL.

My Domain Impact on Identity

• Required before configuring SAML SSO
• Required for Lightning Web Components
• Controls login page behavior (login form, SSO buttons, social sign-on)
• Can redirect automatically to IdP (skip Salesforce login page)
• Custom login flows via Login Discovery

My Domain and Existing Integrations

Deploying or changing My Domain breaks existing integrations that use the generic login.salesforce.com or instance.salesforce.com URLs. All OAuth callback URLs, SAML endpoints, and API base URLs must be updated. Plan this change carefully in large enterprises.

User Lifecycle & Provisioning (JIT & SCIM)

Once a user is authenticated via SSO, they must be provisioned (created or updated) in Salesforce with the correct attributes, profile, role, and permissions.

JIT (Just-in-Time) Provisioning

JIT provisioning automatically creates or updates Salesforce user accounts during the SSO login flow.

Feature	Standard JIT	Custom JIT (Apex SSOJitHandler)
User creation	Yes, based on SAML attributes	Yes, with custom logic
User updates	Yes, on every login	Yes, with custom logic
Profile assignment	Static (one profile per SSO config)	Dynamic (based on SAML attributes or external data)
Permission sets	Not supported	Yes, assign dynamically
Role assignment	Static	Dynamic
Federation ID mapping	Automatic	Custom logic
Error handling	Limited	Full Apex exception handling

When to Use Custom JIT

Use custom JIT (Apex SSOJitHandler) when you need to: assign profiles dynamically based on department, assign permission sets based on role, populate custom fields, or handle complex user matching logic.

SCIM (System for Cross-domain Identity Management)

While JIT happens only at login, SCIM provides a continuous, automated sync of user lifecycle events (create, update, deactivate) between the IdP and Salesforce. Salesforce implements SCIM 2.0 as a Service Provider, exposing /Users and /Groups REST endpoints that IdPs (Okta, Azure AD, Ping) consume.

• Trigger: Happens at the IdP (e.g., Azure AD, Okta) when a user’s status changes. No user login required.
• Deactivation: SCIM can deactivate a user in Salesforce immediately when they are terminated at the IdP, without waiting for a login attempt.
• Group Mapping: The /Groups endpoint maps to Salesforce Public Groups and Queues. Permission Set assignment is managed through user attributes on the /Users endpoint, not through /Groups.
• Profile & Role: SCIM can set Profile and Role via user attributes, enabling centralized lifecycle governance from the IdP.

Aspect	JIT Provisioning	SCIM Provisioning
Protocol	SAML / OIDC	REST (SCIM 2.0)
Timing	Only at login	Real-time or scheduled sync
Deactivation	Cannot deactivate (user must attempt login)	Can deactivate immediately
User Update	Only when user logs in	Syncs even if user never logs in
Group/Queue Management	Not supported	Yes (via /Groups endpoint)
Complexity	Low	Medium (requires IdP SCIM connector configuration)

SCIM for CTA

Recommend SCIM when the scenario requires immediate deprovisioning on termination (compliance-critical), centralized group/queue membership management, or managing large user populations (>5,000) where login-triggered JIT updates are insufficient. SCIM and JIT are complementary: SCIM for lifecycle management, JIT for session-time attribute refresh.

Multi-Factor Authentication (MFA)

MFA is required for all Salesforce direct logins. Understanding MFA architecture matters for CTA scenarios.

MFA Options

Method	Type	Best For
Salesforce Authenticator	Push notification + location	Most internal users
TOTP Authenticator apps	Time-based codes (Google Auth, Authy)	Broad compatibility
Security Keys (U2F/WebAuthn)	Physical hardware keys	High-security environments
Built-in Authenticators	Biometrics (Touch ID, Face ID, Windows Hello)	Convenience + security

MFA in SSO Scenarios

When SSO is configured, MFA responsibility depends on the architecture:

Scenario	Who Handles MFA	Configuration
Corporate IdP with MFA	IdP handles MFA before SAML assertion	No MFA config needed in Salesforce
Salesforce as IdP	Salesforce handles MFA	Configure MFA in Salesforce
SSO without IdP MFA	Must add MFA at Salesforce or IdP level	Configure either side; IdP preferred
Direct login fallback	Salesforce handles MFA	Always required for direct logins

Single Logout (SLO)

Single Logout ensures that logging out of one system terminates sessions across all connected systems. Configure SLO for security-sensitive environments. IdP-initiated SLO (logout at IdP terminates all SP sessions) is most common. SP-initiated SLO (logout at Salesforce notifies IdP) is also supported but not all downstream systems honor it.

Named Credentials

Named Credentials store callout authentication details, keeping secrets out of code. See Programmatic Security for detailed Named Credential architecture and usage patterns.

Social Sign-On

Social Sign-On (Google, Facebook, LinkedIn, Apple) works best for customer portals where it reduces friction for consumer users. For partner portals, LinkedIn provides professional identity verification. For internal Salesforce, always prefer corporate SSO over social sign-on.

Related Topics

• Sharing Model: identity determines who the user is; sharing determines what they see
• Portal Security: external user identity and authentication patterns
• Field & Object Security: permissions assigned after authentication
• Decision Guides: identity architecture and OAuth flow decision trees
• Programmatic Security: Named Credentials and secure callouts
• Integration: OAuth flows for API-based integrations

Sources

• Salesforce Help: SAML Single Sign-On
• Salesforce Help: OAuth 2.0 Authentication Flows
• Salesforce Help: Connected Apps
• Salesforce Help: My Domain
• Salesforce Help: MFA
• Salesforce Help: OAuth Refresh Token Flow
• Salesforce Help: Refresh Token Rotation (Spring ‘24)
• Salesforce Help: Manage OAuth Access Policies
• Salesforce Architects: Identity Architecture
• Cloud Sundial: Salesforce SSO Flows
• Cloud Sundial: Salesforce Identity Flows
• RFC 6749: OAuth 2.0 Authorization Framework
• RFC 7523: JWT Bearer Token
• OpenID Foundation: OpenID Connect Core