Understand Security and Compliance with the Salesforce Mobile App
- Outline the two options for mobile security with the Salesforce mobile app.
- List some of the security features that the Salesforce app provides.
- Define what a connected app is.
- Explain how the Salesforce app uses OAuth to authenticate users.
Hopefully you’re not having nightmares after reading all that scary stuff about mobile security threats. Before you lose any sleep, we can tell you that the Salesforce mobile app provides enterprise-level security right out of the box.
Using something called connected app policies in Setup, admins can control things like mobile session timeouts, PIN code enforcement, IP restrictions, and more. You’ll learn how to configure those policies in the next unit.
In terms of implementing the mobile security settings, you have two options:
- Implement the Salesforce app on its own: To lock down the Salesforce app in a way that meets your company’s security needs, configure the connected app policies in Setup . This option is sufficient for most organizations.
- Implement the Salesforce app with MDM: Some customers have security and compliance requirements that can’t be met using the Salesforce app alone. Those customers typically use a mobile device management (MDM) solution to add extra layers of security and compliance safeguards. You learn more about MDM later in this module.
OK, so what security and compliance features does the Salesforce app provide? We include a brief overview here, but the Salesforce Mobile App Security Guide covers this information in full and glorious detail.
Don’t forget to give the guide to your experts to address their security questions and concerns. (And feel free to read the guide if you’re into geeky technical stuff. Or if you have insomnia. Just kidding! We think mobile security is pretty cool.)
|Authorization||Authorization is the right to use the app. By default, all Salesforce users have access to the Salesforce app. But you can use profiles and permission sets to grant mobile access to only a subset of employees.|
|Permission||The Salesforce app provides access to data based on the permissions defined for each user by their Salesforce admin. Mobile users can’t view or access more than their permissions allow.|
|Authentication||Just because someone has the Salesforce app installed on their device, they can’t necessarily access Salesforce. They have to authenticate using their Salesforce credentials or single sign-on (SSO). If your company uses SSO, the Salesforce app supports both federated and delegated authentication.|
|Communication||Mobile data is encrypted during over-the-air communication.|
|Encryption||Salesforce data is encrypted on the device, which is then double-encrypted by the mobile OS. Files and attachments are also encrypted on the device file system.|
|Data protection||With the Salesforce app, you have additional security safeguards at your disposal, including the ability to remotely wipe the Salesforce data on a device.|
|Compliance||The Salesforce app provides settings that can help you meet industry requirements, such as disabling copy and paste from Salesforce to other apps and requiring the use of a specific email client.|
|MDM integration||The Salesforce app can provide an extra level of security through integration with the most popular MDM solutions. Combined with an MDM, the Salesforce app gives you more control over your users’ devices, as well as additional app distribution options.|
So now you know a little bit about the security features available with the Salesforce app. But what about the app itself? How is it architected, and how does that relate to security?
If you’re unfamiliar with the Salesforce app, the first thing to know is that it actually comes in a few flavors. Let’s get acquainted with them:
- Downloadable Apps: The Salesforce downloadable apps are available for Android and iOS devices that meet platform requirements. Users can download and install Salesforce from Google Play or the App Store.
- Mobile Browser App: The Salesforce mobile browser app runs in a mobile browser on Android, iOS, and Windows devices that meet platform requirements. This option doesn’t require installing anything.
No matter which flavor you use, the Salesforce app runs on the device in a sandboxed environment. (A sandbox! Does that mean we get to play on the playground and build sandcastles together? Sadly, no—it’s not that kind of sandbox.)
Sandboxing is a security technique the mobile OS employs to restrict and isolate apps so they can’t share data with each other. Mobile apps also have to explicitly ask for permission to get access to device features, like the calendar, camera, or microphone. When the Salesforce app is installed on a device, the OS prompts the user to grant a handful of permissions. For a complete list of the permissions, see the security guide.
The last thing for you to know about the architecture is how the mobile app establishes a connection to Salesforce. After all, the Salesforce app that exists outside of the full Salesforce site. Because of that, the Lightning platform considers the Salesforce mobile app to be a connected app.
It’s pretty simple, really. A connected app is an external application that integrates with Salesforce through APIs. It uses something called OAuth to verify both the Salesforce user and the external application.
OK, so...what’s OAuth? OAuth is an industry-standard protocol that lets applications obtain secure access to services such as Salesforce. So a user can work in one app (such as the Salesforce mobile app) and see data from another app (such as Salesforce). Behind the scenes, the apps perform a kind of handshake, and then ask the user to authorize the data sharing.
Best of all, this handshake happens without exposing users’ passwords. Instead, the Salesforce app collects the user’s credentials, which are then sent to the Salesforce server. The server returns a token that is used by the mobile app to establish the user’s mobile session. Passwords are never stored on the device.
Are you new to OAuth and confused about the difference between a token and a password? Let’s clear things up using an analogy from the world of airline travel; it can be helpful to think of the token as a boarding pass.
When you check in for a flight at the airport, you present the agent with a valid form of ID (that is, your Salesforce credentials). After the agent confirms your identity as the correct passenger (authenticates you), you receive a boarding pass (a token). Then later when you get to your gate, you aren’t required to show your ID again—just your boarding pass.
And if you lose your boarding pass, you have to “reauthenticate”: You talk to the gate agent, present your credentials again, and then receive a new boarding pass.
Hopefully that sheds some light on how a token is different than a password. With that out of the way, let’s talk about the two types of OAuth tokens.
After a user logs in to the Salesforce app for the first time and successfully completes the OAuth authentication, the user obtains both an access token and a refresh token. It’s important to understand the difference between them.
- Access Token
- A value used by the Salesforce app to gain access to Salesforce on behalf of the user, instead of using the user’s Salesforce credentials. The access token is a session ID.
- Refresh Token
- If a user’s session has expired, the Salesforce app attempts to use the refresh token to obtain a new access token so the user doesn’t have to reauthenticate. As the admin, you control how long the refresh token for the Salesforce app is valid. You can revoke a refresh token the first time a user uses the app, every time a user uses the app, or on a set schedule (hourly, daily, or monthly). You learn how to do that in the next unit.
The good news is that you don’t need to be an OAuth wizard to manage your Salesforce mobile security settings—you just need to know the basics. The easiest way to grasp how OAuth works is to step through the authentication flow.
The flow of events during OAuth authorization depends on the state of authentication on the device.
First Time Authorization
- User opens the Salesforce app.
- An authentication page appears.
- User enters their username and password.
- The Salesforce app sends the user’s credentials to Salesforce and, in return, receives a session ID as confirmation of successful authentication.
- User grants access to the Salesforce app.
- The app starts.
- User opens the Salesforce app.
- If the session is active, the app starts immediately. If the session has expired, the Salesforce app uses the refresh token from its initial authorization to get an updated session ID. (However, if the refresh token has expired, the user must reenter their credentials.)
- The app starts.
This simple authentication flow doesn’t cover the process for single sign-on. We get to that later in the module.
All right, by now you understand how the Salesforce app establishes a secure connection with Salesforce and authenticates users. But how does this knowledge help you manage your Salesforce mobile security settings?
Remember how we talked about connected app policies at the beginning of this unit? Well, now you know what they are: Salesforce gives you the ability to edit the security settings—or policies—for all the connected apps in your organization, including the Salesforce mobile app. And some of those policies relate specifically to OAuth, so it’s important to learn about the authentication process before you configure any security settings.
OK, awesome admins! We’ve laid all the necessary groundwork. So roll up your sleeves because in the next unit, we get our hands dirty and tinker with the connected app policies.