How authentik SSO connects your applications and directories
When several applications need one login and a directory of record already holds your users, the goal is a single identity layer that sits between them. authentik SSO does this by acting as the identity provider for each application: it issues OAuth2/OIDC tokens or SAML assertions to every app you connect, and it gets its user data from upstream sources such as LDAP or Active Directory, other identity providers, and SCIM feeds. The integration work is less about turning on a protocol and more about agreeing, application by application, what identity the app should receive.
The first difficulty is claim and attribute mapping. Each application expects its own names and formats for the same person, such as an email claim, a SAML NameID, or a group list, and authentik property mappings have to produce exactly that. Trouble usually follows from small mismatches: an application reads a claim that is missing or empty, or it expects a value in a different case. Plan a test user for every application and inspect the actual token or assertion before you call the integration finished, rather than trusting the configuration screen.
The second difficulty is trust configuration. OAuth2/OIDC redirect URIs must match the application's registered callback exactly, and SAML entity IDs and ACS URLs must match on both sides. A single trailing slash or a mismatched hostname produces a login failure that looks like an authentication fault. Record these values in a shared table with the owner of each application, and confirm them in a non-production environment that uses the same public hostnames you will use in production.
The third difficulty is sync scope and role mapping. When authentik pulls users and groups from Active Directory or LDAP, the directory query decides which accounts appear at all, and group-to-role mapping decides what those users can do in each app. Ask the directory owner which organizational units and groups belong in scope, which service and disabled accounts must be excluded, and who approves changes to the mapping. Broad sync scope tends to grant access that nobody intended, so write the scope down before the first sync runs.
Finally, decide which system owns each user attribute. Name, email, department and group membership may be authoritative in the directory, while MFA enrollment or recovery details may live only in authentik. Where both systems can write the same field, one of them will eventually overwrite the other. This page covers integration only. Hardening, high availability, migration and edition choice are covered in their own topics, so use the attribute ownership table as the input to those decisions. Confirm the exact provider versions and feature availability for your environment with the authentik documentation before you commit to a design.
Which authentik parts carry SSO and identity traffic
An authentik integration connects applications, upstream identity sources and user directories through a small set of components. Knowing which part handles which kind of traffic makes it easier to scope onboarding, size hosting and decide where configuration and logs need to be checked.
Providers for each protocol
A provider defines how authentik speaks to one application. authentik documents provider types for OAuth2/OIDC, SAML, LDAP, SCIM and others, and each one issues tokens, assertions or directory responses in its own format. For every application, confirm the protocol it supports, the redirect URIs or assertion consumer URLs it needs, and which signing keys and certificates it will trust.
Applications that bind to providers
An application in authentik is the catalog entry users see in their launcher, and it binds to exactly one provider that carries the protocol settings. Access is controlled through policies bound to the application, so a team can allow or deny sign-in without changing the application's own configuration. Check which groups and policies gate each application before onboarding users.
Sources for directories and upstream providers
Sources bring identities into authentik from Active Directory, LDAP directories and upstream identity providers. Each source decides which users and groups are imported, how they are matched to existing accounts and how often synchronization runs. Confirm the bind account, the search base and the attribute mapping with the directory owner, because these settings determine which users can later sign in.
Property mappings for claims and attributes
Property mappings translate user and group data into the claims, SAML attributes or LDAP attributes that each provider sends. They are where a team decides which email, department or role values reach a downstream application. Review every mapping against what the receiving application expects, and test with a real sign-in before assuming the claim names match.
Server and worker containers
The server container runs core with an embedded outpost, so it handles the web interface, the protocol endpoints that applications call during sign-in and any outpost-served traffic. The worker container runs background tasks such as source synchronization. Confirm that both containers are running and can reach the directory and upstream endpoints, because a healthy server can still show stale directory users when the worker is down.
PostgreSQL as the system of record
PostgreSQL stores all authentik configuration and data except uploaded files, including providers, applications, sources, mappings, users and events. Because every integration depends on it, the database needs backup, restore testing and capacity planning from the start. Ask who owns the database, how it is backed up and whether it is shared with other workloads before the integration goes live.
Which protocol and identity source to choose for each application
This table compares the main protocol and identity source choices for connecting applications to authentik, with the operational cost each one adds. Read each row as a decision: find the situation that matches your application or directory, then check the trade-off before committing. The main takeaway is that the choice of protocol and sync model is driven more by what each application supports and what it needs in its tokens or user records than by preference, and the ongoing cost of each option is easy to underestimate.
| Decision | When it fits | Operational cost to plan for |
|---|---|---|
| OIDC per application | Modern web or API applications that support OAuth2/OIDC and need standard claims such as groups or email in the ID token or userinfo response. | Client secrets must be rotated on a schedule the application team agrees to, and redirect URIs must be kept exact when hostnames change. |
| SAML per application | Legacy or enterprise applications that only accept SAML assertions or require signed assertions with specific attribute names. | Signing certificates expire and must be renewed, and the application must be updated with the new certificate and metadata before cutover. |
| Local authentik accounts | Small user populations, service-facing applications or pilots where no external directory is the source of truth. | Joiner, mover and leaver processes must be handled inside authentik, and password and MFA enrollment becomes the operator's responsibility. |
| Upstream federation with an external IdP | Organizations that already authenticate staff through a central identity provider and want authentik to act as a broker for applications. | Federation settings, claim mappings and metadata must be maintained, and an upstream change can affect every application behind authentik. |
| LDAP or Active Directory as a sync source | Directories remain the authoritative record and authentik needs users and groups copied in on a regular basis. | Sync schedules set the latency for account changes, and sync scope and filters must be reviewed whenever directory structure changes. |
| LDAP or Active Directory as a live bind | Applications or flows must verify passwords against the directory in real time and a local copy of credentials is not acceptable. | Directory availability and bind account permissions become dependencies of every login, and changes to search scope need testing. |
| SCIM push provisioning | Target SaaS applications support SCIM and accounts must exist in the application before first login. | Mapping errors and failed pushes need monitoring, and token rotation for the SCIM endpoint must be planned. |
| Just-in-time creation at login | Applications that create accounts on first sign-in and do not need pre-provisioned users or group memberships. | Users without a login do not exist downstream, which can complicate offboarding and access reviews unless deprovisioning is handled separately. |
| Generic OIDC or SAML for Entra ID or Google Workspace | Organizations that want a standard protocol connection and can accept manual configuration of claims, groups and user sync. | Configuration is maintained by hand, and each change in the upstream tenant must be mirrored in authentik. |
| Entra ID or Google Workspace integrations | Organizations that want built-in connectors for Microsoft Entra ID or Google Workspace directory data and user sync. | These connectors are part of the enterprise license terms, so confirm licensing with authentik before design work begins. |
How to sync Active Directory or LDAP users and groups into authentik
The first decision in an Active Directory or LDAP sync is not in authentik at all. It is the scope of what leaves the directory. Before anyone creates a source, the directory owners and the authentik owners should agree on the base DN that the sync reads from, the user and group filters that select which objects qualify, and which group memberships count as access. A broad base DN can pull in service accounts, disabled identities and contractor objects that were never meant to sign in to applications. A narrow filter can silently exclude a group that a critical application depends on. Write the agreed scope down, have the directory owner sign off on it, and treat any later change to it as a change request, not a configuration tweak.
An LDAP or Active Directory source in authentik reads the directory on a schedule and writes the results into authentik's own database, which is PostgreSQL. The periodic sync work runs in the worker container, not the server container. This split matters for operations. The server handles logins and the admin interface, while the worker performs background tasks such as directory synchronization. If the worker is stopped, unhealthy or unable to reach the directory, users may still log in with existing synchronized accounts, but new users, removed users and changed group memberships will not appear until the worker recovers. Confirm the current source options, scheduling behavior and supported directory versions in the authentik documentation and against your own Active Directory or LDAP environment before you plan the cutover.
Once users and groups are in authentik, membership maps in stages. A synchronized directory group becomes an authentik group, and authentik groups are what you attach to applications through providers, applications and policies. Access to an application should therefore be decided at the group level in authentik, with the directory group as the source of truth. Avoid granting access to individual synchronized users by hand, because those grants are lost or drift when the directory changes. Nested groups deserve particular attention: confirm with your directory team whether nested membership is expected to flow through, and test a nested case in a non-production source before go-live, since flattening rules differ between directory types and configurations.
Attribute mapping decides what reaches applications. Property mappings in authentik translate directory attributes, such as the username, mail address, display name and group names, into the fields and claims that OAuth2/OIDC, SAML and other providers send to applications. Anything not mapped does not reach the application, and an application that expects a claim with a particular name or format will fail quietly if the mapping is missing or wrong. Build the mapping list from each application's requirements, not from the full directory schema. Keep personally identifiable attributes to the minimum each application needs, and record the reason for each one, because the same mapping decisions feed your data protection and access reviews.
Plan the verification before the first production sync. Use a test directory or a copy of the production scope, run a full sync, and check counts of users and groups against the directory owner's expected figures. Sign in as a sample of users from each access group and confirm that each application receives the expected claims and no others. Test a removed user, a disabled user and a user moved between groups, and confirm the change reaches authentik and then the application within the interval you expect. Record the worker logs and sync status for each run so that failures are visible to the operations team. Treat these checks as part of the go-live gate, and confirm the sync interval and error handling in the authentik documentation for the version you deploy.
Configuring authentik SSO step by step
This sequence takes authentik from a confirmed deployment to working single sign-on, one source and one application at a time. Each step ends with a check, such as a test login, a claims inspection, a group-membership check or a sync run result, so any problem stays limited to the change just made. Use it as the build order for your own environment and adjust the details to your applications.
Confirm the deployment model
Decide where authentik runs before anything is configured. Docker Compose suits test setups and small-scale production, and the authentik Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM. For production on Kubernetes, install with Helm and use a separately managed PostgreSQL, because the chart's bundled database is meant for demonstration and test environments. Your platform team confirms the sizing and who owns the database. This step closes when the server and worker containers are running and the admin interface loads over HTTPS.
Create the admin and identity baseline
Create a named administrator account with MFA before any integration starts, and keep the bootstrap credentials out of daily use. Set up the base user and group records that later sources and applications will depend on, and decide which login and MFA flows apply to the default tenant. authentik stores its configuration in PostgreSQL, so record each change in your infrastructure-as-code repository or runbook so the baseline can be rebuilt. This step closes with a test login by a named administrator who completes the MFA challenge and reaches the admin interface.
Configure upstream sources
Connect the sources that hold your people, such as Active Directory, LDAP or an upstream identity provider. Start with one source, and confirm the bind account, base search path and attribute names with the directory owner before saving. The authentik pricing page lists Google Workspace and Microsoft Entra ID integrations as Enterprise-only features, so confirm your edition before planning those sources. This step closes by running a sync or a test login with one known test user and checking that the account appears with the expected attributes.
Define groups and property mappings
Map directory groups to the access decisions your applications need, and keep group names stable because applications and policies will reference them. Use property mappings to control which claims or attributes each application receives, such as email, display name and group membership. Keep mappings small and documented, since each application may need different values. This step closes with a claims inspection: sign in as a test user and confirm the token or SAML assertion contains the expected subject, email and groups, with nothing extra exposed.
Create the first provider and application
Start with a low-risk internal application that has a clear owner and a rollback path. Create one provider that matches the application's protocol, OAuth2/OIDC or SAML, then create the application and bind it to that provider. Attach an access policy that admits only a test group. Record redirect URIs, signing certificates and client settings in your change record. This step closes with a successful test login from a test group member and a group-membership check showing that a user outside the group is denied.
Onboard the remaining applications one at a time
Repeat the provider and application pattern for each target, one application at a time, and move to higher-impact systems only after the earlier ones run cleanly. Document the protocol, redirect URIs or ACS URLs, claims and group rules for each application, and have each owner sign off on their test result. Applications that need LDAP, RADIUS or forward authentication use separate provider types, and those outposts need their own deployment plan. Close each application with a test login by an intended group member and a denied check for an outside user.
Add SCIM targets last
Add SCIM provisioning only after login and claims are stable, because provisioning creates, changes and removes accounts in the target application. Create the SCIM provider, point it at the target's SCIM endpoint using a token issued by the application owner, and define which users and groups are in scope. Run an initial sync in a non-production tenant first and review what was created, updated and deactivated. This step closes when the sync run result matches the expected user and group counts and a test deprovisioning removes access as intended.
What drives the effort and cost of an authentik integration
This table lists the main drivers of effort and cost in an authentik integration, why each one moves the work, how to keep it down, and who usually pays. Read each row as a lever you can set before work starts, since most drivers grow with the number of applications, sources and environments. The main takeaway is that protocol choice, sync scope and mapping reuse shape most of the work, so settle them in writing before asking for a quote.
| Driver | Why it moves effort or cost | How to keep it down | Who pays |
|---|---|---|---|
| Applications and protocol mix | Each app needs its own provider, redirect or metadata setup and testing. SAML metadata and attribute statements usually need more testing than OIDC. | Standardize on OIDC where the app supports it. Onboard apps with similar login needs in one batch. | Application owners confirm requirements. Internal staff or a partner configure and test. |
| Directory size and sync scope | Syncing every OU and attribute from Active Directory or LDAP adds mapping work, sync load and stale account cleanup. | Limit sync to the OUs and groups the applications need. Agree the filter with directory owners in writing. | Directory owners approve scope. Internal identity staff or a partner build the sync. |
| Group-to-role and attribute mapping | Each application role needs a rule that maps directory groups or attributes to claims. Inconsistent naming multiplies the rules. | Set one group naming standard and reuse shared property mappings across applications. | Identity team defines the model. Application owners confirm the roles they need. |
| Upstream identity providers | Each external identity provider adds federation setup, claim mapping, login flow branches and its own test cases. | Federate only providers with a current business need. Keep one login flow that handles provider selection. | Upstream provider owners configure their side. Internal staff or a partner configure authentik. |
| SCIM provisioning targets | Each SCIM target needs its own mapping, test accounts, error handling and reconciliation checks after go-live. | Start with targets that hold the most sensitive access. Add others in later phases with their own sign-off. | Application owners pay for changes in their app. The build team pays for connector work within scope. |
| Environments (test, staging, production) | Each environment needs its own settings, secrets and test runs, and changes must move through all of them. | Keep configuration in version control or exported form so each promotion repeats the same steps. | The internal platform team pays for environment hosting. A partner pays for build effort under a fixed scope. |
| Custom claims and flow changes | Custom claims, expression policies and changed login or enrollment flows need design, review and regression testing. | Use standard claims and flows where possible. Document each custom change with the app it serves. | Application owners request changes. The team that builds them is paid for the scope agreed in writing. |
| Compliance evidence requests | Assessors may ask for configuration exports, access reviews, MFA enforcement proof and change records, which take time to assemble. | Agree the evidence list before build. Collect exports and logs on a schedule so evidence is ready when requested. | The compliance lead defines needs. A partner prepares the evidence pack if it is in scope. |
How to protect client secrets, redirect URIs and directory bind accounts
Most authentik integration risk sits in a handful of credentials and settings: client secrets, signing keys, redirect URIs, directory bind accounts and SCIM tokens. The cards below cover how to store, scope, rotate and monitor each one so that a single leaked value or loose setting cannot expose several applications at once.
Client secrets and signing keys
Each OAuth2/OIDC or SAML provider depends on a client secret or signing certificate that the relying application trusts. Keep these values out of plain-text compose files and Git repositories, store them in your secrets manager, and give each application its own credential so one exposure does not affect every integration. Confirm who can view and export provider keys inside authentik, and record the rotation owner and date for each application.
Strict redirect URI allowlists
An OAuth2/OIDC provider should accept only the exact redirect URIs the application uses, not wildcard or open patterns, because loose matching lets an attacker receive authorization codes. For SAML, review the allowed ACS URLs and entity IDs in the same way. During onboarding and every change request, compare the configured values against the application's own registration and remove any leftover development hostnames.
Least-privilege directory bind accounts
When authentik syncs from Active Directory or LDAP, the bind account should be a dedicated service identity with read-only access to the search base and only the attributes that sync and login require. Avoid domain admin or broad delegated rights. Ask your directory team to confirm the account cannot write, reset passwords or read restricted containers, and document who can rotate its password.
SCIM token handling
SCIM provisioning uses a bearer token that can create, change and deactivate users and groups in downstream applications, so it carries write authority. Generate one token per target application, store it in a secrets manager, and restrict the provider's scope to the groups it must provision. Plan rotation for staff changes and confirm that deprovisioning actions are logged and reviewed.
Group-based application access
Assigning an application to every authenticated user widens the blast radius of any single compromised account. Bind each application to the groups that need it, using policy bindings in authentik, and test with a user outside those groups to confirm access is denied. Review group membership on a schedule, since access granted through nested or inherited groups is easy to overlook.
Change tracking for providers and sources
Changes to providers, sources, property mappings and bindings can silently alter who gets in or what claims an application receives. Route configuration changes through a documented review, use authentik's event log to record who changed what, and export reviewed configuration to a version-controlled store where your tooling supports it. Keep the security policy for supported versions and the 24-hour advance notice of security releases in your patch calendar, and treat general admin access and MFA hardening as covered on the separate security hardening topic.
How to test that authentik SSO works and fails safely
The purpose of this testing is to prove two things before any user depends on an integration: that authorized users reach the right application with the right identity data, and that every failure path ends in denial rather than a silent fallback to a weaker login. Write the test plan per integration (each OAuth2/OIDC client, SAML application, upstream identity provider, directory sync and SCIM connection), and for every test record the expected result before running it. Expected results written after the fact tend to match whatever happened, which defeats the purpose of the exercise.
For each integration, run a successful login for a test user in each group the application is meant to admit, and confirm the session lands in the correct application with the correct role. Then run a denied login for a user who is outside the authorized group, using an account that exists and is active, so the denial comes from the authorization policy and not from a missing account. Inspect the issued token or SAML assertion directly: check the issuer, audience, subject, expiry, group or role claims, and any attribute the application relies on for authorization. A claim that is present but has the wrong format or name is one of the most common reasons an integration appears to work while granting the wrong access.
Test logout and session behavior explicitly. Confirm what happens when the user signs out of the application, whether the authentik session ends, and whether a second application still accepts the session after single logout. Check session lifetime against the timeout you agreed with the application owner. For SCIM, run create, update and deactivate events for a test user and confirm the target application reflects each change within the expected window. For directory sync from Active Directory or LDAP, add a user, change a group membership and remove a user from the source, then confirm the results in authentik match the source after each sync run, including the handling of users who were removed.
Failure tests carry the most weight in this section. Use a wrong redirect URI and confirm the authorization request is rejected rather than redirected anywhere else. Rotate or mistype a client secret in a test copy and confirm token exchange fails with a clear error and no session is created. Make the directory unreachable during a sync and during a login that depends on it, then confirm the application denies access instead of accepting cached or stale decisions it was not designed to honor. Disable an upstream identity provider and confirm authentik does not offer a local password path that the application did not approve. Log each result and attach it to the expected outcome, so a failed expectation is a finding to fix, not a note to explain away.
Confirm the exact behavior of your configured authentik release and your environment before writing expected results, because flow names, stage behavior and error pages change between releases. Ask DeployOpen or your own platform team to confirm which release line is in use, and check the authentik documentation for the provider and stage settings you rely on. Keep the test evidence, including token samples with secrets removed, sync logs and failure screenshots, in the same change record as the configuration, so an auditor or a later upgrade can rerun the same cases.
What to monitor, back up and document after SSO goes live
Once SSO is live, the work shifts to keeping it correct. This sequence records what authentik trusts and who owns it, watches for failures, protects the PostgreSQL database that holds configuration and data, and keeps the platform on a supported release. Each step closes with a record the team can point to.
Document each provider, source, mapping and owner
Create an integration register with one entry per provider, upstream source, property mapping and application. Each entry names the business owner, the technical contact, the protocol, the redirect or assertion settings, the upstream identity provider or directory it depends on, and the group that grants access. Done means every production application has a complete entry reviewed by its owner, and the register sits in version control or a controlled document store the team can search during an incident.
Monitor login failures through the event views
Review the authentik event log for failed logins, rejected flows and authorization errors, and decide who receives alerts for them. Confirm in your own environment whether events can be forwarded to your logging platform and how long they are retained, since enhanced audit logging is listed as an Enterprise feature. Group failures by application so a spike points to a likely cause, such as an expired certificate, a changed redirect URI or a locked account. Done when a deliberate test failure produces an alert that reaches the on-call contact.
Watch source sync and SCIM task failures
Check the system task views for directory sync runs and SCIM provisioning tasks, because a failed task can leave users or group memberships stale without any visible login error. Assign the check to the identity team on a fixed routine and review each failure for its cause, such as an unreachable directory, a changed attribute or a request the target application rejected. Done when a deliberately broken test source produces a visible failed task, and the team records the diagnosis and fix against the matching register entry.
Back up PostgreSQL and test restores
Schedule backups of the PostgreSQL database that holds authentik configuration and data. Uploaded files are excluded from that database, so back them up separately. Since the 2025.10 release, caching, tasks and sessions also live in PostgreSQL, so a restore brings them back too. Restore the backup into a separate environment and confirm that a test user can sign in and a sample application still authenticates. Keep the Compose file or Helm values with the backup set. Done when a dated restore test record shows the version restored, the time taken and the checks passed. Ask your database team to confirm retention and point-in-time options.
Track releases against supported version lines
Watch the authentik releases page and the security policy, and record which version line each environment runs. The security policy lists 2026.5.x and 2026.8.x as the lines receiving security fixes, and the project announces security releases at least 24 hours in advance. Compare each running version with those lines at a fixed review point and flag any environment outside them. Done when the inventory shows each environment's version and support status, and the owner has acknowledged any gap in writing.
Plan upgrades in scheduled change windows
Turn each out-of-date environment into a change request that names the target release, reads its release notes for breaking changes and reserves a window. Upgrade staging first, including any outposts, and rerun the login and sync checks from the earlier steps. The 2025.10 release notes warned of roughly 50% more PostgreSQL connections after upgrading, so review connection limits and database capacity before production. Done when staging passes, a rollback path built on the tested restore is documented, and production is verified against the register.
Review group membership on a set schedule
Export membership for each group that grants access to a production application and compare it with the owner's approved list. Remove accounts that have left, groups that no longer match a role and access granted through a temporary exception. Agree the review cadence with each application owner and write it into the register. Done when a signed review record shows the date, the reviewer, the groups checked and each change made.
Rotate and review client secrets on a schedule
List every OAuth2/OIDC client secret and each SAML signing or encryption certificate referenced in the register, with its expiry or rotation date. Plan each rotation with the application team so the new value is deployed and tested before the old one is retired, and store the new value only in your approved secret store. Done when the register shows the current expiry for every credential, and each rotation has a change record naming the application and the post-change test performed.
How much does an authentik SSO integration cost and what does it need from us?
What drives the cost of an authentik SSO integration?
Cost follows the scope agreed in writing, and the main drivers are the number of applications, the protocol mix, the directory sync scope, the number of SCIM targets and the number of environments. Each OIDC application is usually the smallest unit of work. SAML applications take more time because signing certificates, metadata and attribute statements must match each service provider. Directory sync from Active Directory or LDAP adds work for attribute mapping, group filters and testing against live accounts. Each SCIM target needs its own mapping and error handling. Separate development, test and production environments multiply verification effort. On licensing, the authentik pricing page lists Open Source as free, and Enterprise at $5 per user per month billed annually plus $0.02 per external user per month. Ask for a quote that itemizes each driver and shows license costs as a separate line.
Can our own team integrate authentik SSO without an outside partner?
Yes, a team can often handle a small set of OIDC applications when it has an internal owner who knows each application's redirect URIs, scopes and expected claims. Configuring an OIDC provider for one application is a bounded task with good documentation. The picture changes when the estate includes many legacy applications, SAML services with unusual attribute requirements, LDAP-only systems or complex property mappings that must match existing user records. Those projects tend to raise questions about ownership, testing and rollback that consume time quickly. A useful test is whether someone on staff can explain each application's login flow, what it stores locally and how it responds to a failed token exchange. If the answer is no for several applications, a fixed-scope engagement can cover those gaps while your team builds skills on the platform.
What do we need to provide before SSO integration work starts?
Plan for access and decisions from several people before work begins. Application owners confirm login behavior, redirect URIs, required claims and any custom attributes each application expects. Directory administrators define the scope of any LDAP or Active Directory sync, provide the service account access needed and approve which attributes and groups may leave the directory. Someone must supply test accounts in each application and in the directory, including accounts with and without group membership, so that both successful and denied paths can be checked. Change windows must be agreed for cutover, because each switch affects users. Finally, name one approver who signs off scope changes, acceptance and go-live. Ask for these responsibilities to be written into the scope so that any delay has a clear owner.
Does the authentik Enterprise license cover Entra ID and Google Workspace integrations?
Yes, the authentik pricing page lists Google Workspace and Microsoft Entra ID integrations as Enterprise-only features. The same page lists mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support for subscriptions over $1k as Enterprise-only items. Enterprise is priced at $5 per user per month billed annually plus $0.02 per external user per month, according to that page. Enterprise Plus, which starts at $20k annually, adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Confirm current terms directly on the pricing page before budgeting, and check with your licensing contact how external users are counted in your organization. The license is a separate subscription from DeployOpen's services.
How do we request a fixed-scope quote for authentik SSO work?
Send a written list of the applications, protocols and directories in scope, along with the environments and any compliance evidence you need. Include the number of users and external users, whether SCIM targets are involved and which directory sync is expected. DeployOpen's engagements are typically fixed-scope, and the quote follows from that written scope. DeployOpen does not publish a price list. Ask for named deliverables for each application, such as configuration records, test results, runbook entries and handover sessions. The quote should state its assumptions, the client responsibilities, the change windows, the out-of-scope items and how scope changes are priced. Also ask for acceptance criteria and who signs them. Keeping license costs separate from services lets you compare them with the authentik pricing page directly.
How long does an authentik SSO integration take to complete?
The duration depends on the scope agreed in writing, so no single timeline applies to every organization. The number of applications, the protocol mix, the sync scope and the number of environments set most of the schedule. Dependencies matter as well: application owners must confirm claims, directory administrators must approve sync scope, and change windows fix the cutover dates. Testing time grows with the number of user groups and failure paths you want to verify. Ask for a written timeline that lists phases, the dependencies on your side and the milestones each one affects. Treat any duration offered before scope is written as an assumption to challenge. Once scope is agreed, the work can be planned against named deliverables, and progress can be reported against the same list.
Which authentik protocol integrations usually take the most effort?
SAML and LDAP integrations usually take more effort than a standard OIDC application, although the difference depends on each application. SAML requires agreement on metadata, signing certificates, entity IDs, assertion consumer URLs and attribute statements, and small mismatches can cause login loops that are hard to diagnose. LDAP integrations involve bind behavior, search base design and the permissions the outpost needs, and they often serve legacy software with fixed expectations. SCIM provisioning adds outbound mappings, unique identifier choices and error handling for each target. Directory sync adds filters, attribute mapping and group handling. Before committing, list each application with its protocol and check whether the vendor documents the claims or attributes it expects. Confirm specific provider types and features in authentik's provider documentation for the version you plan to run.
How DeployOpen scopes, builds and hands over authentik SSO integrations
DeployOpen plans, implements, integrates, documents and supports self-hosted authentik inside your own infrastructure, including OAuth2/OIDC and SAML application connections, upstream identity federation and directory sync. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory each application, its protocol (OAuth2/OIDC, SAML, LDAP or SCIM) and the claims or attributes it expects.
- Confirm upstream identity providers, Active Directory or LDAP sources and which user attributes must sync into authentik.
- Record the agreed scope, deliverables and timelines in writing, and confirm which authentik edition each required feature needs.
How we build
- Deploy authentik in your environment with PostgreSQL, the server and worker containers and the hosting you have chosen.
- Configure each provider, application and flow in a reproducible way, with test users for every protocol in scope.
- Test sign-in, logout, token refresh, group mapping and SCIM provisioning and deprovisioning against each connected application.
How we hand over
- Document each provider, application, source and property mapping, including the settings that must match on the application side.
- Walk your operations and identity teams through runbooks for onboarding a new application and rotating certificates or secrets.
- Deliver configuration and documentation so your team can maintain integrations without depending on DeployOpen for routine changes.
How we support
- Review integrations when you move to a new authentik release, including changes that affect providers, outposts and PostgreSQL.
- Available as a retainer for ongoing support, upgrades, and continuous testing of sign-in paths after changes.
- Confirm with the authentik project which release line your deployment uses and how security releases will be applied.
