DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • 5 Best Practices for Secure Payment Processing in Applications
  • Introduction To Face Authentication With FACEIO in AngularJS
  • What D'Hack Is DPoP?
  • MuleSoft OAuth 2.0 Provider: Password Grant Type

Trending

  • Comprehensive Guide to Property-Based Testing in Go: Principles and Implementation
  • AI's Dilemma: When to Retrain and When to Unlearn?
  • Unlocking Data with Language: Real-World Applications of Text-to-SQL Interfaces
  • How the Go Runtime Preempts Goroutines for Efficient Concurrency
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. Explore Salesforce OAuth Authorization Flows and Its Use Cases

Explore Salesforce OAuth Authorization Flows and Its Use Cases

Depending on your use case, you can decide which flow to use for a client app to get an access token to access data in Salesforce.

By 
Jaseem Pookandy user avatar
Jaseem Pookandy
DZone Core CORE ·
Feb. 27, 24 · Tutorial
Likes (1)
Comment
Save
Tweet
Share
3.1K Views

Join the DZone community and get the full member experience.

Join For Free

Have you authorized an application to access Salesforce without giving your credentials to that application? Then, you must have used a Salesforce OAuth authorization flow. OAuth is a standard for authorization. Salesforce uses several OAuth flows, and all these flows have the following three steps in general. 

  1. The client app requests access to a protected resource in Salesforce
  2. The Salesforce authorizing server, in response to the request, sends the access token back to the client app
  3. The resource server (Salesforce) validates the access token and approves access to the protected resource

It is also important to understand the difference between authentication and authorization. Authentication is about verifying WHO you are, whereas authorization is about verifying WHAT you can do. A username and password are the most common type of authentication. Profiles or permission sets are associated with authorization. 

OAuth Roles

All OAuth flows have the following roles in action. 

  1. Resource owner: The resource owner is the user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g., read or write access).
  2. Resource server: Server or application hosting protected data or functionality. 
  3. Authorization server: Server or application that issues access tokens and grants. 
  4. Client: Application requesting access to protected resources on behalf of the resource owner. 

OAuth Components

Following are the key components of an OAuth flow. 

  1. Consumer key: The key used by the consumer to identify itself to the resource server. 
  2. Access token: An access token represents a user’s permission for the client to access their data. It is used to get access to the resources. 
  3. Refresh token: Refresh token is used to request a new access token when an access token has expired. 
  4. Authorization code: An authorization code is a short-lived code that represents the access granted by the end user. This code is used to obtain access tokens and refresh tokens. 
  5. Scope: Scope defines the level of access. Some examples of scope are API, full, refresh token, etc. 

Almost all OAuth flows need a connected app set up in Salesforce. 

Connected App

The connected app defines the entry point when an external application is integrated with Salesforce. It controls how the application interacts with Salesforce, ensuring secure authorization, authentication, and single sign-on (SSO) capabilities. When you create a connected app in Salesforce to integrate an external application with your Salesforce API, you can configure the connected app using OAuth authorization settings. The connected app also allows Salesforce admins to manage access to it by defining the profiles and permission sets associated with the connected app. Salesforce admins can also audit the connected app usage. 

OAuth Flows

Let us look into different OAuth flows. 

Scenario 1

The client application cannot be trusted because it cannot protect the client secret issued by Salesforce's connected app. 

In this case, you can go for OAuth 2.0 User-Agent Flow. This flow is used for mobile or desktop app integration with Salesforce. Dataloader is a common example. 

Since the source code of these applications can be easily accessed by the user and client secrets can be exposed, user-agent flow is appropriate. In this flow, a user has to manually authenticate to Salesforce using their credentials and approve the partner app. After approval, an access token and refresh token are generated in this flow. 

client

Note that we don't use client secrets in this flow. 

Scenario 2

The client app is capable of protecting consumer secrets and can be trusted. 

In this case, you can use the OAuth2.0 Web-Server Authentication Flow. In this flow, we use client secret as an extra authorization parameter. Make sure that your client app can protect the client's secret while using this flow and that the user cannot manipulate the source code. In this flow, the user also has to manually log into Salesforce and approve the access. So, this flow is not recommended for server-server integration. A refresh token is generated in this flow as well. 

Scenario 2

Scenario 3

The client app is an API-only application and wants to connect to Salesforce. 

You don't have a UI for the user to approve the access for the app. In this case, you can go for OAuth2.0 JWT Bearer Token Flow. This flow requires you to upload a certificate to the connected app that will be used to validate the token. You will also need to create a JWT token, which is a JSON file that has the digital signature details. The private key of the certificate uploaded to the connected app is used to sign the JWT token. This flow also requires prior approval of the client app. Prior approval can happen in one of the two ways. 

  • Set your connected app policy to Admin approved users are pre-authorized, and use profiles and permission sets.
  • Set your connected app policy to All users may self-authorize. You can use end-user approval and issuance of a refresh token. 

To request an access token, the client app posts a request to the token endpoint, which includes a JWT. Salesforce validates the JWT using the previously configured certificate. As long as JWT is valid and the client app has prior approval, Salesforce issues an access token. 

Details on how to generate a JWT token can be found here. 

JWT token

If you have SSO enabled for your organization via an active directory or similar central access control system, you could use the SAML assertion from your SSO flow to generate an access token from Salesforce. This flow is called OAuth 2.0 SAML Bearer Assertion Flow. 

Similar to the JWT flow, we use a certificate to sign the SAML assertion. This certificate is uploaded to the connected app. In your post-call to the token endpoint

Scenario 4

The access token used by the client app is expired, and you don't want a user log in and approve the app every time.

You can use OAuth2.0 Refresh Token Flow to generate an access token without a user manually approving client app access. In this flow, you will send a refresh token to the token endpoint. But where do you get the refresh token? The refresh token is generated the first time when you use user-agent or web server flow. The client app can save this refresh token and can be used in this flow to regenerate the access token when the current token expires. 

Scenario 5

Client app runs on a device with limited input or display capability 

A device with limited input capability, such as a smart TV, wants to connect to Salesforce. In this case, you can use OAuth2.0 Device Authentication Flow. Users can connect these apps to Salesforce by accessing a browser on a device with advanced input capability, such as a mobile device. Users authenticate and authorize, while the app continuously polls the Salesforce token endpoint. Polling checks whether the user has authorized and Salesforce has issued an access token. 

scenario 5

Conclusion

There are various OAuth authorization flows you can use when you integrate external client applications into Salesforce. If your use case doesn't have issues in getting a user to manually authorize the client app, you can go for web server or user-agent flow. Both these flows issue a refresh token, which can be used to regenerate the access token upon expiration. If you have a server-server integration, you can go for JWT or SAML flow. If you are working with devices with limited input capabilities, you can go for device authentication flow, which involves users inputting user code in their desired browsers in a verification URL. There are a lot of other advanced flows available in Salesforce.

applications authentication Flow (web browser) security

Opinions expressed by DZone contributors are their own.

Related

  • 5 Best Practices for Secure Payment Processing in Applications
  • Introduction To Face Authentication With FACEIO in AngularJS
  • What D'Hack Is DPoP?
  • MuleSoft OAuth 2.0 Provider: Password Grant Type

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!