Third-party identity providers

Although Composable Commerce provides robust native Customer authentication, you might need to integrate a third-party IDP to support features such as social logins, single sign-on (SSO), and multi-factor authentication (MFA).

What is an identity provider?

An identity provider (IDP) is an external service that manages user identities and handles the authentication process. The IDP stores and verifies passwords, instead of your application doing so. This approach is useful when you want to offer the sign in with Google feature, integrate with an existing employee directory, or leverage advanced security features that Composable Commerce doesn't provide natively.

Here are a few commonly used third-party IDPs:

• Auth0
• Okta
• Azure AD B2C
• Firebase Authentication
• Social login providers such as Google, Facebook, and Apple.

How IDPs work with Composable Commerce

When integrating an IDP, your application's backend orchestrates two separate authorization flows that typically use OAuth 2.0 or OpenID Connect (OIDC) protocols. It's crucial to understand the distinct roles and participants in each flow.

Flow 1: user authentication

This flow handles the user's sign-in or sign-up process.

• Participants: the user's browser (frontend), your backend for frontend (BFF), and the third-party IDP
• Process: the user authenticates via the IDP. The IDP issues a token (for example, a JWT) to the frontend, which is then passed to your BFF. The BFF validates this token to confirm the user's identity.
• Roles:
  • IDP: the authentication server
  • BFF: the resource server that protects its own endpoints and trusts the IDP.
  • Composable Commerce's role: Composable Commerce is not involved in this flow.

Flow 2: service-to-service API access

This flow allows your backend to securely communicate with the Composable Commerce API.

• Participants: your BFF and the Composable Commerce API
• Process: the BFF uses its own confidential client credentials to obtain an access token from the Composable Commerce authorization server. It then uses this token to make authenticated API calls to manage resources, such as Customers, Carts, and Orders.
• Roles:
  • BFF: the client
  • Composable Commerce: the authorization server and resource server

These two flows are independent. Your BFF acts as a bridge, first verifying a user's identity with the IDP (Flow 1) and then using its own separate credentials to interact with Composable Commerce on that user's behalf (Flow 2).

High-level authentication flow

Here's a breakdown of the steps:

1. The IDP handles user authentication: the IDP manages the username and password logic, social logins, and advanced features such as MFA.
2. The IDP issues tokens upon successful authentication: these are often JSON web tokens (JWTs) that contain information about the authenticated user.
3. Your application backend validates the token: your backend receives the token and either validates it locally or makes an introspection call to the IDP to verify its authenticity.
4. You link the external identity to a Composable Commerce Customer:
   • If a Customer record doesn't exist for the user, then your backend creates a new Customer in Composable Commerce.
   • You store the IDP's user ID in the externalId field of the Composable Commerce Customer. This externalId links the IDP user to the Composable Commerce Customer.
   • If the Customer already exists, then your backend retrieves their record by using the externalId field.
5. Composable Commerce manages all e-commerce data: the IDP is used only for authentication. All Customer-specific data such as addresses, Carts, and Orders reside within Composable Commerce, linked by the customerId and externalId fields.

Role of backend for frontend (BFF)

The Composable Commerce API doesn't directly introspect external IDP tokens. Your backend for frontend (BFF) must perform this validation before it can use the IDP-authenticated identity to interact with Composable Commerce.

When to use an IDP

You should consider using an IDP in the following scenarios:

• Single sign-on (SSO): if users need to access multiple applications with a single login, then an IDP simplifies this by allowing them to use existing credentials.
• Existing user base: if you've a large Customer base in an external system (such as a legacy platform or CRM), then an IDP can help migrate and manage these users without forcing them to re-register.
• Advanced authentication features: for features such as MFA, password-less login, and social logins, IDPs offer out-of-the-box solutions that save significant development effort.
• Compliance and security: IDPs specialize in security and compliance; for example, GDPR and CCPA. Offloading these concerns to a dedicated provider can reduce risk.

Although integrating an external IDP can provide advanced authentication capabilities to your applications, this learning module focuses on the native customer authentication features of Composable Commerce. IDP integration is an advanced architectural decision that builds on a solid understanding of how Composable Commerce manages Customer data.

Key takeaways

• Third-party IDPs manage user authentication, letting you support features such as SSO, MFA, and social logins.
• Your application's backend is responsible for validating the IDP token and linking the external user identity to a Composable Commerce Customer by using the externalId field.
• From the frontend’s perspective, your BFF acts as the resource server, whereas the IDP acts as the authentication authority.
• Composable Commerce acts both as an authorization server and a resource server for the backend, managing commerce data (Carts, Orders, profiles) in a different flow.
• Consider using an IDP if you need to integrate with existing user systems, require advanced security features, or want to simplify compliance.

Test your knowledge