Skip to main content
Galactic Core gives you two ways to manage who your customers are, differing in which system holds the shopper’s login.

How the two services split the work

  • AuthenticationService (client.auth) owns identity and sessions: register, log in, log out, password reset, OTP, magic links, session refresh, and a “who am I?” check (getCurrentUser → returns the user id and a few identifying fields).
  • CustomersService (client.customers) owns the customer profile resource: provision a customer record, read the full profile (with addresses, store metrics, purchase history, status), update profile fields, and link to an external identity via external_id.
Both services are part of both paths, rather than one service belonging to each. A Path A storefront — where the customer logs in via Galactic Core — still fetches and edits the customer’s profile through CustomersService. The auth service resolves who the customer is; the customers service holds what the customer looks like. Where Path A and Path B differ is how you prove the caller is the customer when calling CustomersService: Any one of these headers authorises the same operation. The customer-self endpoints (getCustomer, updateCustomer) accept all three — you pick whichever matches your integration. Bring-your-own-auth comes in two shapes that differ only in who checks the identity-provider token: with xExternalAuth, your backend verifies the shopper’s login and signs a short assertion Galactic Core checks; with xIdpToken, you hand Galactic Core the raw token and it asks a verifier you run to confirm it (see the two BYO-auth modes below).

The two paths

Path A — Galactic Core handles auth

Use AuthenticationService (client.auth) for registration, login, password resets, OTP, and session refresh. Each successful registration also creates the customer record automatically — you don’t call CustomersService for creates. Best when:
  • You’re building a storefront from scratch and want the fastest path to a working “create account / sign in” UX.
  • You don’t already have an identity provider.
  • You’re happy with email/password + OTP + magic links as the auth surface.

Path B — Bring your own auth provider

Authenticate users in your own identity system (Auth0, Clerk, Cognito, Firebase Auth, NextAuth, your own SSO) and use CustomersService (client.customers) to provision the matching Galactic Core customer record from your backend. Best when:
  • You already use Auth0/Clerk/Cognito/Firebase/NextAuth/SSO and don’t want a second login system.
  • You need MFA flows, social logins, enterprise SSO, or other features your provider already does well.
  • Your buyers exist in an upstream system (ERP, CRM, accounting platform) and are projected into Galactic Core via integration.

The two BYO-auth modes: who verifies

Both modes let a shopper authenticated in your identity provider act on their own Galactic Core customer record, and both resolve to the same record by external_id. They differ in who verifies the identity-provider token, and therefore what you have to run: Use xExternalAuth when you already run a backend: it authenticates the shopper against your identity provider and signs a short-lived assertion { external_id, iat, exp }, which Galactic Core verifies with a signature check. Nothing leaves your side except the signed claim. Use xIdpToken when you’d rather not build the signing step — a thin or serverless storefront that only holds the identity provider’s client-side token. You send that raw token; Galactic Core forwards it to a verifier endpoint you register as an Auth provider, which validates it and returns the identity. Verification is fail-closed: if the verifier rejects the token or can’t be reached, the request is treated as signed-out, never signed-in. Registering the verifier is done through Custom Integrations; see the Auth provider capability on the Extensions page.

Decision matrix

You can mix both if you need to (e.g. start with Path A and migrate to Path B later). The customer record is the same row either way.

How Path B works end-to-end

The Galactic Core customer never has a Galactic Core JWT — they have your provider’s session, and your backend translates between the two.

external_id — the join key

external_id is an optional string on every customer record. It’s unique per store + environment, which means you can rely on (store_id, environment, external_id) as a stable lookup key for the lifetime of the customer.
Set it on createCustomer, update it on updateCustomer if the upstream identifier changes (e.g. provider migration).

Customer-self endpoints in Path B — the x-external-auth assertion

GET /v1/customers/{id} and PATCH /v1/customers/{id} are customer-self operations: the caller must prove they ARE that customer. In Path A this is a Galactic Core JWT (x-auth-token). In Path B the customer has no Galactic Core session — they have your session — so we accept an equivalent: an HMAC-signed assertion from your backend. Wire format:
The JSON claim:
Rules:
  • Signed with your store’s hmac_secret (the same secret used for orders/payments signing — find it under Integrations → API Keys).
  • exp - iat must be ≤ 300 seconds.
  • The external_id in the claim must resolve to a Galactic Core customer whose id matches the {id} in the path — otherwise 403.
  • Provide x-external-auth OR x-auth-token, not both. Both → 400.
Signing example (Node.js):
The assertion is signed in your backend, so the storefront never holds hmac_secret. The 300-second cap on exp - iat bounds how long a leaked assertion remains valid.

What Path B still doesn’t give you

  • No password reset, magic link, or OTP delivery. Those live in your identity provider.
  • No customer sessions. Galactic Core never issues a JWT to the customer; your provider does. The x-external-auth assertion is a per-request claim from your backend rather than a long-lived customer token.

What Path A doesn’t give you

  • No external identity reuse. Galactic Core mints its own JWTs; it doesn’t accept tokens issued by Auth0/Clerk/etc.
  • No social logins or enterprise SSO out of the box.

Summary

Pick Path A if you’re starting fresh and want a fast working storefront. Pick Path B if you already have an identity provider you’re not going to throw away. The Galactic Core commerce primitives (orders, cart, products, reviews, recommendations) work identically either way — only the customer-record provisioning differs.