Skip to main content

Explore Security and Authentication

Learning Objectives

After completing this unit, you'll be able to:

  • Identify security and authentication methods used in Salesforce apps.
  • Describe the use of external client apps for integrating mobile apps with the Salesforce server.
  • Explain basic OAuth terminology.
  • Outline the flow of events in OAuth authentication and PIN security.

Secure and Authenticate Your Mobile App with OAuth 2.0

Secure authentication is essential for enterprise applications running on mobile devices. OAuth 2.0, the industry-standard protocol, enables secure authorization for access to a customer’s data, without handing out the username and password. It’s often described as the valet key of software access. A valet key restricts access to certain features of your car. For example, a parking attendant can’t open the trunk or glove compartment using a valet key.

Mobile app developers can quickly and easily embed the Salesforce OAuth 2.0 implementation. The implementation uses an HTML view to collect the username and password, which are then sent to the server. The server returns a session token and a persistent refresh token that are stored on the device for future interactions.

A Salesforce external client app is the primary means by which a mobile app connects to Salesforce. An external client app gives both the developer and the administrator control over how the app connects and who has access. For example, an external client app can restrict access to a set of customers, set or relax an IP range, and so on.

Get Familiar with OAuth Terminology

If you’re feeling lost, this list can help you find your way. These labels, considered together, lead directly to OAuth success.

Note

Note
The term “consumer” in this list always refers to a Mobile SDK app.

Consumer Key

A value used by the consumer—in this case, the Mobile SDK app—to identify itself to Salesforce. Referred to as client_id.

Access Token

A value used by the consumer to gain access to protected resources on behalf of the user, instead of using the user’s Salesforce credentials. The access token is a session ID and can be used directly.

Refresh Token

A token used by the consumer to obtain a new access token, without having the end user approve the access again.

Authorization Code

A short-lived token that represents the access granted by the end user. The authorization code is used to obtain an access token and a refresh token.

External Client App

An application external to Salesforce that uses the OAuth protocol to verify both the Salesforce user and the external application.

OAuth2 Authentication Flow

The flow of events during OAuth authorization depends on the state of authentication on the device.

First-Time Authorization Flow

  1. The customer opens a Mobile SDK app.
  2. An authentication prompt appears.
  3. The customer enters a username and password.
  4. The app sends the customer’s credentials to Salesforce and receives a session ID as confirmation of successful authentication.
  5. The customer approves the app’s request to grant access to the app.
  6. The app starts.

Ongoing Authorization

  1. The customer opens a mobile app.
  2. If the session ID is active, the app starts immediately. If the session ID is stale, the app uses the refresh token from its initial authorization to get an updated session ID.
  3. The app starts.

App-Lock Security

As an optional security feature, external client apps can be configured to lock after being in the background for a specified amount of time. To unlock the app, the user is prompted with the operating system's biometric or cryptographic, such as a PIN or passcode, challenge.

To use app-lock protection, the developer must select the Screen Lock checkbox when creating the external client app. Mobile app administrators then have the option to customize the timeout duration.

OAuth2 Web Server Flow

For increased security, Salesforce recommends using the web server flow because it includes Proof Key Code Exchange (PKCE). For more information, explore OAuth 2.0 Web Server Flow for Web App Integration.

OAuth2 User-Agent Flow

In the user-agent flow, the external client app, which integrates the client app with the Salesforce API, receives the access token as an HTTP redirection. The external client app requests that the authorization server redirects the user-agent to a web server or to an accessible local resource.

The web server can extract the access token from the response and pass it to the external client app. For security, the token response is provided as a hash tag (#) fragment on the URL. This format prevents the token from being passed to the server or to any other servers in referral headers.

Warning

Because the access token is encoded into the redirection URL, it can be exposed to the user and other apps on the device.

Note

Note
External client apps for these types of clients can protect per-user secrets. However, the client secret is accessible and exploitable because client executables reside on the user’s device. For this reason, the user-agent flow doesn’t use the client secret. Authorization is based on the user-agent’s same-origin policy. Also, the user-agent flow doesn’t support out-of-band posts.

Scope Parameter Values

OAuth requires scope configuration both on server and on client. The agreement between the two sides defines the scope contract.

  • Server side: Define scope permissions in an external client app on the Salesforce server. These settings determine which levels of access client apps, such as Mobile SDK apps, can request. At a minimum, configure your external client app OAuth settings to match what’s specified in your code. For most apps, refresh_token, web, and api are sufficient. For the full list of scopes, review OAuth Tokens and Scopes.
  • Client side: Specify scope requests in your Mobile SDK app. Client scope requests must be a subset of the external client app’s scope permissions. In Mobile SDK 13.2 and later, providing no scopes results in all server configured scopes being granted.

External Client Apps

External client apps are packageable frameworks to enable a third-party application to integrate with Salesforce using APIs and security protocols. In addition, they include structural improvements to maintain separate user roles and allow second-generation managed packaging. Salesforce recommends that you use external client apps and migrate existing local connected apps to local external client apps.

Note

Note
Some features are only available through connected apps, and connected apps are still required for Mobile SDK apps that run on multiple orgs. See the Comparison of Connected Apps and External Client Apps Features.

Create an External Client App

You can easily create an external client app, but you must have administrator rights. In your own Developer Edition or Trailhead Playground org, you’re automatically granted these permissions.

  1. In your Trailhead Playground or Developer Edition org, go to Setup.
  2. From Setup, enter Apps in the Quick Find box, and then select External Client Apps Manager.
  3. Select New External Client App.
  4. Under Basic Information, fill out the form as follows.
    • External Client App Name: Trailhead Intro
    • API Name: Accept the suggested value.
    • Contact Email: Enter your email address.
    • Distribution State: To develop an external client app for your local org, select Local. To develop an external client app for packaging and distribution, set the Distribution State to Packaged.
  1. Under API (Enable OAuth Settings), check Enable OAuth.
  2. Set Callback URL to any URL string, real or fictional, such as mysampleapp://auth/success. If autofill offers a suggestion, do not accept it. Instead, paste in the callback URL.
  3. Under Available OAuth Scopes, select:
    • Manage user data via APIs (api)
    • Manage user data via Web browsers (web)
    • Perform requests at any time (refresh_token, offline_access)
  4. Click the Add Arrow to move each selection to the Selected OAuth Scopes. This minimal set of scopes works well for most Mobile SDK apps.
  5. Under Security:
    • Uncheck Require Secret for Web Server Flow.
    • Uncheck Require Secret for Refresh Token Flow.
    • (Recommended) Check Issue JSON Web Token (JWT)-based access tokens for named users.
  6. Click Create.

Now that you know a bit about Mobile SDK architecture and security, it’s time for you to get hands-on with Mobile SDK. You can start by completing the following challenge, which requires only a Developer Edition or Trailhead Playground. Afterward, we recommend that you complete the Set Up Your Mobile SDK Developer Tools badge.

Resources

Comparta sus comentarios sobre Trailhead en la Ayuda de Salesforce.

Nos encantaría conocer su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios cuando quiera desde el sitio de la Ayuda de Salesforce.

Más información Continuar para compartir comentarios