Salesforce provides wide range of functionalities which help its customers to grow their business. Because of the Point and Click services, advanced functionalities given by Salesforce, various organizations have started switching to Salesforce CRM from their conventional technologies. But sometimes it becomes difficult to migrate existing system to Salesforce completely, for which we are required to connect different environments with Salesforce. This connection can include providing access to your organization or accessing another environment of different technology base or Salesforce org. In case of providing access to your org Salesforce provides OAuth Authorization Flows. These authorization flows provide access to protected Salesforce resources with the help of connected apps.When dealing with clients around the globe one can’t assume that everybody is using same resources or same technology. Also, connection implementation can vary from customer to customer. Salesforce gives us flexibility in OAuth implementation to use connection methods as per the available resources.You can decide which method to use for communicating with the third-party system based on customer requirement, environment, security considerations of data being transmitted and other factors such as token generation, number of logins required etc. We will discuss about OAuth and different OAuth flows provided by Salesforce in this blog. Before moving ahead, lets understand what is OAuth: OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.Access tokens replace the conventional password authentication. Salesforce generates token through connected app and requesting client use this token in further communications. During this process resource server (in our case Salesforce org), client (requesting access) and resource owner (you being the admin of Salesforce org) involve and permission to access the resource is granted. Here Salesforce also acts as authorization server as well. Basic flow of OAuth can be pictured as In traditional client-server communication model, to access server resource client must have server credentials which are provided by resource owners. Though this is widely used method for server authentication it has some limitations as well –Clients must store server credentials somewhere in files to use them for communicationThere might be some scenarios where servers might expose access to all resourcesSince same credentials would be shared across all third parties, it can be difficult to revoke access of single third party unless you change credentials. But this can result in modification at all third parties.OAuth helps to overcome these limitations. Role of Connected App in OAuth Authorization Flows Connected apps are essential when using OAuth authorization flows as connected app framework enables an external client application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these protocols to authenticate, authorize, and integrate external apps and service providers. Different OAuth Authorization Flows in Salesforce OAuth Authorization Flow Use case OAuth 2.0 Web Server Flow for Web App Integration When you want to access salesforce data from external web app OAuth 2.0 User-Agent Flow for Desktop or Mobile App Integration When you want to access salesforce data from external mobile or desktop app OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration When you want to authorize servers to access data without interactively logging in each time the servers exchange information OAuth 2.0 Device Flow for IoT Integration When you want to use some apps that have limited input capabilities (Smart TVs, IoT devices) OAuth 2.0 Refresh Token Flow for Renewed Sessions The OAuth 2.0 refresh token flow renews access tokens issued by the OAuth 2.0 web server flow or the OAuth 2.0 user-agent flow OAuth 2.0 Username-Password Flow for Special Scenarios For special scenarios where other grant types are not available and communicating parties highly trusted OAuth 2.0 SAML Bearer Assertion Flow for Previously Authorized Apps With the OAuth 2.0 SAML bearer assertion flow, a client—via a connected app—can use previous authorization by supplying a signed SAML 2.0 assertion to request an OAuth access token Conclusion Though Salesforce provides different flows for different use cases, some flows have environment specific concerns. Being developers, we should decide what best suits our requirement. It also depends on other system we are connecting with. You can use username & password-based authentication if you are connecting system from your organization’s ecosystem. If you want to allow access to Salesforce for an application that runs on a device with limited input capabilities, then you can go for Device flow. If your system does not provide UI (server to server communication), you want to avoid multiple logins and you want have connection with Salesforce then you can go for JWT flow. Similarly, there are other flows for different scenarios. We will discuss about JWT flow in my next blog. Manish Raghunath Khade Salesforce Consultant Manish KhadeEnvelopeLinkedin Manish Khade Envelope Linkedin Envelope Linkedin
Salesforce provides wide range of functionalities which help its customers to grow their business. Because of the Point and Click services, advanced functionalities given by Salesforce, various organizations have started switching to Salesforce CRM from their conventional technologies. But sometimes it becomes difficult to migrate existing system to Salesforce completely, for which we are required to connect different environments with Salesforce. This connection can include providing access to your organization or accessing another environment of different technology base or Salesforce org. In case of providing access to your org Salesforce provides OAuth Authorization Flows. These authorization flows provide access to protected Salesforce resources with the help of connected apps.When dealing with clients around the globe one can’t assume that everybody is using same resources or same technology. Also, connection implementation can vary from customer to customer. Salesforce gives us flexibility in OAuth implementation to use connection methods as per the available resources.You can decide which method to use for communicating with the third-party system based on customer requirement, environment, security considerations of data being transmitted and other factors such as token generation, number of logins required etc. We will discuss about OAuth and different OAuth flows provided by Salesforce in this blog. Before moving ahead, lets understand what is OAuth: OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.Access tokens replace the conventional password authentication. Salesforce generates token through connected app and requesting client use this token in further communications. During this process resource server (in our case Salesforce org), client (requesting access) and resource owner (you being the admin of Salesforce org) involve and permission to access the resource is granted. Here Salesforce also acts as authorization server as well. Basic flow of OAuth can be pictured as In traditional client-server communication model, to access server resource client must have server credentials which are provided by resource owners. Though this is widely used method for server authentication it has some limitations as well –Clients must store server credentials somewhere in files to use them for communicationThere might be some scenarios where servers might expose access to all resourcesSince same credentials would be shared across all third parties, it can be difficult to revoke access of single third party unless you change credentials. But this can result in modification at all third parties.OAuth helps to overcome these limitations. Role of Connected App in OAuth Authorization Flows Connected apps are essential when using OAuth authorization flows as connected app framework enables an external client application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these protocols to authenticate, authorize, and integrate external apps and service providers. Different OAuth Authorization Flows in Salesforce OAuth Authorization Flow Use case OAuth 2.0 Web Server Flow for Web App Integration When you want to access salesforce data from external web app OAuth 2.0 User-Agent Flow for Desktop or Mobile App Integration When you want to access salesforce data from external mobile or desktop app OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration When you want to authorize servers to access data without interactively logging in each time the servers exchange information OAuth 2.0 Device Flow for IoT Integration When you want to use some apps that have limited input capabilities (Smart TVs, IoT devices) OAuth 2.0 Refresh Token Flow for Renewed Sessions The OAuth 2.0 refresh token flow renews access tokens issued by the OAuth 2.0 web server flow or the OAuth 2.0 user-agent flow OAuth 2.0 Username-Password Flow for Special Scenarios For special scenarios where other grant types are not available and communicating parties highly trusted OAuth 2.0 SAML Bearer Assertion Flow for Previously Authorized Apps With the OAuth 2.0 SAML bearer assertion flow, a client—via a connected app—can use previous authorization by supplying a signed SAML 2.0 assertion to request an OAuth access token Conclusion Though Salesforce provides different flows for different use cases, some flows have environment specific concerns. Being developers, we should decide what best suits our requirement. It also depends on other system we are connecting with. You can use username & password-based authentication if you are connecting system from your organization’s ecosystem. If you want to allow access to Salesforce for an application that runs on a device with limited input capabilities, then you can go for Device flow. If your system does not provide UI (server to server communication), you want to avoid multiple logins and you want have connection with Salesforce then you can go for JWT flow. Similarly, there are other flows for different scenarios. We will discuss about JWT flow in my next blog. Manish Raghunath Khade Salesforce Consultant Manish KhadeEnvelopeLinkedin Manish Khade Envelope Linkedin Envelope Linkedin
