Skip to content

Sign-in & identity pools

Everyone who touches the platform signs in through the same identity provider — WorkOS — but not into one shared crowd. Identity is split into two pools, and the split is one of the platform's deliberate walls: a reader's account and an employee's account are different kinds of thing, with different sign-in rules, and they never meet.

  • Packt Login is the consumer pool: one account that works on every customer-facing surface Packt runs.
  • Packt Platform is the tenant pool: where Packt's own staff and partner businesses sign in, and where every machine credential lives.

This page explains who signs in where, what "one Packt account" really promises, and the extra checks that apply to people working inside the platform. What a signed-in caller can do is the authorisation story on Tenancy, trust & security; how a token is obtained and what it carries is Authentication.

Who signs in where

Surface Who signs in Pool
packtpub.com, the subscription site, and every vertical microsite Customers Packt Login
Author and creator tooling Authors — the same customer account Packt Login
Internal Packt tooling Packt staff, with their corporate (Entra ID) account Packt Platform
Partner consoles — e.g. the Content Lake A partner business's staff and systems Packt Platform 
flowchart TD
    subgraph PL["Packt Login — consumer pool"]
        C["Customers & authors<br/>self-registration, social login,<br/>optional company SSO for seats"]
    end
    subgraph PP["Packt Platform — tenant pool"]
        S["Packt staff<br/>via corporate Entra ID"]
        P["Partner businesses<br/>via their own identity provider"]
        M["Machine credentials<br/>services & integrations"]
    end
    PL -->|"tokens: always the packt tenant"| API["The platform"]
    PP -->|"tokens: the signed-in tenant"| API

Packt Login — one account for everything customer-facing

A customer has one Packt account, and it works everywhere: packtpub.com, the subscription site, and each of the vertical microsites as the fleet grows into the hundreds. Authors are customers too — the account an author uses to write with Packt is the same one they read with. There is no separate registration anywhere, and no site keeps its own password.

Behind the scenes, sign-in happens on one shared domain rather than on each site, which is what makes the promise cheap to keep: sign in on packtpub.com, then click sign-in on a microsite, and you are through without retyping anything. The calibration is deliberate — one account everywhere is the promise; zero clicks is not. Sites do not silently sign you in the moment you arrive; they complete a sign-in quickly when you ask.

Signing in is not the same as getting in

Any Packt account can sign in to the subscription site. Whether the signed-in customer can read anything there is an entitlement question, answered after authentication by the platform's access records. Identity proves who; entitlements decide access.

Packt Platform — staff and partner businesses

The tenant pool works differently, because everyone in it belongs to a business:

  • Packt staff never hold Packt-managed passwords. Employees sign in with their corporate Entra ID account, and joiners, movers and leavers flow through from corporate IT automatically. Someone who leaves the company loses platform access when their corporate account is disabled — no separate offboarding list to remember.
  • Partner businesses bring their own identity provider. A partner's IT admin connects their company's sign-in (and, if they want it, automatic user provisioning) through a self-serve portal — no Packt hand-holding required. A small partner without an identity provider can use passwords with enforced multi-factor authentication instead.
  • Every sign-in here is bound to one business. A token from this pool names the tenant its holder is acting in — which is exactly how the isolation described in Tenancy, trust & security reaches the credential. Staff who work across two of Packt's businesses hold a membership in each and switch explicitly; each switch produces a token for that business only.
  • All machine credentials live here. Services and partner integrations that act as themselves — with no person present — are registered in this pool, each bound to the one tenant it serves. The consumer pool contains no machine credentials at all.

An employee who is personally a Packt customer has two accounts — a staff identity and a private reading account — and that is deliberate: personal purchases and reading history do not belong to an employer login.

Why two pools rather than one

Three reasons, each worth the cost of running two:

  • Opposite sign-in postures. The consumer pool must welcome strangers: open registration, passwords, social login. The tenant pool should refuse them: corporate and partner sign-in only, with no password surface for the platform's most privileged users.
  • No accidental crossings. In a single pool, an employee signed in to internal tooling would drift onto packtpub.com already signed in as staff, muddling a work identity with a shopping one. Separate pools make that impossible rather than discouraged.
  • A smaller blast radius. The consumer pool faces the internet's usual account attacks. Because it holds no business tenants and no machine credentials, nothing minted from it can ever reach a business's estate — a consumer-side compromise is fenced off from tenant data by construction, the platform's usual fail-closed shape.

Permitted is not the same as permitted right now

For people working inside the platform, permissions are not the end of the story. An employee may hold every permission a task needs and still be refused, because the context is wrong: an unfamiliar device, an unexpected network, or too long since they last proved it's really them.

Those checks — conditional access — run where the corporate identity lives: Entra evaluates the device, the network and the sign-in each time an employee authenticates, and the platform keeps tenant-pool sessions short enough that those checks stay fresh. For genuinely sensitive actions, the platform goes one step further with step-up authentication: the tool asks the person to re-prove themselves if their last real sign-in is older than the action allows (minutes, not hours), and that re-proof runs the corporate checks again at that moment — so a laptop that fell out of compliance an hour ago is caught before the sensitive action, not after.

Customers never see any of this. Consumer surfaces face different risks — fraud and bots, not stolen laptops — and get different controls.

Companies that buy seats

A company that buys subscription seats for its people — say, a business buying a hundred seats for its engineers — is a customer, not a tenant. Its employees are ordinary Packt Login accounts, and the seats they occupy are platform records, exactly as described in Identity & organisations.

If the company wants its people to sign in with their corporate account, that works too — the company's identity provider is connected to the consumer pool, and each employee's company sign-in lands on their ordinary Packt account (or their existing one: an employee who already had a personal account under their work email keeps it, seat and all). Two rules keep this clean:

  • The connection signs people in; seats decide access. A company's sign-in may admit thousands of employees; only the hundred who claim a seat get what the seats grant.
  • Leaving the company releases the seat, never the account. The departing employee keeps their account and everything they bought personally; the seat returns to the company's pool.