Integration
Okta single sign-on document management
Okta acts as the identity provider for DocumentMS over OIDC. Group claims in the token drive role assignment on each sign-in, so a user deactivated in Okta cannot authenticate, and role changes made in Okta take effect at their next session.
What this connection does
Okta acts as the identity provider for DocumentMS over OIDC. Group claims in the token drive role assignment on each sign-in, so a user deactivated in Okta cannot authenticate and a role change in Okta takes effect at their next session.
For organisations that have consolidated identity governance in Okta, this means DocumentMS access is reviewed and revoked in the same place as everything else — rather than being a separate console that access reviews forget.
What you need on your side
- An Okta tenant and an administrator able to create an OIDC application
- Okta groups corresponding to the DocumentMS roles you intend to use
- A group claim configured on the authorisation server
Setting it up
Step 1: Create the OIDC application
Create a web application in Okta with the DocumentMS redirect URI, and note the client credentials.
Step 2: Add a groups claim
Configure the authorisation server to include group membership in the ID token.
Step 3: Map groups to roles
Map each Okta group to a DocumentMS role, starting with the most restrictive.
Step 4: Verify and revoke
Sign in as a test user, confirm the role, then deactivate in Okta and confirm access is refused.
Limits worth knowing before you rely on it
- Role changes apply at next sign-in; deactivate the user in Okta for immediate revocation rather than changing group membership
- Group claim size limits apply on some Okta configurations — use a filtered claim expression rather than returning every group
- SCIM 2.0 provisioning is supported alongside SSO, so Okta remains the source of truth for account lifecycle as well as for authentication — a deactivation in Okta removes access here without a second action
Last reviewed: 2026-09-01