Connected app in Salesforce for absolute beginners
Before starting to learn how to create a Connected app in Salesforce and use it for any purpose, let us first understand about a term called Session IDs. Whenever you login to any website by providing your username and password, the server generates and assigns you a token by sending it to your browser wrapped in a cookie. And in any subsequent requests that you make to the server, the browser appends the token to the request in what is called Authorization header so that the server knows who is making the request. This token is called Session ID and it is a short-lived token whose expiration date is set by the authorization server itself. When you are logged into the any salesforce org, you can view your Session Id by opening the browser console and typing document.cookie.
Another way to view the Session ID is by going to Developer console, opening the Anonymous window and executing the following line:
After you have the session ID, you can make request to Salesforce from any other application such as Java, Python, Node by treating them as Http client. The following picture shows how list of Account is queried from Postman using the Session ID. Notice the Authorization header with Bearer token.
So what does connected app has to do with Session IDs? Well, the answer is simple. There are few steps involved to create a connected app in Salesforce. However, the end goal of using connected app is to get Session ID of any user in that particular org from any external apps. This could be done for various reasons such as integrating the data from the external app to Salesforce, sending any kinds of file to Salesforce through the external app, and many more.
The user, in context of whose the external app is trying to make the request must be permitted to use the Connected app. This can be done in two ways which will be discussed later in the article. This standard design of allowing an external application to access the resources hosted by any other application(Salesforce in our case) on behalf of a valid user is called OAuth which stands for Open Authorization.
There are various OAuth flows in Salesforce that are described in the official documentation and each of these have their own use cases. But in general the four main steps involved are:
- User in Salesforce org allows the external application to have restricted access to the Salesforce on behalf of the user through Connected app.
- External application requests for access token using the client credentials.
- Authorization server validates the request coming from external app and grants Access token in response.
- External application uses the Access token to make request to Salesforce.
Now, since we have understood the objective of using connected app, let us begin creating it.
Go to Setup -> App Manager and click on New Connected App.
Fill in all the required fields as shown above. Here callback URL is the URL that Salesforce Authorization server will redirect the user to after the user successfully authorizes the Connected app by allowing it to access the protected resource. In the parameter, the callback URL receives either authorization code or access token directly based on the parameter value response_type. More about response_type later in the article.
Selected OAuth Scopes define, to what extent should we allow the External App using this connected app to use the resource.
Once you click save, it can take up to 10 minutes for the effect to be seen. Till then we can look into the two ways in which we can permit any user in the org to use the Connected App. Both the ways are managed by changing the OAuth policies. Click on Manage button and you will see this page.
Click on Edit Policies.
These are the two ways:
- All users may self-authorize
- Admin approved users are pre-authorized
All users may-self authorize means that, the user in context of whose we are trying to make request to Salesforce through external app, should manually authorize the connected app. This is done by going to a special link that looks like this:
The URL part is either test or login domain. client_id is taken from the Connected App that we just created, redirect_uri must match the one we mentioned in callback URL and it must be URL encoded. response_type can be anything we want(code, token, id_token) based on our use case.
This page should appear if all the parameters are correct.
Once you click allow, you will be redirected to the mentioned callback URL with necessary data in parameter as mentioned in the response_type. The example we are about to look at doesn’t require a valid endpoint. You could also just add https://localhost in the Callback URL.
Admin approved users are pre-authorized means that, the user in context of whose we are trying to make request to Salesforce through external app, requires permission to use the Connected app and the Admin can give the permission through either permission set or profile.
Now let’s work on getting the access token. For simplicity we will use username and password flow. This is not the flow to be chosen in a business case where exchanging the password and consumer secret to the External Application is risky thing. But to understand the flow of Connected app, this will do the job.
The endpoint to get the token is /services/oauth2/token with POST request. client_id and client_secret should be the ones specified in the connected app. The password needs to have a security token appended to it in the end. Eg: If you password is mypassword1, then the final password value provided should be mypassword1securitytoken. Security token can get generated/reset from Settings->Reset My Security Token.
Now that we have the access_token, we can use it to get limited access to Salesforce data.
The Connected app login usage of the user can be monitored through the user’s login history. Go to Setup->Users->select the user->Scroll below and look for Login History.