AUTH GUIDE / Scenario guide
An owner controls the guest list
Invite a known team or closed group
Maya already runs a workspace in Studio Board. She invites Leo to work there.
A worked example with fictional people and products.
What this gives you
A person joins an existing customer account by accepting an invitation.
This example is a product’s customer team. Your organization’s administration console uses a separate platform client.
Jump to the implementation recipe ↓See it happen
Follow Leo’s first day
- 01
Invite the person
Maya sends an invitation from the customer team page.
What happens behind this step
Maya must be the live account owner. Keep organization staff invitations separate from customer account invitations.
- 02
Accept the invitation
Leo accepts using his existing login or establishes one through the hosted journey.
What happens behind this step
The intended recipient must accept a valid invitation. Sending the invitation alone does not create current access.
- 03
Enter the team’s account
Leo arrives as a member of Maya’s existing account.
What happens behind this step
Validate the customer token and selected account. No new customer account is created by this invitation.
- 04
Respect a later removal
If Maya removes Leo, the app ends access according to its session checks.
What happens behind this step
Do not recreate the seat from historical acceptance. Refresh/session revalidation and bearer expiry define the enforcement window.
The handover to your app
A person, a context, a clear boundary.
Leo enters as member.
Use Maya’s existing customer account to decide which records this request may reach. The product still checks what this person may do.
{
"sub": "leo-example-id",
"account": "selected-company-id",
"account_role": "member"
}Decoded example only. A real token needs signature, issuer, audience, lifetime and context validation.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
}Start with an existing account and a live owner. Use consent-based account invitations and enforce the app’s own member permissions.
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
This example is a product’s customer team. Your organization’s administration console uses a separate platform client.
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 invite a known team or closed group 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.
Start with an existing account and a live owner. Use consent-based account invitations and enforce the app’s own member permissions.
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
}