Authentication has always been a topic of interest to me, it involves critical aspects in an application such as security and end-user experience. How we enable the application for authentication has an impact on the ease of integration, security robustness, adoption and scalability.

Salesforce provides a large number of options to authenticate into the platform. The purpose of this series is to try to cover all of them so that they become handy to developers and architects trying to understand the best option to choose while taking into consideration the common use cases, implications and limitations of each one of them.  For this initial post let's talk about Authentication Providers.

In the most simple terms, the authentication providers feature in Salesforce allows you to define an external mechanism of authentication into the platform  (single sign-on) , this means, internal or community users do not need to have Salesforce credentials to login to the platform but can do so by using the credentials of another service such as Google, Facebook, LinkedIn, another Salesforce org or your own custom provider.  This feature allows you to leverage services that support the OpenId Protocol or the OAuth standard, this makes is easy to implement and very convenient considering any modern cloud platform support these standards.

I use this on a daily basis to conveniently login to my main Developer Org (my experimentation environment) using my Facebook credentials so that I don't have to worry about remembering my credentials.


Auth. Providers allows you to decouple your application, the job of authenticating a user is delegated to a service so that authentication becomes a clear separate component of your architecture. In addition to enabling the user to conveniently login to the application using a third party's authentication,  you will be able to also leverage features of OAuth such as the use of scopes. For those not familiar with the concept, scopes is a concept in OAuth in which the client application obtains the permission to access specific resources or perform certain actions with the consent of the authentication provider, often, with the explicit approval of the end user.


Use Cases:

  • A large customer community for which you want to simplify the user registration and management process.
  • An application that requires the use of user's data stored in the third party provider.
  • An organization which uses a custom web application as the main method of authentication and for which you want to enable single sign-on capabilities.