Kinde B2B

Produces a tenant contract for isolation, partitioning, active/no-tenant behavior, and tenant credentials. Conditional annexes carry identity, authorization, machine-access, and control-plane decisions only when those branches are in scope. Owning skills consume this contract rather than redefining its tenancy invariants.

Stance

Treat the run as design-only until the user asks to implement. Inspect the application stack and actively invoke the loaded framework adapter for framework work. If no adapter is available, mark that implementation handoff blocked; keep the tenant contract as the completed design artifact.

Dated sources and first-party conflicts live in REFERENCES.md. Read it before relying on a product claim that is not already recorded in a sibling file, and whenever two official pages disagree.

Guardrails

• Tenant source. Retain verified access-token org_code by default. An intentional token workflow removal requires the contract to name a trusted server-side tenant/membership resolver and a no-membership discriminator; otherwise tenant implementation is blocked. Client hints never qualify. Details: TENANCY.md.
• Exact API audience. Register every protected product API, request its audience, and verify the exact aud before authorization. Details: AUTHORIZATION.md.
• Permission and scope split. User requests use verified permission keys; M2M uses granted scope; organization API keys use verification-response scopes. Details: AUTHORIZATION.md.
• Credential class. A global M2M credential and a user API key without contract-defined tenant resolution are not tenant credentials. Details: MACHINE-ACCESS.md.

Read map