function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Usman AslamUsman Aslam 

What is the recommended approach by Salesforce for mobile application authentication?

What is the recommended approach by Salesforce for mobile application authentication?
 - SAML based authentication?
 - OAuth User-Agent flow?
 - OAuth Username-Password Flow?
 - Session Id flow?

Here is my understanding:
SAML seems out question, because it involves identity provider and in most cases we don't utilize an ID provider.

In User-Agent flow we need a connected app and don't have to provide password at all and access token is sent to pre-defined callback URL. Which is not happening in all of the mobile applications available, such Salesforce1.

Salesforce1 app seems close to OAuth Username-Password Flow but we don't have to provide security token. We can login to any instance with a valid username and password and our IP is not white listed either. How can we authenticate without a security token? I believe there is a browser plugin running in the Salesforce1 app and we have to tap 'Allow' access after login and have to provide verification code as well (one time only). Tapping 'Allow' and verification code is alternative to security token?

I don't know anything anout session Id flow and didn't find any details.

I am NOT looking for code, just a general opinion about the best approach from the four option above.

Thanks in advance.

Usman
Best Answer chosen by Usman Aslam
Mohith Kumar ShrivastavaMohith Kumar Shrivastava
Salesforce 1 Uses OAuth 2.0 web server authentication .This is documented in the security guide of salesforce 1 in page 6.

https://resources.docs.salesforce.com/sfdc/pdf/salesforce1_mobile_security.pdf

A user obtains an access and refresh token after successfully completing the OAuth 2.0 web server authentication. A user can use the refresh token to get a new access token (session ID). Upon logout, the OAuth access and refresh tokens are revoked, and the user set passcode is wiped (if passcode is enabled by org administrator). The user is re-prompted to enter the username/password and reset the passcode.

Refresh Token and access Token are securely stored in the device .

iOS Downloadable App:
AES-128 with a 256 bit key consisting of a SHA-256 hashed concatenation of a generated RFC 4122 Universally Unique Identifier (persisted to the encrypted keychain) and a Base64 encoded SHA-256 hash of the device passcode (this 4 to 8 digit non-alphanumeric passcode requirement is enabled by the org administrator and is set by the client). Token is stored in the keychain using kSecAttrAccessibleWhenUnlockedThisDeviceOnly to preserve the session for the user, because iOS may terminate the application. 

Android Downloadable App:
PBKDF2 produced AES-256 encrypted key derived from device unique Android ID and randomly generated string. Token is stored in Android’s AccountManager. The SQLCipher-encrypted key is derived from the passcode, if enabled by org administrator, or UUID (universally unique identifier) if the passcode isn’t enabled.

Mobile Browser App:
Access token is never stored on the mobile device. The mobile browser app requires a user to re-enter the username/password to obtain a new access token.

I think similar type of approach can be adopted for the custom app as well .The key is to securely protect the tokens in the app and salesforce SDK has inbuilt mechansim for all this .

All Answers

Mohith Kumar ShrivastavaMohith Kumar Shrivastava
Salesforce 1 Uses OAuth 2.0 web server authentication .This is documented in the security guide of salesforce 1 in page 6.

https://resources.docs.salesforce.com/sfdc/pdf/salesforce1_mobile_security.pdf

A user obtains an access and refresh token after successfully completing the OAuth 2.0 web server authentication. A user can use the refresh token to get a new access token (session ID). Upon logout, the OAuth access and refresh tokens are revoked, and the user set passcode is wiped (if passcode is enabled by org administrator). The user is re-prompted to enter the username/password and reset the passcode.

Refresh Token and access Token are securely stored in the device .

iOS Downloadable App:
AES-128 with a 256 bit key consisting of a SHA-256 hashed concatenation of a generated RFC 4122 Universally Unique Identifier (persisted to the encrypted keychain) and a Base64 encoded SHA-256 hash of the device passcode (this 4 to 8 digit non-alphanumeric passcode requirement is enabled by the org administrator and is set by the client). Token is stored in the keychain using kSecAttrAccessibleWhenUnlockedThisDeviceOnly to preserve the session for the user, because iOS may terminate the application. 

Android Downloadable App:
PBKDF2 produced AES-256 encrypted key derived from device unique Android ID and randomly generated string. Token is stored in Android’s AccountManager. The SQLCipher-encrypted key is derived from the passcode, if enabled by org administrator, or UUID (universally unique identifier) if the passcode isn’t enabled.

Mobile Browser App:
Access token is never stored on the mobile device. The mobile browser app requires a user to re-enter the username/password to obtain a new access token.

I think similar type of approach can be adopted for the custom app as well .The key is to securely protect the tokens in the app and salesforce SDK has inbuilt mechansim for all this .
This was selected as the best answer
Usman AslamUsman Aslam
@Mohith - Thanks for the detailed reply.
Documentation in PDF says:
All components of Salesforce1 require user authentication at the point and time of access. Salesforce1 utilizes OAuth2.0 for authentication through username/password or SSO (single sign-on) credentials.
I am getting close to reply :).
Lets waits for another reply and then I mark this as solved.

Thanks