authentik SCIM provisioning to applications

How authentik SCIM provisioning keeps SaaS accounts in step with your directory

authentik's SCIM provider pushes users and groups from authentik to a target application over SCIM 2.0, so accounts and group memberships exist in the application before a person signs in for the first time. Because authentik is your source of truth in this setup, the provider turns changes made in authentik (creating a user, adding someone to a group, deactivating an account) into requests the target application accepts. The provider works best when paired with SSO: SCIM decides which accounts and groups exist and what they belong to, while SSO decides how people authenticate. Running one without the other usually leaves a gap, either a user who can sign in but has no roles or a provisioned account that still needs a separate password.

The integration covers the outbound push from authentik to a target application: which users and groups are sent, how attributes are mapped to the SCIM schema the application expects, and when sync runs. It does not cover pulling accounts from an application back into authentik, and it does not replace the application's own role model, so permissions inside the application still need to be designed and confirmed there. Inbound provisioning from upstream directories is a separate topic covered by authentik's source documentation. Ask the application vendor which SCIM features it supports, including user deactivation, group membership updates and filtering, because a SCIM endpoint that accepts create requests may not handle every update the same way.

Confirm the supported provider types for your authentik version in the authentik providers documentation before you plan the build, since the list of provider types is the first thing to check against your target. Then write down, for each target application, the account identifier it expects, whether it needs groups or only users, and whether it treats a deactivated user as a deleted one. Those answers determine the mappings, the filters and the deletion behavior you will test, and they are the questions to put to the vendor in writing.

What your environment needs before you create a SCIM provider

Six items need to be settled before you create a SCIM provider in authentik. Each one can block the sync on its own, and most surface as failed pushes rather than clear errors, so confirm them in writing with the application owner before any configuration starts.

A supported authentik release line

Check that your deployment runs a release in a line the security policy lists as receiving security fixes. The policy currently names 2026.5.x and 2026.8.x, so a deployment outside those lines should be planned for upgrade before SCIM work begins. Confirm the exact version on the running server and worker, since both containers need to match. Ask who receives the advance notice of security releases, which the project announces at least 24 hours ahead.

Confirmed SCIM endpoint and plan tier

Before you configure anything, confirm in the vendor's own documentation that the target application exposes a SCIM 2.0 endpoint and that your subscription tier includes it. SCIM is often limited to higher plans, and the endpoint URL and authentication method differ by vendor. Record the base URL, the supported resources (users, groups) and any vendor-specific quirks so the provider settings match what the application actually accepts.

A dedicated service account or token

Create a separate service identity on the target application for SCIM pushes, with only the rights needed to manage users and groups. Do not reuse a personal administrator login. Record who owns the token, where it is stored, and when it expires, because an expired token stops provisioning silently until someone checks the sync status. Ask the vendor whether the token can be scoped and rotated without downtime.

Outbound HTTPS from the worker

SCIM requests are sent by the authentik worker container, not by the browser or the server container. Confirm that the worker host can reach the target's SCIM base URL over HTTPS through any proxy, firewall or egress policy you run. Check certificate trust as well, since a private certificate authority on the target side must be present in the worker's trust store. Test the path from the worker itself, not from your workstation.

Agreed scope of users and groups

Write down which authentik users and groups will be pushed, and which must stay out. Identify service accounts, break-glass accounts and groups that exist only for internal policy, because a broad group filter can create accounts the application should never hold. Decide what happens to a user who leaves the scope: whether the target account is deactivated or deleted. Filter behavior determines how old memberships are handled, so agree on it before the first sync.

A named owner for the target console

Name one person on the application side who can see provisioning logs, correct duplicate accounts and approve changes to group mapping. Also name the authentik owner who will review failed tasks in the worker and adjust the provider. Without both names, the first mismatch between an existing local account and a SCIM-created account tends to sit unresolved, and the two teams end up debugging the same error from different consoles.

Configuring the SCIM provider and assigning it to an application

This sequence connects authentik to a target application's SCIM 2.0 endpoint, binds the provider to the application, and pushes a tested set of users and groups across. The result is a verified first sync that shows whether attribute matching and scope are correct before you widen assignments.

Create the SCIM provider with the target endpoint
An administrator creates a SCIM provider in the authentik admin interface and enters the target application's SCIM base URL and the bearer token or credential the vendor issued for provisioning. Confirm the exact field names, the token format and whether the URL must include a path segment in the providers documentation for your release, and check the vendor's SCIM documentation for the same values. Save the provider and confirm it appears in the provider list without a configuration error. The check is a saved provider with the endpoint recorded, and no credential is displayed in plain text after saving.
Set user and group matching fields
Choose the attribute authentik uses to match each user and group to an existing account in the target, typically a stable identifier or the email address, and set the group matching field the same way. Mismatched matching fields are the most common cause of duplicate accounts, so agree the choice with the application owner before the first sync. Confirm the property mappings for the target's user and group schema in the providers documentation, and note whether the target's vendor page recommends a particular identifier. The check is a written mapping table, reviewed by the application owner, that names the matching attribute on both sides.
Bind the provider to the application
In the application's settings in the authentik admin interface, select the SCIM provider as the provisioning backend so that authentik knows which target receives changes for that application. Confirm the menu location for this binding in the documentation for your release, since the path can differ between versions. Only applications you intend to provision should carry the binding, because an incorrect binding sends changes to the wrong tenant. The check is an application page that lists the SCIM provider as its provisioning target.
Assign a limited test population
Assign one test user and one test group to the application through its bindings, keeping the population small so the first sync is easy to inspect. Use a test account that the application owner can recognize in the target, and avoid service accounts and shared mailboxes at this stage. Assignment scope controls what the sync sends, so confirm that the group filter behaves as you expect, including whether removing a user from a group leaves the old membership in the target until a later sync reconciles it. The check is a short list in authentik showing exactly one test user and one test group in scope.
Run an initial sync and read the task result
Trigger the first synchronization from the provider page, or wait for the scheduled run if your release triggers it that way, and open the task result. Read the log for each record, noting creations, updates, skips and errors, and compare the counts with the population you assigned. A 401 or 403 response usually points to the token or its scope, and a 409 or conflict usually points to a matching failure, so resolve those before expanding scope. The check is a completed task with the expected counts and no unexplained errors.
Verify the test user and group in the target
Sign in to the target's admin console and find the test user and test group that authentik just pushed. Confirm that the user's attributes match the mapping you agreed, that the account matched the intended existing record rather than creating a duplicate, and that the group membership shows the test user. Repeat the check from authentik by viewing the group membership and comparing it with the target. The check is the same membership visible in both systems, with no duplicate account in the target.
Widen scope only after the test passes
Once the test user and group reconcile cleanly, expand assignments in stages and repeat the task review after each stage. Keep a record of the sync results so that any later change in behavior can be traced to a specific assignment or mapping change. Before a wide rollout, ask the application vendor to confirm how it handles deactivation and group removal, since those behaviors vary by product. The check is a dated record of each stage with the task result and the target verification attached.

How authentik users and groups map to SCIM resources

This table compares each authentik object and attribute with the SCIM resource field it becomes in the target application, and the decision your team must make for it. Read it before you build the provider, because the identifier choices here decide whether a sync updates an existing account or creates a duplicate.

authentik object	SCIM resource or attribute	Target field	Decision the team must make
User username	User userName	Login name in the target app	Confirm the target treats this value as unique and stable, and that it matches the value users already have there.
User email	User emails (primary)	Account email or matching key	Decide whether email is the matching key, and whether it can change without creating a second account in the target.
User display name	User displayName	Visible name in the target	Choose whether authentik or the target owns display names, since a later edit in one system can be overwritten by the other.
User given and family name	User name.givenName and name.familyName	Structured name fields	Map these only if the target requires them, and check whether it accepts empty values for users without a split name.
User active flag	User active	Enabled or disabled account	Decide whether an inactive authentik user should be deactivated in the target or deleted, and confirm the target supports deactivation at all.
Group name	Group displayName	Team or role name in the target	Agree on a naming pattern so groups are not created twice under slightly different names.
Group membership	Group members	Membership list in the target	Confirm which groups are pushed, and how removals from a group are handled when a filter no longer matches.
Custom attributes and property mappings	Enterprise or extension schema attributes	Target custom fields	List only the attributes the target needs, because each mapping must be tested for every user type that carries it.

Why group filters can leave old memberships in place

Changing a group scope or filter in authentik changes which groups the SCIM provider pushes from that point forward, but it does not, on its own, tell the target application to remove memberships for groups that have just fallen out of scope. Treat that as behavior to confirm in the authentik release your team runs, not as a guaranteed outcome. The practical risk is that a user keeps access in the SaaS or self-hosted app through a group that no longer appears in authentik, and nobody notices because the sync reports no error. The control to plan for is that the target keeps its own copy of group membership, and removing an entry from the pushed set is a separate action from revoking the membership there.

Before you change a production filter, test it on a non-production group that has one or two disposable test users. Record the target's membership for that group first, using the target's own admin interface or API, and note the exact group values and identifiers the provider sends. Then make the scope change in authentik, trigger a sync, and list the target's memberships again. Compare the two lists and write down which memberships were added, which were removed, and which stayed. If the stale membership remains, you have confirmed the behavior for that release and that target, and your cleanup design has to account for it.

Plan the cleanup step as part of the change, not as a follow-up. Options include a scripted reconciliation that compares the target's group memberships with the groups authentik currently pushes and removes the difference, a scheduled report that flags memberships with no matching authentik group, or an explicit removal run before the scope change takes effect. Whichever you choose, assign an owner, run it in a test tenant first, and confirm that the removal does not also delete accounts or groups that you meant to keep. Ask the vendor of the target application and your authentik support channel how their SCIM implementation handles group removal, because behavior differs between targets, and confirm the result on your own version.

Sync triggers and vendor compatibility settings to confirm

Before you promise anyone a delay, confirm which events cause authentik to send a change to the target. The set of triggering events, any scheduled full sync and any manual sync action can differ by release and by edition, so check the provider settings and the release notes for the version you run.

Object events: Check which user and group changes (creation, attribute changes, group membership changes, deactivation) produce a push, and test each one against a staging target.
Assignment changes: Confirm whether adding or removing a user from the group or application bound to the provider sends a push, since this decides whether access changes reach the target promptly.
Scheduled or manual syncs: Check whether the provider offers a scheduled full sync or a manual sync action, and whether that option is available in your edition.
Background worker: Background tasks run in the worker container, so confirm the worker is running and review its logs after a test change.
Measured timing: Record how long a test change takes to appear in the target, and write that measured result into your runbook.

Confirm the triggering behavior in your release's documentation and record the results of each test before go-live.

Securing the SCIM token and limiting what gets provisioned

A SCIM connection is a standing channel that can create, change and remove accounts in a target application. The controls below decide how much damage a leaked token or a misconfigured group filter can do, and they should be settled before the first sync runs.

Scope the target token

Issue the SCIM token with only the rights the target application needs to manage users and groups, and do not reuse an administrator token from another integration. Ask the application owner which endpoints and object types the token can reach, and confirm that it cannot change tenant settings or billing. Set a rotation schedule the owner signs off on, and record who holds the token and where it is stored. Confirm the minimum rights with the vendor before the first sync.

Restrict provisioned groups

Provision only the groups that the target application is meant to see, selected by an explicit group list rather than by a broad filter. Admin or owner roles in the target should be granted only through a mapping that someone reviewed and approved, never because a user happens to belong to a group with a similar name. Check the group filter after every change, because a narrowed filter does not remove memberships that were already pushed.

Keep the token out of config files

Do not place the SCIM token in plaintext configuration files, Compose files, Helm values or source control. If the deployment has a secret store, hold the token there and inject it at runtime, and limit read access to the people and services that operate the provider. Confirm how the secret reaches the authentik containers and whether it appears in logs or exported configuration. A token in a repository is a token that must be rotated.

Log and review provisioning tasks

Keep the record of each provisioning task and review it on a fixed cadence, looking for unexpected creates, large batches of updates, and repeated failures against the same account. Make sure the log retention period meets your audit needs and that the log is forwarded somewhere the authentik operators cannot edit. Ask the vendor which events the target application records on its side so both logs can be compared during an investigation.

Control who edits provider bindings

A provider binding decides which application receives which users and groups, so changing it is a change to access. Limit edit rights on SCIM providers and their application bindings to a named group, and require a second reviewer for changes that add groups or admin mappings. Confirm which of these permissions your authentik edition and role model allow, and test that a non-admin operator cannot add a binding.

Deactivate before deleting

Decide what happens in the target application when a user leaves or is removed from a group. Many teams prefer to deactivate the account first, which blocks sign-in and keeps ownership of content intact, and delete only after a retention window the business has approved. Confirm whether the target application deletes, deactivates or ignores a SCIM delete request, since that behavior varies by vendor and changes the blast radius of an error.

Which SCIM failures recur and where to look first

This table pairs the SCIM failures teams see most often with their likely causes and the first check to run. Start with the worker logs and task results in authentik, since most sync problems show up there before they appear on the target application. Work down the rows in order of the symptom you are seeing, not the order of the causes you suspect.

Symptom	Likely cause	First check
401 or 403 responses from the target	The bearer token has expired, was rotated on the target, or lacks the scope needed to create or update users and groups	Open the failed task in authentik, confirm the token on the SCIM provider is current, and test the same token against the target's user endpoint
Duplicate accounts appear on the target	The matching attribute differs between systems, such as email case, a username format or an external ID that the target never stored	Compare the identifier authentik sends with the one already on the target account, then align the mapping before re-running sync
Memberships remain after a group filter change	SCIM does not remove users from groups that fall outside a new filter, so old memberships stay until they are cleared on the target	Check the group's membership on the target after the change and decide whether to remove them manually or through a planned cleanup
Users are not created in the target	The user sits outside the application binding or group assignment, so authentik never includes them in the sync scope	Confirm the user is bound to the application through the group or policy and review the sync task output for skipped objects
Sync appears idle	The worker container is not running, or background tasks are queued behind a backlog in PostgreSQL	Check worker logs and the task queue for pending or stalled SCIM tasks before changing any provider settings
Target rejects requests with rate limit or schema errors	The target throttles bulk requests, or a mapped attribute does not match the target's schema or required fields	Read the response body in the task result, note the HTTP status and any schema message, then reduce batch load or correct the attribute mapping

Pairing SCIM with SSO so accounts exist before the first login

Provisioning and single sign-on are usually designed together because they answer two different questions about the same person. SCIM decides which account and group memberships exist in the target application before anyone signs in. SSO decides whether the person who signs in through authentik is allowed to proceed. If only SSO is configured, the application may create a local account on first login with the wrong role, or refuse the login entirely. If only SCIM is configured, the account exists but the user still has no working sign-in path. Designing both together means that the account the SCIM push creates is the same account the SSO assertion resolves to.

The rule that must line up is the identifier. The SCIM provider sends a userName and related attributes for each user, and the application stores that value as the account key. On the authentik side, the SSO assertion or token carries a subject or email claim that the application maps to a user. Those two values must match exactly, including case and domain suffix, or the application will create a second account on first login. Before you enable pushes to production, pick one identifier, usually the work email, confirm which value the SAML NameID or OIDC subject carries, and check the vendor's documentation on how it matches incoming assertions to existing SCIM accounts. Check with the vendor which field it treats as the unique key, because that choice governs what happens when a username changes.

When the account is missing at first sign-in, the user typically sees an error page from the application, such as a message that no account is associated with the login, or a prompt to request access. The exact text depends on the application and its settings, so confirm it in a test before users encounter it. Test the two paths together with one test user in a non-production tenant. Assign the user to the authentik application and the group that drives provisioning, run the sync and confirm the account and group memberships appear on the application side. Then sign in through authentik and confirm the session lands on that same account without creating a duplicate. Repeat the test after changing the user's email to confirm the identifier behavior you have documented.

Questions teams ask before provisioning with authentik

What drives the cost of a SCIM provisioning build?

The main cost drivers are the number of target applications, the number of custom attributes each one needs mapped, how your groups are modeled, and how much testing each target requires. Each target implements SCIM 2.0 with its own behavior, so a target that needs vendor-specific handling takes more analysis than one that follows the standard closely. Costs fall into one-time design and build work and recurring work after go-live. Ask for the quote to list each target separately, with its attribute mappings, group rules, test cases and the environments where testing runs. Any figure should come from that written scope, not from a general estimate.

How long does a SCIM provisioning project take?

The duration depends on scope, so no fixed timeline applies to every build. The variables that matter most are the number of targets, whether each vendor's SCIM endpoint needs special handling, how complex the group model is, and how quickly target owners can review and test. A single well-documented target moves faster than several targets with custom attributes. DeployOpen's engagements are usually fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask for the schedule in that written plan, and confirm early when each test tenant will be available, since delays in access often push back the testing phase.

What does our internal team need to provide for SCIM provisioning?

Three roles matter most. First, an owner in each target application who can approve attribute mappings, confirm how roles and groups should appear, and sign off testing. Second, a test tenant or sandbox in each target that mirrors production settings closely enough to show realistic vendor behavior, with admin credentials handled under your secrets policy. Third, an identity data owner who decides which users and groups should be provisioned, which attributes are authoritative, and which service accounts are excluded. An authentik administrator also needs access to the instance to make and review changes. When these people are not available, decisions stall and tests run against assumptions.

Can a platform team build SCIM provisioning without a partner?

Yes, a capable platform team can build a single well-documented target in-house, provided it has time, access to the target's SCIM and admin API documentation, and someone who owns the identity data. Difficulty rises with the number of targets, because each one has its own attribute schema, group semantics, deactivation behavior and quirks, and every later change must be retested against all of them. Work that teams often underestimate includes deciding how deprovisioning works, testing group removal, and confirming that a sync does not leave stale memberships behind. Compare that load with your team's current capacity, and use a written scope from a partner to see exactly what your team would otherwise own.

Why do old group memberships stay in a target after a SCIM filter change?

A group filter decides which groups and members the provider sends to a target, so changing the filter changes what is in scope but does not automatically clean up what was already sent. Members that fall outside the new filter can remain in the target until something removes them. Confirm in your authentik version how the provider handles memberships that leave the filter, and then test the exact case: remove a user from the scope, run a sync, and check the target's group list directly. Record the result for each target, because vendors differ in how they treat group membership updates and removals.

What recurs after SCIM provisioning goes live?

Several tasks repeat after go-live. Authentik moves through versioned releases, and the authentik security policy lists the supported versions that receive security fixes, so the instance and its provider configuration need planned upgrades. Credentials that the provider uses to call each target, such as tokens or API keys, need rotation under your policy. Targets also change their SCIM schemas or vendor behavior, which can break mappings that worked before. Membership review is recurring as well: periodic checks confirm that groups still match your access policy and that departed users no longer appear in targets. Ask whether a retainer covers these tasks or whether your team keeps them.

What should a SCIM provisioning quote include?

A useful quote follows directly from the written scope and lists each deliverable. It should name every target application with the version tested, the attribute mappings and custom attributes in scope, the group model and filter rules, how deletions and deactivations are handled, the test cases and the environments they run in, and the handover documentation. It should also state what is excluded, such as vendor-side changes or licenses a target requires. Confirm the authentik edition needed for the provider type you plan to use, since the authentik pricing page lists some provisioning integrations as Enterprise features.

How DeployOpen scopes and delivers authentik SCIM provisioning

DeployOpen plans, implements, tests, documents and supports authentik SCIM provisioning to applications inside your own infrastructure. Each engagement starts from a written scope that names the target applications, the user and group attributes to send, and the sync behavior you accept, so the work is defined before it begins.

How we scope

Inventory each target application and confirm its SCIM 2.0 endpoint, authentication method and vendor-specific behavior.
Define which authentik groups drive provisioning and which group membership changes remove access in the target app.
Agree in writing how deletions, deactivations and old memberships are handled before any connection is configured.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Configure SCIM providers and property mappings in authentik and bind them to the agreed applications and groups.
Test create, update, group membership and deactivation events in a non-production environment against each target.
Verify that group filter changes leave prior memberships in place and correct them with documented steps.
Pair provisioning with the SSO configuration so each provisioned account matches the identity used at login.

How we hand over

Document the sync triggers, mappings, filters and vendor compatibility settings used for each application.
Provide runbooks for manual resync, failed-task review and removing stale memberships safely.
Walk through the configuration with your administrators and record open items and owner decisions.
Deliver configuration and documentation in your environment, under your control and your change process.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover re-testing after authentik or target application upgrades that change SCIM behavior.
Confirm with each vendor which SCIM features and modes your plan supports before scoping the support work.
Ask for a written quote that lists scope, deliverables, recurring support and exclusions before approval.