Olyron Identity
Every token knows the org and the role.
Accounts holds the session. The access token it issues carries the active organization and the member’s role, so every product in the suite enforces the same tenant without asking anyone to sign in twice.
Password · Google · Sign-in link
{ "iss": "https://accounts.olyron.com/auth/v1", "sub": "3f6a1c92-…-1e2af5d70b68", "email": "avery@example.health", "role": "authenticated", "exp": 1767225600,Added by Olyron: "olyron_org_id": "b41d07e5-…-9a2c6f80d113",Added by Olyron: "olyron_role": "admin"}The hook reads app_metadata.active_org_id, confirms the person still holds a membership in that organization, and falls back to their earliest one when they do not. A revoked membership drops the claim rather than trusting the stored value.
What apps inherit
Integrate once
Every Olyron product reads the same person, organization and role instead of rebuilding authentication a fifth time.
What Accounts holds
Hosted authentication
Password, Google, and emailed sign-in links, on a session that is created and refreshed on Accounts and nowhere else.
/auth/v1/token
Organizations and invites
An organization has a slug and a member list. Invite by email, accept from the link, and switch between the orgs a person belongs to.
org_memberships
Role-based access
5 roles, stored once on the membership and read everywhere. Change someone's role and every product sees it on their next token.
owner · admin · member · billing · readonly
What another app inherits
Org-aware token claims
The active organization and the role ride on the access token, so an API can enforce the tenant without keeping its own copy of your org chart.
olyron_org_id · olyron_role
Sign in with Olyron
Register a client with its allowed redirect URIs, send people to authorize, exchange the one-time code server-side. Third-party clients always meet the consent screen first.
/sso/consent
Cross-app SSO
A first-party desk skips consent and is handed a short-lived code instead, so moving between suite products never asks for a second sign-in.
/api/sso/authorize
The path
From sign-in to an API call
Four messages. Only the first one involves a password, and only the last one leaves Olyron.
01The person sends to Olyron Accounts
Sign in, once
Password, Google, or an emailed sign-in link. The session cookie is set on Accounts and stays there — no product app ever handles the credential.
POST /auth/v1/token
02Olyron Accounts sends to Postgres
Resolve the active organization
The access-token hook reads app_metadata.active_org_id and re-checks it against org_memberships, falling back to the person's earliest membership when the stored one no longer holds.
custom_access_token_hook
03Postgres sends to Olyron Accounts
Return the membership
One row: the organization and the role on it. Five roles exist — owner, admin, member, billing, readonly — and they live on the membership, not on each app.
olyron_org_id + olyron_role
04Olyron Accounts sends to Your app
Mint the claims and hand over
A first-party desk is handed a one-time code straight back. A third-party client goes through the consent screen first, and only then gets a code to exchange server-side.
?code=… → access_token
Next step
Put Olyron in front of the next launch
Your app stops storing passwords, stops modelling roles, and starts reading the organization straight off the token.
- Create an account and open an organization.
- Register your app and its allowed redirect URIs.
- Send people to sign in with Olyron.