Skip to content

Identity & organisations

Almost everything in the operations ring starts with the same question: who is on the other end? An order needs a buyer. An entitlement needs a holder. An organisation subscription needs to know which seats belong to which people. Identity is the part of the platform that answers that question — the source of truth for customers and B2B organisations, and for the relationships between them.

Two things make the design easy to reason about. First, identity is a record-keeping concern here, not a login screen: the mechanics of signing in are delegated wholesale to WorkOS, as described in Authentication. Second, a customer identity is deliberately not a contract party — the authors and rights-holders Packt pays live in a separate registry inside Contracts. Both splits are explained below.

In design

Identity is still being designed as a standalone service. What is settled: authentication is delegated to WorkOS, and platform services see only Bearer tokens carrying tenant claims (Authentication, Tenancy & security); orders create entitlements held against a customer identity; and customer identities are kept apart from contract parties, which live in the Contracts agent registry. What is not settled: the service boundary and APIs, event names, organisation lifecycle mechanics (invitations, seat management, offboarding), and the migration path from today's systems. Treat the shape below as direction, not shipped behaviour.

Customers and organisations are first-class records

The platform models two kinds of identity, and the relationship between them is where most of the interesting behaviour lives.

A customer is a person: someone who buys an ebook, holds a subscription, or reads through an AI surface. A B2B organisation is a company or team that holds a relationship with Packt in its own right — typically a subscription with a number of seats that its members occupy. An organisation is not a folder of customers; it is a record with its own entitlements, its own billing relationship, and its own administrators.

The relationships tie the two together:

  • a customer can be a member of an organisation, occupying one of its seats;
  • an organisation's entitlements can apply to its members — a team subscription entitles every seat-holder without each person buying anything;
  • membership can change — people join and leave — without disturbing either the person's own purchases or the organisation's subscription.

That last point is the reason identity is its own concern rather than a column on an order. A customer who leaves a company keeps everything they bought personally and loses what the company's seats granted; the records that make that clean are identity records.

Sign-in is someone else's job

Identity is not a password store. Authentication — sign-in, SSO, multi-factor, credential storage — is delegated to WorkOS, a provider whose entire job is doing those things well. What the platform's services see is the outcome: a Bearer token carrying tenant claims, checked on every request, as covered in Authentication and Tenancy & security.

The split keeps the interesting problems local. WorkOS answers is this really them? once, at the front door. Identity answers the questions that come after: which customer record is this token about, which organisation do they belong to, and which seats does that organisation hold? The front door itself is Packt Login — one customer account that works on every customer-facing surface, from packtpub.com to each vertical microsite to the author tooling (Sign-in & identity pools).

Enterprise SSO — a B2B organisation connecting its own identity provider so its staff sign in with their company credentials — lands on the WorkOS side of the line, while the seats those people occupy remain platform records. Two rules keep the two sides honest: the company's sign-in may admit far more people than it bought seats for, and only seat-holders get what the seats grant; and when someone leaves the company, the seat is released but the person's account — and everything they bought personally — survives.

What an identity connects to

An identity on its own does nothing. Its value is in what hangs off it:

Connection What it answers Where it is described
Entitlements What may this customer access? Orders & entitlements
Orders What did this customer buy? Orders & entitlements
Usage What was served and consumed? How AI use is tracked

Entitlements are the durable records that a purchase or subscription creates: this customer (or this organisation's seats) may access this product. They are held against identity, which is exactly why identity has to be a stable, first-class record — entitlements outlive checkouts, renewals, and job changes.

Orders are the transactions themselves: what was bought, from which catalogue, at what price. An order needs a buyer, and the buyer is an identity record — which is what lets a refund find the entitlement it must revoke.

Usage is recorded with deliberate restraint. When content is served — including through AI surfaces — the platform records facts about the content: which resources appeared, from which version, whether they were cited, under which rights basis. Those events exist to measure what content earned, feeding the royalty model — not to build a dossier on the reader. Identity appears where it must (an entitlement check knows who asked; an order knows who bought), and behavioural measurement aggregates into per-resource performance signals in Analytics rather than per-person profiles.

A customer is not a contract party

The platform draws a hard line between the people who buy content and the people who are paid for it — even when they are the same human being.

Customers and organisations live here, in Identity. Authors, co-authors, technical reviewers, agencies, and rights-holders live in the agent registry inside Contracts, because what matters about them is contractual: which agreements name them, what royalty terms they hold, how their splits resolve. An author who also holds a Packt subscription is two records on purpose — a customer identity that explains what they may read, and a contract party that explains what they are owed. Nothing about their reading account can leak into, or interfere with, their royalty statement.

The split mirrors the platform's general habit of separating the record from the interpretation: identity records who someone is to the storefront; contracts record who someone is to the money.

Signals this service will publish

Like every service on the platform, Identity will announce its state changes as events, following the platform's event grammar. The names below are illustrative, not yet claimed — none of them exists yet:

Illustrative event What it would announce
platform.users.customer.v1.created A customer record was created
platform.users.organisation.v1.created A B2B organisation was registered
platform.users.membership.v1.changed A customer joined or left an org

A searchable users estate — letting operational tools find customers and organisations the way search already finds content — is planned on the same pattern as the existing content and product estates.