AUTH GUIDE / Scenario guide
Controlled entry, personal records
Admit customers without company workspaces
Pocket Journal controls who gets in. Lia uses her own records without creating a company workspace.
A worked example with fictional people and products.
What this gives you
An admitted customer enters as consumer; payment is a separate check.
A closed signup form is not a payment gate. A paid consumer product needs an explicit entitlement decision.
Jump to the implementation recipe ↓See it happen
Follow Lia’s first day
- 01
Control the entry
The product admits Lia through its supported onboarding flow.
What happens behind this step
Public signup is closed. Configure and verify the onboarding path that establishes the customer identity.
- 02
Sign in
Lia uses that identity to enter Pocket Journal.
What happens behind this step
An eligible unseated customer receives the consumer projection for the pinned account.
- 03
Check paid access if needed
If the product sells access, it checks Lia’s entitlement before opening paid features.
What happens behind this step
Closing signup and pinning an account do not prove payment. The product must implement the intended entitlement check.
- 04
Keep her records private
Lia sees only her own journal.
What happens behind this step
Scope private data to the pinned account and validated subject. Consumers do not gain a seat or team-management rights.
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": false,
"signupGrantsAccount": false,
"consumerAccountId": "your-existing-operator-account-id"
}Define the supported onboarding and entitlement path. Set the consumer pin and isolate personal records by subject as well as account.
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
A closed signup form is not a payment gate. A paid consumer product needs an explicit entitlement decision.
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 admit customers without company workspaces 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.
Define the supported onboarding and entitlement path. Set the consumer pin and isolate personal records by subject as well as account.
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": false,
"signupGrantsAccount": false,
"consumerAccountId": "your-existing-operator-account-id"
}