Quick overview
Salesforce supports several OAuth 2.0 authorization flows to accommodate different application types and security requirements. Choosing the right flow depends on whether the client is a web app, mobile app, server-side process, or needs delegated access without user interaction.
Common Salesforce OAuth2.0 flows
1. Authorization Code Grant (Web Server Flow)
Best for server-side web applications where the client secret can be kept confidential. The user authorizes the app via a browser redirect, and Salesforce returns an authorization code which the server exchanges for an access token (and refresh token if requested).
Use when: web apps with backend server, long-lived sessions, need refresh tokens.
2. User-Agent Flow (Implicit Grant)
Designed for client-side web or mobile apps where the client secret cannot be stored securely. The access token is returned directly in the URL fragment after user authorization. No refresh token is issued.
Use when: single-page apps or mobile apps that can't secure client secrets, short-lived tokens acceptable.
3. JWT Bearer Token Flow
Server-to-server integration without interactive user login. The client (connected app) uses a signed JWT assertion (signed with a certificate private key) to request an access token on behalf of a user. Common for integrations where admins pre-authorize the app.
Use when: backend integrations, automated processes, no user interaction, high security.
4. Username-Password Flow (Resource Owner Password Credentials Grant)
The app collects a user’s credentials (username/password) and exchanges them directly for an access token. This flow is discouraged because it requires storing or handling user credentials and often triggers security policies. It may be used in legacy/controlled environments.
Use when: legacy systems, trusted environments, where other flows are not feasible (not recommended).
5. SAML Bearer Assertion Flow
For single sign-on scenarios using SAML assertions. An identity provider issues a SAML assertion that Salesforce exchanges for an access token. Useful when integrating with corporate SSO solutions.
Use when: enterprise SSO with SAML, identity provider-driven authentication.
6. Device Flow (Device Authorization Grant)
For devices without an easy input mechanism (e.g., TVs, IoT). The device requests a code, user completes authorization on a separate device/URL, and the device polls Salesforce for the token.
Use when: limited-input devices, user authorizes on a second device.
Key considerations
- Connected App: Configure OAuth scopes, callback URL, and policies in Salesforce.
- Scopes: Limit scopes to least privilege (api, full, refresh_token, offline_access, web, openid).
- Security: Prefer flows that avoid handling user credentials directly and use refresh tokens or JWT for server-to-server.
- Policies: IP restrictions, session timeouts, and connected app policies may affect which flows work.
Example: Authorization Code Flow sequence
1. Redirect user to Salesforce authorization endpoint with client_id, redirect_uri, response_type=code, and scopes.
2. User authenticates and grants access.
3. Salesforce redirects to redirect_uri with code.
4. Server exchanges code for access_token (and refresh_token) at token endpoint using client_secret.
5. Use access_token to call Salesforce APIs.
Conclusion
Salesforce supports multiple OAuth2.0 flows—choose Authorization Code for server-side apps, User-Agent for pure client apps, JWT or SAML for server-to-server or SSO, Username-Password only as last resort, and Device Flow for constrained devices. Properly configure connected apps and scopes for secure integrations.