authentik and Sentry SAML and SCIM integration guide

authentik and Sentry SAML and SCIM integration: what it does and which method to use

If you want Sentry sign-in and the access lifecycle for your engineers driven by authentik, the integration uses SAML 2 for sign-in and SCIM for provisioning users and teams, and SCIM only works after SAML is configured first. The order matters: you establish the SAML trust, confirm that engineers can sign in through authentik, and only then turn on SCIM so that Sentry can create, update and remove members and teams from identity data that authentik sends. Plan the two parts as separate milestones with their own checks.

The split of responsibility is simple to state and easy to get wrong. authentik is the identity source: it holds the users, the groups that represent your teams or roles, the SAML application that Sentry trusts, and the provisioning settings that push identities out. Sentry owns the organization, the teams inside it, the member roles and the plan that determines which features exist at all. Group membership in authentik does not create a Sentry team by itself, so decide early which authentik groups map to which Sentry teams and who maintains that mapping. On Sentry SaaS, SAML2 single sign-on and SCIM start at the Business plan, so confirm the plan before you design anything. Ask your Sentry account contact to confirm current plan terms in writing, because the pricing page lists these features for Business and above.

Two decisions shape the rest of the work. First, decide whether your organization needs SCIM at all. Sign-in alone covers many teams, but without SCIM, removing a leaver in authentik does not remove them from Sentry, so you need a manual offboarding step. Second, decide where the organization lives. Sentry stores data at rest in either the United States or Germany, chosen when the organization is created and not changeable later, and it keeps some account data in the US even for EU-region organizations. Settle the region, the plan and the group-to-team mapping before you create the SAML application, because changing the region means creating a new organization.

Prerequisites: Sentry plan, authentik version and accounts to have ready

Four things need to be settled before any configuration starts: the Sentry plan, the authentik release, the Sentry access you hold, and how authentik groups map to Sentry teams. Each one changes what you can build and in what order.

Sentry Business or Enterprise plan

SAML2 single sign-on and SCIM provisioning both start at the Business plan on Sentry SaaS, so a Team subscription cannot enforce SSO or provision users from authentik. The authentik Sentry guide also says SCIM requires SAML2 to be configured first. Confirm current plan terms on the Sentry pricing page before purchase, because tier names and inclusions change.

Owner or admin access in Sentry

Whoever runs the setup needs an owner or admin role in the Sentry organization to enable SSO, set the identity provider metadata and manage members and teams. Confirm which named accounts hold that role and that at least one of them can still sign in without SSO. Record the organization slug and the data storage region chosen at creation, because the region cannot be changed later without a new organization.

Supported authentik release

Use a release on a supported line, which the authentik security policy lists as 2026.5.x or 2026.8.x. The latest release on the GitHub releases page at the time of writing is 2026.8.4. Pin the version you deploy, check the release notes for SAML or SCIM changes, and confirm that the Sentry guide still matches your version's field names.

authentik admin accounts and break-glass access

Create named administrator accounts in authentik for the people who will build the SAML provider, SCIM provider and application. Keep a separate break-glass admin with a hardware or strong second factor, stored outside the SSO flow. If the SAML application is misconfigured, this account is how you recover without locking every engineer out of Sentry.

Group structure that maps to Sentry teams

Decide which authentik groups will be pushed by SCIM and how they correspond to Sentry teams and roles before you build anything. Keep the group count small and named after the Sentry team they represent. Agree who owns membership changes in authentik, since that owner controls both sign-in and team membership in Sentry after provisioning.

Reference guide and field names

Use the authentik Sentry integration guide as the reference for exact field names, endpoint values and provider options. Read it against your authentik version before copying values into the setup, since labels can differ between releases. Keep a short written record of each value you enter so the configuration can be reviewed and reproduced.

Setup order: configure SAML2 in authentik and Sentry first, then SCIM

This sequence gets engineers signing in to Sentry through authentik over SAML2 first, then adds SCIM so users and teams are provisioned from the same identity source.

Confirm the Sentry plan and region before configuring
Before any configuration, confirm that the Sentry organization is on a Business or Enterprise plan, because SAML2 single sign-on and SCIM start at the Business plan and SCIM on Sentry SaaS requires one of those two plans. Also confirm the data storage region, since it is fixed when the organization is created and can only change by creating a new organization. Your owner should record the plan and region in the change ticket. This step is done when a Sentry owner confirms the plan in the billing settings and the region is documented.
Create the SAML provider and application in authentik
An authentik administrator creates a SAML2 provider and an application that uses it, then sets the Sentry assertion consumer service details and the signing certificate as the Sentry guide describes. Map the email attribute so that it matches the email addresses users have in Sentry, because Sentry matches accounts by email. Bind the application to the groups that should reach Sentry. This step is done when the application appears in the authentik user library and the provider metadata can be downloaded.
Configure SAML2 single sign-on in Sentry
A Sentry organization owner opens the organization's authentication settings, selects SAML2 as the provider, and enters the identity provider values from authentik, such as the SSO URL and the certificate. Confirm the attribute mapping for user identity and team or role attributes if your design uses them. Save the configuration without enforcing SSO for all members yet, so that an administrator can still recover access if the first sign-in fails. This step is done when Sentry shows SAML2 as configured for the organization.
Test sign-in with a non-admin account
Sign out of Sentry, then sign in with a regular member account through the authentik application, not an organization owner account. A non-admin test shows whether attribute mapping, email matching and group binding work for the users who will rely on SSO. Check the authentik event log for the login if the attempt fails. This step is done when the test user lands in the correct Sentry organization after authenticating through authentik, and the login appears in Sentry's member activity.
Enforce SAML2 after the test passes
Once a non-admin test sign-in works, an owner can turn on the setting that requires SAML2 for the organization, and optionally allow members to link their accounts. Keep at least one owner account that can still sign in with a recovery method, and record which account that is. This step is done when the organization shows SAML2 as required and the owner has confirmed that a second test sign-in still succeeds.
Create the SCIM token and connect provisioning
With SAML2 working, an authentik administrator configures the SCIM provider for Sentry, using the SCIM endpoint and token from the Sentry organization settings and the provider type described in the authentik integration guide. Assign the same groups used for SAML so that provisioning and sign-in follow one membership model. Run an initial sync from authentik. This step is done when the SCIM sync reports success in authentik and no sync errors are listed.
Verify users and teams in the Sentry member list
Check that the test users created by SCIM appear in the Sentry member list with the expected roles, and that teams created from the authentik groups appear under the organization's teams. Remove a test user from the authentik group and run a sync to confirm that the matching Sentry membership changes, which proves deprovisioning works. Keep a record of the test results with the date, the accounts used and the sync logs. This step is done when membership and team changes in authentik match what appears in Sentry.

Choosing a Sentry deployment: SaaS region or self-hosted

Sentry SaaS on the US region stores data at rest in Iowa, USA. The region is set when the organization is created, so it is the first decision to make. This model fits teams whose policies accept US storage for event data and who want Sentry to run the platform. For the SSO work in this guide, the plan matters as much as the region, because SAML2 single sign-on and SCIM start at the Business plan.

SSO and SCIM plan gate: SCIM provisioning of users and teams requires SAML2 to be configured first, and on SaaS it requires a Business or Enterprise plan. Developer and Team organizations cannot use the SCIM steps in this guide.
Business price: the Sentry pricing page lists Business at $80 per month billed annually or $89 billed monthly, with unlimited users and 50,000 errors.
Retention: Business keeps data for up to 90 days, compared with a 30-day lookback on Developer, which matters if engineers investigate older issues.
Changing region later: moving to another region means creating a new organization, so plan how projects, teams and settings would be recreated before you commit.

Confirm the current plan contents, error quota and overage terms with Sentry before you purchase, because pricing and quotas can change.

Attribute and identity mapping between authentik and Sentry

This table compares each identity attribute authentik sends or provisions with what Sentry uses it for, from login matching to team assignment. Read each row as a question to confirm against the authentik Sentry guide before you configure the SAML mappings or SCIM group sync. The main takeaway is that SCIM team mapping only works after SAML login is working, so the attribute chain has to be verified in order.

Identity element	What Sentry uses it for	What to confirm before go-live
User identifier (NameID)	Identifies the SAML subject that Sentry links to a Sentry user account	Confirm in the authentik Sentry guide which NameID format and source attribute it expects, and keep it stable across logins
Email address	Used to match an incoming SAML login to an existing Sentry member invited to the organization	Confirm that the email authentik sends matches the address the Sentry member was invited with, including case and aliases
Name attributes	Populate the display name on the Sentry user profile after SAML login	Confirm which attribute names the guide maps and whether first and last name are both required
Group membership (SAML)	Used by the guide to route SSO logins; confirm whether any group claim is needed for Sentry at login	Confirm whether the guide sends a groups attribute at all, since SCIM is the documented path for team membership
Organization membership	Determines which Sentry organization a user is a member of after SSO	Confirm the org slug in the SAML configuration matches the Sentry organization you are configuring
SCIM group names	Become Sentry team names when authentik provisions groups through SCIM	Confirm that group names in authentik are unique and stable, since renaming a group can change the team it maps to
SCIM user attributes	Drive creation, update and deactivation of Sentry members during provisioning	Confirm which userName and email fields the guide expects, and test deactivation with one test user before wider rollout

Security settings to lock down before go-live

Once SAML and SCIM are working, the settings that matter most are the ones that control who can sign in, how long access lasts after someone leaves, and which software versions sit behind the login. Each card below is a decision or check to close before engineers rely on Sentry through authentik.

Signing certificate handling

The SAML signing certificate authentik presents is what Sentry trusts when it validates assertions. Record which certificate is active, who holds the private key in authentik, and where the metadata was imported. Plan a rotation window in which both the old and new certificates are accepted, then replace the certificate in Sentry before the old one expires. Test one login after each change.

Restricting SCIM token scope and storage

The SCIM token lets authentik create, update and remove Sentry users and teams, so treat it as an administrative credential. Generate it from a dedicated service-level account rather than a personal one, store it in a secrets manager, and confirm which organization and permissions it carries. Rotate it on a schedule and whenever an administrator who handled it leaves.

Enforcing SSO for the organization

SAML only protects access if it is the only way in. In Sentry, check the organization authentication settings so that members must sign in through authentik and password logins are disabled for regular members. Confirm which administrator accounts stay outside SSO for break-glass use, and record where those credentials are kept.

MFA enforced in authentik

Sentry does not replace the second factor, so the MFA requirement has to live in authentik. Attach an authentication stage that requires a second factor to the flow used for the Sentry application, and confirm that the stage runs for every group that reaches Sentry. Verify the enforcement with a test account that has no enrolled device.

Deprovisioning leavers through SCIM

Deprovisioning depends on the SCIM link being active and on authentik removing or deactivating the user when they leave the groups that grant access. Test with a disposable account: remove it from the group in authentik, then confirm that the Sentry member is removed or suspended. Check how Sentry handles ownership of projects a leaver created.

Keeping authentik on a supported release line

The authentik security policy lists the supported release lines that receive security fixes, and the project announces security releases at least 24 hours in advance. Confirm that your running version is on a supported line, subscribe to release notices, and schedule upgrades so that the single sign-on path is never left on an unpatched version. Check the upgrade notes for each step, since the upgrade path must be followed in order.

Common failures when connecting Sentry to authentik and how to fix them

This table lists the failures teams most often hit when connecting Sentry to authentik over SAML and SCIM, with the cause and fix for each. Read it before go-live, and use the authentik Sentry guide to check individual field values.

Failure	Likely cause	Fix
SCIM options missing in Sentry	The Sentry organization is on Developer or Team, where SAML2 and SCIM do not start until the Business plan	Confirm the plan on Sentry's pricing page and upgrade to Business or Enterprise before configuring SCIM
SCIM configured before SAML	SCIM provisioning of users and teams depends on SAML2 already being set up in authentik and Sentry	Finish and test SAML2 sign-in first, then add the SCIM provider and token as a second step
SAML sign-in fails with an email mismatch	The email attribute sent by authentik does not match the email on the existing Sentry user account	Compare the NameID and email attribute values in the authentik Sentry guide against the Sentry account, and correct the source attribute or the user's email in authentik
Users sign in but have no team membership	Users are created without team assignments because teams are not mapped from authentik groups	Map the authentik groups that should carry team membership in the SCIM settings, then re-sync and check one test user
SCIM sync stops after a token change	The SCIM token in Sentry was regenerated or revoked, so authentik's stored token no longer authenticates	Generate a new token in Sentry, update the SCIM provider in authentik, and trigger a sync to confirm it succeeds
Users locked out after enforcing SSO	SSO was made mandatory before every existing user had a matching authentik account, or a user with an owner role was not tested	Test sign-in with a non-owner and an owner account before enforcement, and keep a documented recovery path for administrators
Leavers keep Sentry access	Deactivation in authentik does not reach Sentry because SCIM is not running or the user was never linked	Check that the SCIM sync runs on the expected schedule and that deactivated users are reflected in Sentry's member list

Questions buyers ask before connecting Sentry to authentik

What does it cost to connect Sentry to authentik?

The cost has three parts: the Sentry subscription, the authentik edition you run, and internal or partner time for group design and testing. SCIM provisioning on Sentry SaaS requires a Business or Enterprise plan. The Sentry pricing page lists Business at $80 per month billed annually or $89 monthly, with unlimited users and 50,000 errors. Team at $26 per month billed annually does not include SAML2 single sign-on or SCIM. Enterprise is priced on request. The authentik Open Source edition is free, while Enterprise is listed at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starts at $20k annually. The SAML and SCIM setup itself does not require Enterprise, but confirm the edition against the features you need in the authentik pricing page. Subscriptions recur monthly or annually; the setup labor is one-time.

How long does a Sentry and authentik integration take?

Duration depends on how many groups and teams you map, how many Sentry organizations you run, and how much testing your security team requires. The core SAML configuration is a short, bounded task, while group design, SCIM attribute mapping and deprovisioning tests take longer because they need decisions from engineering leads and access owners. The order is fixed: configure SAML2 first, verify single sign-on with test users, then enable SCIM, since the authentik guide requires SAML2 before SCIM provisioning. Ask any partner for a written schedule tied to a written scope before work starts, and confirm which Sentry plan is active before the build begins.

What do we need to provide for the integration?

You need an owner on the Sentry side with rights to change organization authentication settings, an authentik administrator who can create providers, applications and property mappings, and a list of which people and teams should exist in Sentry. Sentry SAML2 and SCIM are only offered from the Business plan, so the account owner must approve the upgrade first. You also need decisions on how identity groups map to Sentry teams, who keeps access when someone leaves, and which test accounts will verify sign-in before rollout. Gather these inputs before any configuration work starts, because they decide most of the rework risk.

Can our internal team set this up without outside help?

Yes, a team with authentik and Sentry administration experience can complete the SAML and SCIM setup alone, following the authentik integration guide and Sentry's plan requirements. The harder parts are the decisions: team mapping, attribute choices and deprovisioning rules, which benefit from a peer review by someone who has not built them. If your team has no recent authentik administration, or no one has tested SCIM deprovisioning, consider a fixed-scope engagement from DeployOpen with written deliverables. Either way, agree in writing who signs off the test results.

Where is Sentry data stored, and can we keep it in the EU?

Sentry stores data at rest in either Iowa, USA or Frankfurt, Germany. You choose the region when you create the organization, and it cannot be changed later except by creating a new organization. Even for EU-region organizations, Sentry's data storage documentation says user accounts, notification settings, 2FA authenticators, organization settings, access tokens, DSN keys, audit logs and usage data are stored in the US. Review this with your privacy and legal teams before you select a region, because it affects which data your transfer assessment must cover.

Should we use Sentry SaaS or self-host Sentry with authentik?

Choose SaaS if you accept Sentry's hosted region choice and the data placement described above, and you want Sentry to run the platform. Choose self-hosting if data location, control or internal-only operation matter more than the managed service. Self-hosted Sentry needs at least 4 CPU cores, 16 GB RAM plus 16 GB swap (32 GB RAM recommended) and 20 GB of free disk, and Sentry's self-hosted documentation lists features that are unavailable when self-hosting, including spike protection, Seer and data storage location selection. Its license, FSL-1.1-Apache-2.0, permits internal self-hosting but not selling or competing with Sentry. The getsentry/self-hosted project describes its package as suited to low-volume deployments and proofs of concept, so size production capacity with your own load tests.

What happens to access when someone leaves the company?

With SCIM enabled, deprovisioning in authentik can remove or deactivate the matching Sentry user, but the result depends on the attributes and groups you mapped, so test it. Verify that a disabled authentik user loses Sentry access, that their team memberships are handled as you intended, and that sign-in through SAML fails afterward. Keep an audit trail of these tests. Sentry's audit logs are stored in the US even for EU-region organizations, so confirm that this is acceptable for your records before you rely on them as evidence.

Where SAML and SCIM rollouts usually stall

Most Sentry rollouts that slip do so for four predictable reasons, and the first is group design left until after go-live. In authentik, the SAML provider, the application and the Sentry-side team structure all depend on which groups exist and which of them map to Sentry teams. If those groups are improvised during cutover, engineers end up in the wrong teams or with the wrong roles, and fixing that means re-running provisioning on a live organization. Agree the group-to-team mapping on paper before the SCIM provider is created, and confirm with Sentry's own documentation how team membership and roles are assigned when SCIM is active.

The second and third failures are about access. Leavers are often not deprovisioned because the SCIM sync is treated as a one-time import rather than an ongoing process, so a user disabled in authentik may still hold a Sentry seat. Separately, teams that enforce SSO before testing it can lock out their own administrators, especially the people who hold the Sentry owner or manager roles needed to recover access. Keep at least one break-glass administrator who signs in with a separate method, and verify that a test user removed in authentik loses access in Sentry before you rely on that behavior.

The fourth failure is unclear ownership of the SCIM token. The token is created on the Sentry side and entered into authentik, so whoever creates it effectively controls provisioning for the whole organization. Name a single owner, record where the token is stored, and set a rotation step in your runbook, since an expired or rotated token will quietly stop provisioning. Also confirm before you start that your Sentry organization is on a plan that includes SCIM, because a plan change midway through the project can stall the work entirely.

How DeployOpen scopes and delivers the authentik and Sentry integration

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and that includes the authentik side of a SAML and SCIM connection to Sentry. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Confirm which Sentry plan and region your organization uses, since SCIM on Sentry SaaS requires Business or Enterprise.
Record the authentik version, hosting model and the Sentry organization slug that SAML and SCIM will target.
Agree in writing which users, teams and role mappings sync from authentik, and which stay managed in Sentry.

How we build

Configure the authentik SAML provider and application for Sentry first, because SCIM depends on SAML being in place.
Add the SCIM provider only after SAML sign-in works for a test user, then map groups to Sentry teams.
Test sign-in, provisioning, group changes and deprovisioning of a leaver in a non-production Sentry organization.

How we hand over

Deliver a written runbook covering the SAML certificate, SCIM token rotation and the setup order for future changes.
Document the attribute mappings, group-to-team rules and the owner accounts that must stay outside SSO.
Walk your administrators through sign-in, provisioning checks and the points to review before each authentik upgrade.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
Retainer work can cover authentik upgrades and retesting the Sentry connection after each change on either side.
Ask for a quote built from the written scope, which names the deliverables, the environments touched and the handover items.

authentik and Sentry SAML and SCIM integration