OAuth 2.0 (Open Authorization)
Salesforce CRM applications are built on the power of Salesforce Platform, so business could be run on any device, easily build new customer applications or integrate with existing back office systems. It has various modules for Sales, Service, Marketing, Commerce, Quip, Platform and more.Per it’s 2017 Annual Report there are more than 150,000 Salesforce customers. Going by the same number Salesforce should now have a total subscriber base of 3.75 million.
OAuth (Open Authorization) is an open protocol that provides secure API authorization from applications in a simple and standardized way. This protocol is available in all the editions including Salesforce Classic and Lightning Experience.
While managing connected Apps it is required to have user permission to MANAGE, CREATE, EDIT and DELETE OAuth apps. HorizonCore owns expertise in the API integration, customized app development even on Salesforce platform. Let’s have a brief about OAuth 2.0 protocol which is used for Remote Access Application.
The Salesforce platform implements the OAuth 2.0 authorization framework. APIs, such as the Salesforce REST and SOAP web service APIs or the Chatter REST API, can use OAuth 2.0 to authorize access to Salesforce resources.
How OAuth 2.0 works?
OAuth gives a client application restricted access to your data on a resource server. To allow access, an authorization server grants tokens to the client app in response to an authorization.
Contrast this approach with giving your username and password to a client app to access a resource server on your behalf, effectively impersonating you. That application now has precisely the same access as you to your data. If you no longer trust the client app, your only recourse is to change your password at the resource server and for similar client apps—an inconvenience and a security risk. For this reason, OAuth tokens are a better solution.
There are There are four OAuth tokens.
1) Authorization code – Authorization server pass this token to client application via browser. And client sends the authorization code back to the authorization server to obtain an access token.
2) Access Token – On behalf of the end user client use an access token to make a request. When an access token expires, attempts to use it fail, and the app must obtain a new access token.
3) Refresh token – The client application can store a refresh token, using it to periodically obtain fresh access tokens.
4) ID token – OpenID Connect, an authentication layer on top of OAuth 2.0, defines an ID token as a signed data structure. The data structure contains authenticated user attributes (including a unique identifier for the user), the time when the token was issued, and an identifier for the requesting client. An ID token is encoded as a JSON web token (JWT).
Choosing an OAuth 2.0 Authentication Flow for Salesforce
There are various authentication flows of OAuth 2.0 while working with Salesforce, but it is required to select correct flow for the process. For better execution, there is an ideal authentication flow for Salesforce asunder.
• Web Server -server must be able to protect the client secret. This flow uses an OAuth 2.0 authorization code grant type.
• JWT Bearer Token Flow – The main use case of the JWT Bearer Token Flow is server-to-server API integration. This flow uses a certificate to sign the JWT request and doesn’t require explicit user interaction.
• Device Authentication Flow – Command-line apps or applications that run on devices with limited input and display capabilities, such as TVs, appliances, and other IoT devices, can use this flow.
• Asset Token Flow – This flow combines issuing and registering asset tokens for efficient token exchange and automatic linking of devices to service cloud asset data.
• SAML Bearer Assertion Flow – An app can also reuse an existing authorization by supplying a signed SAML 2.0 assertion
• SAML Assertion Flow – This flow is an alternative for orgs that are using SAML to access Salesforce and want to access the web services API in the same way.
• Username & Password – Use it only for testing, when a user is not present at app startup.In these cases, set user permissions to minimize access and protect stored credentials from unauthorized access.
OAuth 2.0 Authentication Endpoints
OAuth endpoints are the URLs that are used to make OAuth authentication requests to Salesforce. When application makes an authentication request, make sure that correct Salesforce OAuth endpoints are being used.
The primary endpoints are:
Instead of login.salesforce.com, customers can also use the My Domain, community, or test.salesforce.com (sandbox) domains in these endpoints.
When a client app makes an authorization request that’s successful, the HTTP response contains an identity URL along with the access token. The URL is returned in the id scope parameter. It is also a RESTful API that you can use to query user information, including the username, email address, and org ID. The identity URL is the gateway to Salesforce’s Identity Service too.
Configuring a Connected App with OAuth
The developer creates the connected app and defines the API integration, providing OAuth metadata about the app, such as:
Basic descriptive and contact information for the connected app
The OAuth scopes and callback URL for the connected app
To configure OAuth settings, select Enable OAuth Settings to open the API section and supply the required metadata, including the callback URL.The callback URL is an endpoint in your application to which Salesforce can redirect the user’s browser with an authentication code or access token. To protect the token, the only hostname allowed with an HTTP callback URL is localhost. Other hosts must use HTTPS. Alternatively. If you’re using the JWT Bearer Token or SAML Bearer Assertion flows, select Use Digital Signatures and upload a signing certificate.
After you save the connected app definition, you are provided an OAuth client ID key and client secret for the connected app.
Deploying a Connected App with OAuth
There are two deployment modes.
The app is created and used in the same Salesforce Org.
The app is created in one org and installed on other orgs. This method is how an entity with multiple orgs or an ISV deploys a connected app.
Admins can install a connected app in their Salesforce orgs and configure profiles, permission sets, and IP range restrictions to control application access.
Using a Connected App with OAuth
For authentication flows, if users are asked to authorize and indicate that they are not the signed-in user. Users can authorize an app to access Salesforce more than once, Newer OAuth 2.0 apps using the Web Server flow are approved for more devices after the user has been granted access once. The User-Agent flow requires user approval every time.
Along with Salesforce CRM integration, our team of expert programmers at HorizonCore is efficient enough to provide various Services like integrating with Facebook API, Google Maps API, Twitter API, LinkedIn API, Amazon API, eBay API, Twilio API, YouTube API. promises deliver any API integration solution that you wish. Our pre-made, scalable and portable scripts allow us to deliver this service in a variety of scripting languages. you can drop us a mail here, or you can hire dedicated developers from us so that they can contribute immensely to your business growth.
To understand the latest version of PHP and the new features of the PHP team added to it, you need … Continue reading “PHP Versions | Detailed Guide On Top Versions Of PHP”Read more
By keeping an eye on the current employee retention concern. We have come up with some measures that we wish … Continue reading “Difficulties in employee retentions and new hirings”Read more
Principally, PHP is interpreted but PHP is collected down to an intermediate bytecode. PHP (Hypertext Preprocessor) is a general-purpose scripting … Continue reading “Is PHP Compilable? Comparing Old PHP and Rearmost PHP Performances”Read more