Connecting to Third-Party Systems
Introduction
Integrations with third-party systems are a common requirement for custom frontends. B2B operations are often data-heavy and can potentially involve information from multiple systems, making this topic of third-party integrations especially relevant for the B2B Buyer Portal.
Third-party API integrations can be fairly straightforward in a traditional web application with a server-side layer. The Buyer Portal, however, is a client-side application. The portal already handles user authentication with one API - namely, the B2B GraphQL API. How do we translate this authentication into secure access to a third-party system from the browser?
The Challenge of Client-Side API Requests
Let’s define a hypothetical scenario for a third-party integration. Your B2B operations might involve using a CRM system for managing support cases opened by buyers for their orders. And users of your storefront might need to see support case information when viewing their orders, sourced from the CRM. Assume that the B2B Edition company a user is associated with has a corresponding entity in the CRM system.
Any API requests to the CRM must originate in the browser, where the client app runs. How do you ensure these requests are properly and securely authenticated? It’s unlikely the CRM implements a storefront API (like the B2B GraphQL API) with auth tokens designed to be used in the open. (Even if so, we would need a single sign-on solution to avoid managing two logins for the user.)
The challenges can be summarized this way:
- Secrets in the browser: The credentials for our hypothetical CRM API are a sensitive secret that must not be exposed.
- No shared identity: The user’s established authentication with the B2B GraphQL API means nothing for authentication with the CRM’s API.
Solving our client-side API challenges will therefore be similarly two-fold:
- Server-side layer: Rather than making direct API requests to the CRM from the browser, we need our own server-side middleware to manage this data. This middleware might proxy requests directly to the CRM, but a more efficient solution is likely to allow the middleware to store minimal support case data pushed to it from the CRM. The sensitive credentials for the CRM API would be stored securely in the middleware application for any requests it needs to make.
- B2B Token Validation: A logged-in user has already been authenticated with B2B Edition and has a token to prove their identity. Our middleware can use this token with the B2B GraphQL API to verify the user belongs to a particular company.
Middleware and Token Exchange
Since our hypothetical middleware serves primarily to control the flow of data to a UI, it can be thought of as implementing a “backend for frontend” (BFF) pattern.
A key capability of this middleware would be to capitalize on the user’s existing authentication with the B2B GraphQL API to verify the user’s (and company’s) identity. It could then issue its own token.
A high-level overview of this strategy:
- Authentication request: The Buyer Portal calls the middleware with the user’s B2B GraphQL API token.
- Verification: The middleware uses the B2B GraphQL API to verify the token and the company identity.
- Token exchange: The middleware issues its own secure token back to the Buyer Portal user.
- Subsequent requests: The Buyer Portal sends future requests to the middleware with the unique token, and the middleware validates the token and returns data.
Building out a middleware or BFF like this is beyond the scope of this course, but we’ll simulate this workflow from the Buyer Portal perspective in the next lab.
Json Web Tokens
Json Web Tokens (JWTs) are well suited for the type of token to be issued by the middleware in our hypothetical scenario. JWTs are an open industry standard for transmitting claims between two parties, and they are designed specifically to be transmitted in the open (such as publicly in the browser) while still being trusted.
A JWT is an encoded version of information represented in simple Json format, signed by a secret that is not shared publicly. So while the content of a JWT exposed in the browser can be tampered with, the middleware application uses the secret to verify the integrity of the token and will reject a token that has been altered.
The B2B GraphQL API token is, itself, a JWT. This is why it is secure to transmit publicly from the browser.
Single Sign-On
The straightforward method described above is a homegrown solution relying on the Buyer Portal’s existing authentication with the B2B GraphQL API. For the type of integrations we’re describing in this section, another option is to use a full single sign-on (SSO) solution to manage authentication.
Popular third-party SSO providers (such as Okta or OneLogin) can be used to manage user authentication and authorization to multiple systems. In a SSO flow, the user’s initial authentication would be done through the SSO provider, and the SSO would manage appropriate credentials for multiple systems (in our scenario, the B2B GraphQL API and the middleware application).
SSO can be an appropriate solution if your authentication requirements are complex. If replacing the built-in Buyer Portal login flow with a SSO integration, note the key capability of the B2B REST Management API to issue storefront tokens.
In Headless
In Catalyst or other headless storefronts, you have more flexibility for integration strategy. You might opt to make third-party API requests in the server-side layer already part of your storefront application. This bypasses the client-side challenges discussed here.
