Single sign-on (SSO)
Let your team sign in with your identity provider over SAML or OIDC, so access follows joiners and leavers.
SSO lets people sign in with your existing identity provider, so access follows your normal joiner and leaver process instead of a separate list.
OIDC
| Field | What it is |
|---|---|
clientId |
The client Glowo authenticates as |
clientSecret |
Its secret |
authorizationUrl |
Where users are sent to authorise |
tokenUrl |
Where Glowo exchanges the code |
userInfoUrl |
Where Glowo reads the profile |
scopes |
Scopes to request |
Any IdP that speaks OIDC works — Okta, Entra ID, Google Workspace, Auth0, Keycloak.
SAML 2.0
| Field | What it is |
|---|---|
entryPoint |
Your IdP’s sign-on URL, where Glowo sends people to authenticate |
certificate |
Your IdP’s signing certificate, in PEM form |
issuer |
Your IdP’s entity ID |
Glowo gives you two values in return, shown on the SSO settings page and in the setup wizard. Paste them into your IdP:
| Value | Your IdP calls it |
|---|---|
| Assertion Consumer Service URL | ACS URL, Reply URL, or Single sign-on URL |
| Service Provider Entity ID | Audience, Audience URI, or Entity ID |
Both are derived from your Glowo API address, so read them from the product rather than typing them from memory.
What Glowo expects of an assertion
Sign-in always starts at Glowo, never at your IdP. Turn IdP-initiated SSO off — an unsolicited assertion is refused, because there is no request of ours for it to answer.
Assertions must be signed, must name Glowo’s entity ID as the audience, must be addressed to the ACS URL above, and must carry a validity window. Each one can be used once. Single logout is not supported yet: signing out of Glowo does not sign you out of your IdP.
The email address in the assertion has to be inside the domain you verified —
NameID is used when no email attribute is present.
Domain-based detection
SSO can be tied to an email domain, so someone entering an address at that domain is sent to your IdP automatically rather than having to know to pick “sign in with SSO”.
Who SSO can sign in
SSO authenticates people who are already in your workspace. It does not add them to it.
Someone signing in through your IdP must already be a member — invited, and signed up — or the sign-in is refused. So the order is: invite the person, they accept, and from then on they sign in with your IdP.
This is deliberate. Membership carries a role and counts against your plan’s seats, and neither of those is a decision an identity provider should be making on your behalf.
Rolling it out
Configure the IdP
Create an application in your IdP. For OIDC, give it Glowo’s redirect URI; for SAML, give it Glowo’s ACS URL and entity ID.
Configure Glowo
Enter the fields above.
Test with one account first
Preferably not the owner’s. A misconfigured IdP that you cannot sign in through is much easier to fix with a working session in another browser.
Invite the team
Then enable domain-based detection. Everyone signing in through SSO needs a Glowo membership first — see above.