Authentication Requirements

  • Article

In addition to hosting the Display Services iframe or JS SDK within your solution, partners must implement the following authentication requirements in order to enable usage of the iframe:

  • Integrations must use OAuth2-based Sales Access Tokens to authenticate users within the iframe.
  • The developer applications used to request Sales Access Tokens must be created via the Provisioning API. One application must be created on behalf of each tenant.
  • The domain in the HTTP referer header must be allowlisted for the developer application the SAT corresponds to as described in this article.

Using Sales Access Tokens

Sales Access Tokens are required as a means of authenticating users. Sales Access Tokens are access tokens with a short TTL which are requested from the /salesAccessTokens API using a valid long-lived access token. The short-lived access token is then passed into the iframe's query string to authenticate the user.

There is a detailed walkthrough of how to implement authentication with Sales Access Tokens here.

Requesting Developer Credentials on Behalf of Your Customers

Partners must create one set of developer credentials for each customer group that uses the Display Services integration. In order to request developer application credentials through the provisioning API, a partner's developer application is granted permission to make requests to the Provisioning API. Applications created via the Provisioning API receive predetermined permissions. For Display Services partners, any developer applications created via the Provisioning API will automatically be granted the r_sales_nav_display permission. When this permission is requested as the scope in the 3-legged authorization code grant flow, the resulting access token can be used to call /salesAccessTokens for a short-lived token to authenticate the iframe.

One Developer Application per Customer

Developer applications must be created on behalf of each customer/tenant that exists within the partner solution. This is required for a number of reasons:

  • Some partners may need to allowlist unique domains for each customer.
  • LinkedIn may need to throttle individual developer applications due to irregular behavior/excessive usage. Throttling one customer's developer application will prevent all other customers from being impacted.

You should specify an ID for the tenant when creating the developer application in the uniqueForeignId field of the create application request. You can find more details in the Provisioning API documentation.

Domain Allowlist

When the iframe is loaded by clients, the domain of the page the iframe is loaded on will be sent to LinkedIn in the HTTP referer header of the HTTP request. Any domain the iframe is loaded on must be allowlisted for the developer application that the Sales Access Token corresponds to. The domain in the header is validated by LinkedIn against the validJsSdkDomains list defined for the application. This list can be created when a new developer application is requested, or modified over time in an update request as described in the Provisioning API documentation.