SSO and account linking

TechTur platforms let their signed-in users open POS without registering again, using one-time launch tickets. This is a server-to-server handshake followed by a browser redirect; no reusable token ever appears in a URL.

Flow

Seller in RekaDijo ──click "POS & Store Operations"──▶ RekaDijo server
RekaDijo server ──POST /api/v1/platform/launch-tickets (client-credentials token, platform:identity)──▶ POS
POS ──{ code, launchUrl, expiresAt (5 min) }──▶ RekaDijo server
RekaDijo server ──302 launchUrl──▶ seller's browser ──GET /launch?code=…──▶ POS
POS: redeem code once → identify user → resolve business → session cookie

Minting a ticket

const { launchUrl } = await pos.platform.createLaunchTicket({
  externalUserId: user.id,            // your stable user id — the identity key
  email: user.email,                  // display / new-account email only
  displayName: `${user.firstName} ${user.lastName}`,
  externalBusinessId: business.id,    // your business id (optional)
  businessName: business.name,
  businessRole: "owner",              // owner | manager | staff — as on your platform
  returnUrl: "https://rekadijo.techtursolutions.com/dashboard/vendor",
});
return redirect(launchUrl);

Mint tickets only for users your platform has authenticated in this request, and only with roles your platform actually grants them. returnUrl must be on your platform's registered website.

What POS does with the code

1. The code is valid for 5 minutes and once.
2. Identity. POS looks up a FederatedIdentity (platform, externalUserId).
   • Found → that POS user is signed in.
   • Not found and no POS account uses the email → a new POS account is created and linked (no password; the person can set one later via Forgot password).
   • Not found but a POS account already uses that email → POS does not link automatically. The person is asked to sign in to that account and confirm the link. Matching email addresses never establish identity.
3. Business.
   • Linked (platform, externalBusinessId) → POS ensures a membership with the role mapped from businessRole (owner → Business Owner, manager → Store Manager, staff → Cashier). A suspended membership is not reactivated.
   • Not linked and businessRole = owner → the owner sees a consent screen ("Set up POS for …: what will be shared"). On consent POS creates the business, the link, and a connection granting your application its approved (non-platform) scopes on that business.
   • Not linked and not owner → refused: the owner must open POS first.

Account linking without SSO

A platform that cannot mint tickets yet can use OAuth: the business owner connects your application to their existing POS business from your settings page. You then hold a per-business token. See Authentication.

Upgrade path to full OIDC

Launch tickets are the current mechanism. A future OIDC provider on POS (for platforms that delegate sign-in entirely) is on the roadmap; it will reuse the same FederatedIdentity records.