OpenID Connect · OAuth 2.0 · SAML 2.0
One identity provider for every organisation you serve.
Athang SSO is a multi-tenant OpenID Connect and SAML identity provider. Every issuer, session cookie, signing key and user record belongs to exactly one organisation — so a single deployment serves all of them, and none of them can see each other.
- Protocols
- OIDC & SAML
- Provisioning
- SCIM 2.0
Preview - Directories
- LDAP & AD
Preview - Isolation
- Per tenant
By design
We sign people in. Your app decides what they can do.
Athang SSO answers one question — who is this? The six roles here govern this console only. Permissions inside your application stay in your application, checked at request time.
- Console roles never reach your app
- Your app keeps its own roles and permissions
- Checked live on every request — nothing stale in a token
If SSO owned your permissions
- One role hierarchy has to fit every app — who outranks whom, what inherits what — and a single tree gets it wrong for someone
- Remove a role and the token issued a minute ago still carries it — until it expires
- Every app shares one role list, so “admin” in Finance and “admin” in Analytics collide
- A new feature in one app means changing the identity provider first, and rolling every app
- Tokens swell with claims most apps never read, on every single request
- The provider cannot see ownership, projects or rows — the checks your app actually makes
- One misconfiguration over-grants or locks out every application at once
Because your app owns them
- Each app draws its own hierarchy — flat, nested or per-team — without negotiating it with any other app
- A change takes effect on the next request — nothing to wait out, nothing to revoke
- Roles named in your app’s own language, as coarse or as fine as the feature needs
- Ship on your own schedule — no ticket to the identity team, no cross-app rollout
- Small, standard tokens that any OpenID Connect library reads unchanged
- The permission check sits next to the data it protects, with all the context it needs
- A mistake stays inside one app instead of spreading to all of them
Identity is the one thing worth centralising — who someone is, and whether they are still allowed in. What they may do has always been your application’s business, and it stays that way.
How it works
Three steps, and no proprietary client library.
Athang SSO speaks the standards your framework already implements. If your language has an OpenID Connect library, the integration is configuration rather than code.
Register your application
Add your app in the admin console and get a client ID, a redirect URI and — for a confidential client — a secret shown exactly once. SAML applications register the same way, with an entity ID and an assertion consumer service URL.
Send people here to sign in
Your app redirects to the authorization endpoint. Athang SSO shows that organisation’s own branded sign-in screen, with its own password policy and its own federated identity providers, and handles the whole exchange.
Get standard tokens back
You receive an ID token and an access token signed with RS256, verifiable against the published JWKS for that organisation’s issuer. Any conformant OpenID Connect library will do — there is nothing proprietary to integrate against.
Features
Everything an identity provider owes you, already built.
Not a roadmap. Each item below is implemented and running in the product today. The ones marked Preview are newer than the rest: they work, and their configuration may still change between releases.
Standards-based single sign-on
A full OpenID Connect provider: the OAuth 2.0 authorization code flow with PKCE, refresh-token rotation, and the client credentials grant for service-to-service calls. Tokens are signed with RS256 and every organisation publishes its own discovery document and JWKS.
SAML 2.0, in both directions
Preview Act as the identity provider for SAML applications — signed assertions, published metadata, configurable name ID and attribute release. Or act as the service provider and verify assertions from an upstream identity provider, with certificate rotation that overlaps so nothing breaks mid-swap.
Federate the identity people already have
Let each organisation bring its own Google Workspace, Microsoft Entra ID, or any conformant OpenID Connect or SAML provider — with its own credentials, not yours. Accounts can be created on first sign-in or linked to an existing user by email address, per provider.
Directories and automatic provisioning
Preview Authenticate straight against LDAP or Active Directory over LDAPS or StartTLS, with a connection test in the console before you save. Or let an upstream directory push accounts in over SCIM 2.0 — create, read, update, patch and delete on users, filtering included.
Multi-tenant down to the database row
Each organisation is a tenant identified by a segment of the URL, with its own issuer, its own session cookie and its own sign-in screens. Isolation is enforced by composite foreign keys in the database, so a query that crosses a tenant boundary is not something the schema can express.
Roles, keys and session control
Six roles govern the Athang SSO console itself — full administration, day-to-day operation, read-only audit and end-user self-service — and stop at that boundary: what a signed-in user can do inside your application is your application’s own roles and permissions to define. Sessions are held in Redis and an administrator can list them and revoke one device or every device for a user. API keys are scoped, shown once, and revocable.
An audit trail you did not have to build
Every write is recorded with its before and after state, credentials redacted, scoped to the tenant it happened in. Sign-in attempts are logged whatever the outcome, with the address and user agent. Password resets are single-use and short-lived, and repeated failures lock the account.
Every organisation looks like itself
Logo, brand colour, headline, supporting text and support address are set per tenant and applied to that tenant’s sign-in screens — including the browser chrome. The cached brand is applied before the page renders, so nobody watches someone else’s colour repaint into theirs.
Standards
What is supported, stated plainly.
A short list you can check against your requirements before you talk to anyone. If something is missing from it, it is missing from the product. Anything marked Preview is built and working, but still settling — worth knowing if you are planning a rollout around it.
OpenID Connect and OAuth 2.0
- Authorization code flow with PKCE (S256)
- Refresh-token rotation
- Client credentials grant
- RS256 signing with a published JWKS
- Discovery document per tenant issuer
- Public and confidential clients, exact-match redirect URIs
- Front-channel logout and session check
SAML 2.0 Preview
- Identity provider: signed assertions and responses
- Published IdP metadata per tenant
- Name ID from email, username or user ID
- Configurable attribute release
- Service provider: verify upstream assertions
- Signed authentication requests
- Overlapping certificate rotation
Federation and directories
- Google Workspace
- Microsoft Entra ID
- Any conformant OpenID Connect provider
- Any conformant SAML 2.0 provider
Preview - LDAP and Active Directory over LDAPS or StartTLS
Preview - SCIM 2.0 inbound provisioning for users
Preview - Per-provider account creation and email linking
Isolation and operations
- One issuer, session cookie and sign-in surface per tenant
- Tenant isolation enforced by database constraints
- Six console roles, from administration to self-service — your apps keep their own
- Scoped API keys, shown once and revocable
- Audit log with before and after state
- Sign-in event log with address and user agent
- Health endpoints, Kubernetes manifests, autoscaling
Ready when you are
Already set up here? Enter your organisation's sign-in name and you will land on your own branded sign-in screen. New to Athang SSO? Create your organisation in minutes — verify your email, name it, done.