Sign-in and credentials
Plat5 doesn’t run sign-in. Your identity provider does, and Plat5 accepts its tokens. Plat5 adds API keys and sessions on top.
Sign-in
Section titled “Sign-in”Any OIDC provider works: Auth0, Okta, Keycloak, Clerk, or Plat5 Auth, an optional email-code provider you can run yourself. The gateway checks the provider’s JWTs against its published keys. See Bring your identity provider.
A sign-in token calls user routes: the person’s own profile, their organizations, their personal keys.
Credentials
Section titled “Credentials”| Credential | Belongs to | Calls | Lifetime |
|---|---|---|---|
| Sign-in token (JWT) | A person | user routes |
Your identity provider’s |
| Personal API key | A person | user routes |
Until revoked |
| Member API key | A member (person or service account) | organization and member routes |
Until revoked, or the member is removed |
| Session | A person’s membership in one organization | organization and member routes |
One hour |
Send a JWT as Authorization: Bearer … and keys and sessions as X-API-Key: …. Using the wrong kind for a route is a 401.
A credential always has exactly its member’s permissions. There are no narrower keys: to give an integration less, give it a service account with a smaller role.
Sessions
Section titled “Sessions”A web app signs a person in with your identity provider, then opens a session in the organization they pick:
POST /user/organizations/{organization_id}/sessionAuthorization: Bearer <user token>The response holds the session token and the member’s role and permission labels, so the app can show or hide controls. The gateway still decides.
Key format
Section titled “Key format”Keys and sessions look like acme-k-2-… and acme-s-2-…. The first part is your brand (APIKEY_BRAND), so you can register the pattern with secret scanners. k is a key, which is revoked if it leaks; s is a session, which expires.
More: identity.md, idp-contract.md.