SSO and enterprise
SAML, OIDC, SCIM provisioning and IP allowlisting.
Security → Enterprise holds identity and access features for larger deployments.
Single sign-on
SAML 2.0 and OIDC.
| Endpoints | /api/v1/auth/sso and /sso/callback |
| Rate limit | Its own bucket, separate from login |
| Role mapping | Group or attribute → AccelerUp role |
Role mapping writes users.role, which is the role that is actually
enforced — and it travels in the JWT. A role change through SSO therefore has
to invalidate existing sessions, the same as one made by hand. See
Roles.
SCIM 2.0
Provisioning and deprovisioning from your identity provider.
| Base | /scim/v2 |
| Auth | A token with the admin scope |
| Cookies | None — machine-to-machine, so no CSRF protection applies |
Deprovisioning is the valuable half. A leaver removed in the identity provider is removed here, which is exactly the thing that is otherwise forgotten.
IP allowlisting
Restrict API access to a set of CIDRs. Applied after authentication — an allowlisted address still needs a valid token.
Test from outside your network before enabling it, and keep a break-glass path. An allowlist that excludes your own admins is a lockout you cannot fix from the interface.
Two-factor enforcement
2FA can be required organisation-wide. Members without it must enrol before they can do anything else.
Session invalidation
Any role or membership change must call RegisterUserLogout. This applies to
SSO and SCIM changes as much as to manual ones — otherwise a demoted or removed
user keeps working until their token expires.
Related
Where this behaviour lives: backend/internal/handler/sso_handler.go, backend/internal/handler/enterprise_handler.go. If the code and this page disagree, the code is right — please fix the page.
Part of Security — Vulnerabilities, compliance, hardening and enterprise identity.