AUTH GUIDE / Scenario guide

← All scenarios

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.

Studio Board
Leo
Welcome to Studio Board
Member · Maya’s existing customer account
The destination in this example. Your app supplies its own interface.

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

Maya invites LeoLeo acceptsThe team works together
  1. 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.

  2. 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.

  3. 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.

  4. 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.

IN EVERYDAY WORDS

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.

ILLUSTRATIVE CLAIMS
{
  "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
}

Want to see how the layers fit?

Follow the same person across workspaces, companies and roles.

Explore the architecture →