Authentication and SSO
One sign-in for your staff and your clients — Microsoft Entra ID, Google Workspace, or a password with a second factor, with directory provisioning that creates and removes accounts for you.
The problem
Onboarding a new hire means creating them in the directory, then again in the service desk, then again in the client’s tenant. Offboarding means remembering all three at 4pm on a Friday. Six months later nobody can say for certain whether the contractor who left in March still has a login, and the only evidence either way is a spreadsheet. Meanwhile the security questionnaire from your largest client asks whether you enforce SSO and MFA, and the honest answer is “we ask people to”.
What Solidlio does about it
Solidlio treats one person as one identity across every organization they belong to, and lets each organization decide how that person proves who they are. Connect Microsoft Entra ID or Google Workspace, and members sign in with the account they already have. Turn on enforcement and password sign-in stops working for that organization — retroactively, so sessions that were already open die at their next refresh rather than at a mass logout. Connect SCIM and your directory becomes the source of truth: it creates the account, sets the role from group membership, and deactivating there revokes the session here. Every session records whether it came from your directory or from a password, so enforcement holds through token refresh and organization switching instead of being walked around by either.
Capabilities
| Capability | What it does |
|---|---|
| Entra ID and Google SSO | Single sign-on per organization, with the client secret encrypted at rest and never read back |
| Enforced SSO | Password sign-in refused for members, with platform administrator as the documented break-glass |
| Anti-lockout guard | Enforcement is refused unless a working browser-flow provider is already enabled |
| SSO discovery from email | A work email surfaces its organization’s providers without revealing whether the account exists |
| SCIM provisioning | Users and groups pushed from Entra ID or Okta, scoped to exactly one organization by its token |
| Directory-group roles | A group maps to one of your own custom roles; every member is reconciled on the spot |
| Just-in-time provisioning | First-time SSO sign-in creates the account, at a role you choose, only for domains you allowlist |
| Domain auto-join | A DNS-TXT-verified email domain adds anyone on it to your organization at the role you set |
| Authenticator-app two-factor | Authenticator-app codes with ten single-use recovery codes, enforceable per person |
| MFA through SSO | An SSO sign-in that meets an MFA requirement finishes as an SSO session, not a password one |
| Connection test | Verifies tenant and credentials against the identity provider without provisioning or signing in |
| Session revocation | One call kills every session for a person, including the refresh token behind it |
| Magic-link sign-in | Single-use 15-minute email link, stored hashed, for people with no password |
Built for MSPs and their clients
A managed client’s directory belongs to the client, not to you. Solidlio keeps both sides administering their own identity provider without either inheriting the other’s.
| Organization | MSP | |
|---|---|---|
| Identity provider | Configures its own Entra or Google tenant | Configures its own, separately |
| Enforcement | Decides whether its members may still use a password | Decides the same for its own staff, independently |
| Directory push | Issues its own SCIM token, bound to its organization alone | Issues its own; a client’s token can never read or write MSP identities |
| New accounts | Sets the role just-in-time and SCIM provisioning mint | Same, clamped to roles legal for an MSP’s own organization |
| Break-glass | An org admin can always turn enforcement back off | Platform staff can sign in with a password whatever any tenant enforces |
| Entitlement | Enterprise plan | A managed client with no plan of its own inherits the MSP’s |
An organization’s SSO provider can only ever resolve to a person that organization is entitled to — an active member, or an address on a domain that provider explicitly allowlisted. One tenant’s identity provider cannot claim another tenant’s account.
How it works
- Register Solidlio in your directory using the redirect URI shown in the setup wizard, and paste back the client id, secret and tenant id.
- Test the connection. Solidlio checks that single sign-on discovery resolves for the tenant and that the credentials are accepted — without provisioning anyone.
- Choose who may join. Auto-provisioning on or off, the role new accounts receive, and the email domains this provider is allowed to claim.
- Members sign in. They enter a work email, Solidlio shows the buttons that organization has configured, and the round trip to the directory returns them with a 15-minute access token and a 7-day refresh token.
- Add a second factor where you need one: mark people as MFA-required and sign-in redirects them to enrollment before it will issue a session — through SSO as well as through a password.
- Turn on enforcement when you are ready. Password sign-in stops for that organization, including on refresh, magic link and organization switching.
- Connect SCIM so the directory creates, updates and deactivates accounts, and group membership drives roles.
Compliance and audit
Every sign-in attempt against a known account is written to login history with its outcome, the method used, whether a second factor was involved, the IP address, the user agent and the geolocation resolved from that address. Failures record why. Sessions are individually recorded with device, browser, operating system and location, and each carries the id of the token it issued, so “which sessions were live on the 14th” is answerable.
Enrollment, verification, failed verification, recovery-code use and MFA removal are each recorded separately, as are password reset requests and completions. Sessions minted through single sign-on are marked as such and carry the organizations whose directory vouched for them, so an audit can distinguish a directory-authenticated session from a password one after the fact.
Secrets are never recoverable from the product: OAuth client secrets are encrypted at rest and reads report only whether one exists; authenticator-app secrets are encrypted at rest; SCIM tokens, magic links, password-reset tokens and recovery codes are stored only as hashes, and the SCIM token is displayed exactly once.
Editions
ssoEnabled is the gate. Directory single sign-on, enforcement and SCIM provisioning are Enterprise-only in both plan families; everything else is available on every tier including Free.
| Capability | Free | Starter / Essentials | Growth / Professional | Scale / Business | Enterprise |
|---|---|---|---|---|---|
| Password sign-in | ● | ● | ● | ● | ● |
| Magic-link sign-in | ● | ● | ● | ● | ● |
| Authenticator-app two-factor and recovery codes | ● | ● | ● | ● | ● |
| Verified-domain auto-join | ● | ● | ● | ● | ● |
| Session history and revocation | ● | ● | ● | ● | ● |
| Entra ID / Google single sign-on | — | — | — | — | ● |
| Enforced SSO | — | — | — | — | ● |
| SCIM directory provisioning | — | — | — | — | ● |
| Directory-group role mapping | — | — | — | — | ● |
Downgrading never breaks a working configuration: the gate applies to creating a provider and to re-enabling a disabled one, not to signing in through one that is already live.
Integrations
Microsoft Entra ID — Single sign-on and SCIM inbound provisioning. Google Workspace — Single sign-on. Okta — SCIM inbound provisioning. Apple Sign In — the Solidlio iOS app only.
Your directory already knows who works here — this is how Solidlio finds out.