What happens when you open a module
The link goes straight to the module — app.erp.io/crm, for instance — not through the shell.
If it has one, you are already in and nothing else happens. This is the common case and it is one navigation.
Same origin, so the cookie is there. Seeing it, the module knows the suite has already authenticated you and redirects to the hand-off itself.
Short-lived, signed, naming exactly one module as its audience and carrying your identity and your current organisation.
It fetches the shell's public keys, checks the signature, the audience and the issuer, mirrors you into its own user table, and issues a session scoped to itself.
The whole sequence is invisible when it works. What you see is a page.
What the module checks
| Check | Rejects |
|---|---|
| Signature against the shell JWKS | A forged or tampered token. |
| Issuer | A token minted by something that is not our shell. |
| Audience | A token minted for a different module — CRM will not accept a token issued for Accounting. |
| Expiry | A replayed token. They are short-lived by design. |
| Organisation | A token for an organisation the module is not willing to provision. |
Each of those was tested end to end before the module was allowed to trust the mechanism: no token, a bogus token, a token minted for a different module, an expired one, and a valid one for an organisation outside the allowed set are all refused; a valid one for your own tenancy signs you in.
Why a module might still ask you to sign in
Two modules — Accounting and PLM — do not accept the hand-off token today and sign you in themselves. Accounting reads the shell session cookie directly, which works because it shares the origin. If you land on a module's own sign-in form having already signed in to the shell, that is either one of those two, or a genuine fault worth reporting.
A module running its own authentication library can own the URL the hand-off token is delivered to. Delivering the token there gets it read as an unknown login provider, and the customer's first sight of the product is an error page. CRM and Marketing therefore take the token on their own dedicated paths rather than the default. If a module ever sends you to a configuration error immediately after sign-in, this is the shape of the problem.
Signing in with your own identity provider
Google sign-in is available to everyone. SAML and OIDC against your own identity provider — Okta, Entra, Google Workspace as an IdP rather than a social login — are part of the Scale plan and are configured by us rather than self-serve. Contact [email protected] with your metadata URL.
Sign in
One account, every module
What this does not do
Even with SAML, users are not provisioned or de-provisioned automatically. Invitations and removals stay manual.
One IdP for the organisation, not one per application.
You land in the shell and pick from the rail.
Questions
How long is a module session good for?
The module owns its own session lifetime. Revoking your shell sessions is the reliable way to end them all.
Can I use erp.io as an identity provider for something else?
No. The token model is inbound only, scoped to our own modules.
Does signing out of one module sign me out of all of them?
Signing out of the shell does. Signing out inside a module clears that module.