AUTH GUIDE / Scenario guide
People, not customer companies
Give each person their own experience
Lia wants a private journal. She does not need a company, teammates or a team page.
A worked example with fictional people and products.
What this gives you
One shared operator account, private records for each person.
All consumers share the pinned account. Filtering only by account would mix their personal records.
Jump to the implementation recipe ↓See it happen
Follow Lia’s first day
- 01
Create a login
Lia creates her identity from Pocket Journal.
What happens behind this step
Enable public signup on the customer client and pin its ConsumerAccountId to an existing account.
- 02
Verify and sign in
She completes the required verification and sign-in steps.
What happens behind this step
A qualifying unseated customer receives the consumer projection. A live seat takes precedence if one exists.
- 03
See her own records
Pocket Journal opens Lia’s journal, not everybody’s journal.
What happens behind this step
The token contains the pinned account and Lia’s subject. Every private-record query must use both account and sub.
- 04
Come back tomorrow
Lia returns with the same identity and sees her own work.
What happens behind this step
Validate the session and current token context. Apply any additional app permission or entitlement checks before operations.
The handover to your app
A person, a context, a clear boundary.
Lia enters as consumer.
Use Pinned account + Lia’s subject to decide which records this request may reach. The product still checks what this person may do.
{
"sub": "lia-example-id",
"account": "pinned-operator-account-id",
"account_role": "consumer"
}Build this scenario
The recipe for your developer or agent.
Start with a registered customer app and the policy below. Then connect the specific access path for this scenario.
1. Register the app
Choose your organization and environment, register the HTTPS callback, then configure the client ID and server secret.
Registration request and prerequisites →2. Apply this access policy
{
"surface": "customer",
"allowSelfRegistration": true,
"signupGrantsAccount": false,
"consumerAccountId": "your-existing-operator-account-id"
}Choose the existing account to pin. Implement per-person record ownership using both account and sub. Do not offer the hosted customer team page to a consumer without a seat.
3. Connect hosted sign-in
The app starts login, auth handles the hosted screens, and the validated callback brings the person back to your product.
Complete .NET example →OIDC for other stacks →
4. Check the boundaries
All consumers share the pinned account. Filtering only by account would mix their personal records.
Acceptance checks →Branding and direct return →
Ready-to-use implementation brief
Give this brief and this page’s URL to your developer or agent. Replace the example account and callback values with the approved settings for your app.
Implement the give each person their own experience scenario for a new app using ALKEYON.
Use the customer client policy below in the selected environment.
Register the exact HTTPS app callback and keep confidential credentials server-side.
Choose the existing account to pin. Implement per-person record ownership using both account and sub. Do not offer the hosted customer team page to a consumer without a seat.
Keep the hosted login, verification and recovery flow tied to this app.
Validate tokens and enforce the tenant, account and operation boundaries.
Do not treat a successful login as a payment or membership grant.
Use the current SDK and OpenAPI contracts linked in this guide.
Verify permitted entry, refused entry, correct product return and revoked access.
Client policy:
{
"surface": "customer",
"allowSelfRegistration": true,
"signupGrantsAccount": false,
"consumerAccountId": "your-existing-operator-account-id"
}