Identity and Access Management – Salesforce as an Identity Provider
Connected App and OAuth Terminology
| Access Token | Instead of using the Salesforce credentials, a consumer (connected app) can use an access token to gain access to protected resources on behalf of the user. (OAuth 1.0.A – access token exchanged for a session ID, OAuth 2.0 the access token is a session ID and can be used directly. |
| Authorization Code | Only used in OAuth 2.0 witht he web server flow, the authorization code isa token that represents the access granted by the end user. The authorization code is used to obtain an acces token and a refresh token. It expires after 15 minutes. |
| Authorization Server | The authorization server is the server that authorizes a resource owner, and upon successful authoriaation, issues access tokens to the requesting consumer. |
| Callback URL | A callback URL is the URL that is invoked after OAuth authorization for the consumer (Connected App). In some contexts, the URL must be a real URL that the client’s web browser is reidrected to. In others, the URL isn’t actually used, but the value between your client app and the server (the connected app definition) must be the same. |
| Consumer | A consumer is the website or app that uses OAuth to authorize botht eh Salesforce user and itself on the user’s behalf. Referred to as client in OAuth 2.0. |
| Consumer Key | A consumer uses a key to identify itself to Salesforce. Referred to as client_id in OAuth 2.0. |
| Consumer Secret | A consumer uses a secret to establish ownership of the consumer key. Referred to as client_secret in OAuth 2.0. |
| OAuth Endpoint | OAuth endpoints are the URLs that you use to make OAuth authorization requests to Salesforce |
| Nonce | Nonce is a number, often a random number, used during authorization to ensure that requests cannot be reused. |
| OAuth | Open Authorization (OAuth) is a standard, token-based protocol for authorization. |
| Refresh Token | Only used in OAuth 2.0, a consumer can use a refresh token to obtain a new access token, without having the end user approve the access again. |
| Request Token | Only used in OAuth 1.0.A, a consumer(connected app) can use a request token to obtain authorization from the end user. It exchanges the token for an access token. |
| Resource Owner | The resource owner is the entity (usually the end user) that grants access to a protected resource. |
| Resource Server | Thre resource server is the server that hosts the protected resource. Your Salesforce org is the resource server that protects your data. |
| Token Secret | A consumer uses this secret to establish ownership of a given token, both for request tokens and access tokens. |
| User | An individual who has a Salesforce login. |
Authorize Apps with OAuth
OAuth cannot be used independently to authenticate a users identity, use OpenID as an authentication service.
| OAuth Authorization Flows | Grants access to a client application restricted access to protecterd resources on a resource server. Consists of three main steps: Client App Requests Access to Protected Resource, Authorizing Server Grants Access Tokens to Client App, Resource Server Validates Access Tokens and Approves Access |
| OAuth Tokens and Scopes | Connected app receive tokens on behalf of a client after authorization. Scopes further define the type of protected resources that the connected app can access. The scopes are assigned to the connected app when you build it. |
| Revoke OAuth Tokens | Revoke a token if you don’e want an external client to access Salesforce data or if you don’t trust the client to discontinue on their own. |
| OAuth Custom Scopes | Create an OAuth custom scope to customize permissions to the protected resource. |
| Identity URLs | Gateway to the Salesforce Identity Service that can be accessed using the OAuth 2.0 user-agent or web server flows. When connected app with the id scope is successfully authorized it receives an identity URL along with the access token. The connected app can then send a GET request with the access token to the identity URL. In response Salesforce returns details about the queried user and org. |
| OAuth Endpoints | OAuth endpoints are the URLS that you use to make OAuth authroization requests to Salesforce. Each OAuth flow defines which endpoints to use and what request data to provide. |
| Enable CORS for OAuth Endpoints | Web applications use Cross-Origin Resource Sharing (CORS) to request resources from origins other than their own. For example, a web page can use CORS to request infromation about a user from your My Domain or Experience Cloud site. In addition to public and allowlisted web pages, Salesforce supports CORS for certain OAuth endpoints when requested from a My Domain or Experience Cloud site. |
| Query for User Information | A connected app can query the UserInfo endpoint for information about the user associated with the connected app’s access token. Salesforce returns basic personal information about the user and important endpoints that the connected app can talk to, such as photos and accessible API endpoints. This UserInfo endpoint provides access to information only for current user. It doesn’t give access to other users in the org. |
| Query for the OpenID Connect Configuration | Use the OpenID Connect discovery endpoint to query for information about the Salesforce OpenID Connect configuration. Salesforce returns basic information about endpoints, supported scopes, and other values used for OpenID Connect authorization. |
| Query SAML Authentication Settings | You can query the authentication configuration endpoint for information about an org’s or Experience Cloud site’s SAML single sign-on(SSO) and authentication provider settings. Use thsi functionality when you’re developing apps that need this information on demand. |
Connected App Basics
Build a Connected App for API Integration
OAuth Authorization Flows
| OAuth 2.0 Web Server Flow for Web App Integration | Integrate an external web app with Salesforce API (implements OAuth 2.0 authorization code grant type). Server hosting web app must be able to protect the connected app’s identity defined by the client ID and client secret. |
| OAuth 2.0 User-Agent Flow for Desktop or Mobile App Integration | Authorize a desktop or mobile app to access data using an external or embedded browser. Client apps running in a browser using a scripting language such as JavaScript can alsu use this flow. This flows uses the OAuth 2.0 implicit grant type. |
| 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 Authorization and Session Management for Hybrid Apps | A hybrid app sets requested domain cookies and bridges an access token into a web session. However, the access token and web session aren’t connected and they will need to be tracked to check wehn access and refresh tokens expire. They must then be manually rebridged to continue the session. |
| OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration | This flow uses a certificate to sign the JWT request and doesn’t require explicit user interaction, prior approval of the client app is required. |
| OpenId Connect Dynamic Client Registration for External API Gateways | You can use OpenID Connect dynamic client registration to enable your Salesforce instance as an independent OAuth authorization server to protect resources hosted on an external API gateway. |
| Generate an Initial Access Token | OpenID Connect dynamic client registration OAuth 2.0 clients – connected apps – directly register connected apps with Salesforce. An initial access token is required. |
| OpenID Connect Token Introspection | Allows all OAuth connected apps to check the current state of an OAuth 2.0 access or refresh token. |
| OAuth 2.0 Device Flow for IoT Integration | To integrate apps that run on devices with limited input or display capabilities (Smart TVs, appliances and other IoT deveices). Command line apps can also use this flow. |
| OAuth 2.0 Asset Token Flow for Securing Connected Devices | Assest tokens are an open-standards-based JWT authentication token. They identify the device to a backend service that processes the stream of data and events from the device. |
| Demo the Asset Token Flow | For a quick demo of the asset tokens. |
| OAuth 2.0 Username-Password Flow for Special Scenarios | This flow can be used to authorize a client via a connected app that already has the user’s credentials. Use only if there is a high degree of trust between the systems as it passes credentials back and forth. |
| Block the OAuth 2.0 Username-Password Flow | Prevents developers from using the OAuth 2.0 Username-Password flow to ensure security. |
| OAuth 2.0 SAML Bearer Assertion Flow for Previously Authorized Apps | Client – via connected app – can use previous authorization by providing signed SAML 2.0 assertion to request OAuth access token. |
| SAML Assertion Flow for Accessing the API | Alternative for orgs that use SAML. Can federate with the API using a SAML assertion. |
| OAuth 2.0 Authorization Errors | When errors occur authorizing server sends an error code to the callback URL with an error code. |
| OAuth 1.0.A Flow | If your org uses OAuth 1.0.A protocol use this to integrate a client via a connected with the Salesforce API |
| OAuth 1.0.A Authorization Error Codes | When errors occur Salesforce returns an error code |