OAuth + Salesforce: How it works?

Salesforce uses the OAuth protocol to allow users of applications to securely access to data and metadata without having to reveal your password.

OAuth + Salesforce: How it works?

login-page-1-1

Salesforce uses the OAuth protocol to allow users of applications to securely access to data and metadata without having to reveal your password.

You've probably noticed that some sites offer to authenticate us from our Facebook, Twitter, Google or Salesforce accounts.
As a user, this is very convenient !

This feature is made possible through a secure API provided by Salesforce. The latter also offer several APIs to do a little of everything with your account, including connecting applications of the AppExchange.

By being aware of this information, it is possible that the site you are connecting to can do everything with your account. Do you have interest in connecting to it, providing your login credentials?

To overcome these fears, the solution is to set up a delegation of authorization mechanism between the different entities. OAuth was created in this way.

What is OAuth?

OAuth is a free protocol that allows a client application to use the secure API of another application on behalf of a user.

The major benefit of OAuth is that the user no longer needs to provide credentials to a third-party application because the connection is to the API application.

The roles

OAuth proposes 4 roles:

* Owner's Resource

It is an entity that can grant access to a protected resource. When the owner of the resource is a person, he is designated as the end user.
Ex: having an account on Salesforce.com

* Server Resource

It is a server that hosts protected resources, which is able to accept and respond to requests for protected resources by using access tokens.
Ex: the Salesforce company exposing its API

* Client

This is an application requesting protected resources on behalf of the owner of these and with his permission. This can be a server-side PHP application, a client-side JavaScript application, a mobile application.
Ex: bluefactory.io, website of Bluefactory company

* Authorization Server

This is a server that issues access tokens to the client after the owner of the resource has been formally authenticated and has been granted permission.
Ex: a server of the company Salesforce.

The token

The token is a string of characters, it is issued by the authorization server at the request of the client. The authorization server defines its lifetime and the values of the other parameters.

The scopes

The scope is a parameter that defines the scope of the permissions of the authorization request. The list of scopes is defined at the authorization server.

The client must specify the scopes he wishes to use during the authorization request.

HTTPS

OAuth imposes the use of HTTPS for exchanges between the client and the authorization server because of the sensitive data that passes between the two (access token, possibly identifiers and passwords).

HTTP is a client-server communication protocol developed for the World Wide Web.
HTTPS is the combination of HTTP with an encryption layer like SSL or TLS.

OAuth in real life

You signed up at Bluefactory application. Bluefactory automatically wants to access information from your Salesforce account in a precise scope.
You are redirected by the web browser to the authorization server of Salesforce.
If you allow access, the authorization server redirects you to Bluefactory app and makes the access token available in the URL fragment.

Conclusion

We have seen the basics of the OAuth 2.0 protocol. OAuth 2.0 has become a standard for authorization delegation between different applications. The big companies have adopted it so why not you?