authentik and Docker SAML and SCIM integration for SSO enforcement
If you lead engineering or security and want Docker organization members to sign in through authentik, with accounts provisioned centrally, the supported route is the one described in the authentik Docker guide. Docker SSO requires a Docker Business subscription and an organization owner, and each user's authentik email must match their Docker account on a verified domain. Those three conditions decide whether the integration can start at all, so confirm them before any configuration work. The Docker plan terms and the verified domain status belong to your Docker organization, and only an owner can make those changes.
Responsibilities split cleanly between the two products. authentik owns the identity side: the user records, the credentials and second factors, the group membership that determines who should have Docker access, and the SAML and SCIM provider definitions that authentik presents to Docker. Docker owns the organization itself: the verified domains, the SSO connection once it is enabled, default teams, and the membership and roles that result from sign-in and provisioning. Before building anything, decide which authentik groups map to which Docker teams, who will hold the organization owner role, and what happens to a Docker account whose authentik user is disabled. Those decisions are easier to make on paper than to unwind after members have already signed in.
Two things need confirming with Docker and your own environment rather than assuming. First, check that the email addresses in authentik exactly match the Docker accounts on the domain you verify, because a mismatch leaves users unable to sign in through SSO. Second, confirm current SCIM and default team behavior in Docker's documentation for your plan, since those settings are the parts most likely to change. Docker's pricing page lists single sign-on and SCIM provisioning for Docker Business only, which is the first check to make against your contract.
What you need before configuring Docker SSO with authentik
Docker SSO through authentik depends on decisions on both sides before any configuration starts. The Docker organization needs the right subscription, an owner, and a verified domain, while authentik needs a supported release and accounts whose emails match Docker identities exactly.
Docker Business subscription
Single sign-on and SCIM provisioning are listed on Docker's pricing page only for Docker Business, so a Personal, Pro or Team organization cannot follow this setup. Confirm the current plan contents and per-user price with Docker before committing, because the Business tier is the cost driver for this integration. Ask your Docker account contact whether any legacy plan applies to your organization.
Organization owner account
The authentik integration guide requires an organization owner to perform the SSO setup in Docker. Identify the named owner, confirm that the account is a long-lived administrative identity rather than a personal login, and make sure at least one additional owner exists for recovery. Without an owner available during the change window, the configuration will stall.
Verified domain on Docker
The email domain your users sign in with must be verified in the Docker organization before SSO can match accounts to it. Verification relies on DNS changes that your DNS team controls, so plan that step early. Check the domain ownership rules in Docker's current documentation, since they determine which addresses can be claimed.
Supported authentik release
Run a version that appears in the authentik security policy as receiving security fixes, and plan the target release against the current latest release listed on GitHub. Versions are named by year and month, so confirm the exact version in your environment before building. Running an unsupported release means the SAML and SCIM setup may be built on code that no longer receives security fixes.
Matching authentik email per user
Each user's authentik email must match their Docker account email on the verified domain, since this match is how SSO links the login to the Docker identity. Audit the authentik user directory for case differences, aliases and accounts created by hand before rollout. Users whose emails do not match will be unable to sign in through SSO, and they may create a duplicate Docker account if self-signup is still open.
Docker Hub pull limits for the cutover
Unauthenticated pulls in Docker Hub are limited per IP address, and Personal accounts have their own limit, so a build fleet that moves onto SSO accounts may see different pull behavior. Confirm the limits that apply to your Docker plan with Docker before cutover, since its documentation and pricing page describe the Personal limit differently. Test pulls from your build and runtime networks while both login paths still work.
How to configure Docker SSO and SCIM in authentik, in order
This sequence connects a Docker Business organization to authentik so users sign in through authentik and, if you enable it, are provisioned and removed through SCIM. Each step closes with a check, and the final check confirms that an organization owner can still reach the organization before you enforce SSO for everyone.
Confirm the Docker Business plan and verified domain
The organization owner confirms that the Docker organization is on a Docker Business subscription, the plan where single sign-on and SCIM provisioning are listed on Docker's pricing page. The owner then verifies the company domain in the organization's admin settings. Each user's authentik email must sit on this verified domain, so verify it before any user is moved. The authentik Docker integration guide lists these requirements. Check: the domain shows as verified in Docker, and the owner can open the organization's security settings without errors.
Create Docker application and SAML provider
An authentik administrator creates an application for Docker and attaches a SAML provider, using the Docker integration guide for the endpoint values and signing settings that Docker's single sign-on setup requests. Keep the provider metadata and the Docker-side values together in a shared record so both sides stay in step. Check: the provider appears in authentik with its metadata available to download, and Docker's single sign-on configuration accepts the metadata without a validation error.
Map the email attribute to Docker accounts
Set the attribute mapping so the email value sent to Docker is each user's authentik email address. That address must match the Docker account on the verified domain, or the sign-in will not link to the correct account. Test with a sample user whose email is on the verified domain, and confirm the attribute value in that user's authentik record before any wider rollout. Check: the test user's Docker account matches the email shown in authentik, and a test user with a mismatched email is not linked to another account.
Bind the application to allowed users and groups
Bind the application only to the authentik groups or users who should hold a Docker seat, so everyone else cannot start the sign-in flow. Choose the group based on who needs Docker access, and remember that every bound user needs a matching email on the verified domain. Check: a non-admin test account in the bound group signs in through authentik and reaches the Docker organization, while a test account outside the group is refused at the authentik side.
Configure default teams for new members
In Docker's organization settings, set the default teams that new members join when they first sign in, so access starts from a known baseline. The available team options depend on the Docker admin console, so confirm the current settings with Docker before you rely on them. Plan the team names and their access before go-live so that new members do not receive broader access than intended. Check: a new test user joins the expected default team after the first sign-in, and that membership appears in the organization's member list.
Enable SCIM provisioning from authentik
Create the SCIM provider in authentik, enter the SCIM endpoint and the credential Docker issues for provisioning, and bind the provider to the same application so user creation and removal follow authentik. Store the credential in a secrets store, because it grants the ability to change organization membership. Check: create a test user in authentik and confirm the user appears in the Docker organization. Then deactivate that user and confirm the matching change appears in Docker.
Confirm the org owner can still sign in
Before you require SSO for all members, sign in as the organization owner through authentik and confirm the owner can still reach the organization's admin settings. Record who holds the owner role and how recovery works if sign-in fails, because a misconfigured enforcement can lock administrators out. Ask Docker to confirm its current fallback options for owners. Check: the owner completes a fresh sign-in, the owner can change an organization setting, and a non-admin test account reaches Docker only through authentik.
Why email matching and verified domains decide whether users can sign in
Docker does not match SSO users by username or by the identity authentik happens to hold. It ties the authentik login to a Docker account through the email address on a verified domain. If the email authentik sends for a user differs from the address on their Docker account, or the domain is not verified for the organization, the sign-in either fails or creates a second Docker account that owns none of the user's repositories, teams or access tokens. The authentik Docker integration guide is the place to confirm the exact matching rules for your authentik version before you plan the rollout.
Before any user is moved onto SSO, run a three-way check. First, confirm which authentik attribute carries the email that the SAML assertion sends, and that the value is lowercase, complete and not a placeholder. Second, export the email on each Docker account in the organization and compare it with the authentik value. Third, confirm in the Docker admin console that every domain you expect to see in those addresses is verified for the organization. Build this as a reconciliation list: each row is a person, and any row where the three values disagree is fixed before the cutover date. Pay particular attention to aliases, plus-addressing and users who changed surnames, because these produce the most duplicates.
Contractors and users on domains you do not own need an explicit decision, not a silent exception. Options include inviting them through a domain you control, keeping them as Docker accounts outside SSO while the organization enforces SSO for employees, or excluding them from the Docker organization altogether. Each option has a different effect on who can pull private images and who holds organization access tokens, so confirm the Docker plan terms for guest and non-verified users with Docker before you choose. Record the decision per group so that an auditor or a departing contractor can be traced back to one clear rule.
Mapping authentik users, groups and attributes to Docker organization fields
This table compares each identity field authentik can send with what Docker needs to match a person to an organization member and place them in a default team. Items marked as confirmed come from the authentik Docker guide, while the rest must be checked against Docker's SCIM behavior in your own tenant before rollout.
| Field or object | Role in Docker matching | Status |
|---|---|---|
| User email | Must match the Docker account email, and the domain must be verified in the Docker organization | Confirmed in the authentik Docker guide |
| Verified domain | Email domain must be verified on the Docker side before SSO enforcement can match users | Confirmed in the authentik Docker guide |
| Username | Identifies the user in authentik and in SCIM payloads, but confirm whether Docker uses it for matching or only for display | Confirm in tenant |
| Given and family name | Populates display name on the Docker member record, confirm which attributes Docker reads from SCIM | Confirm in tenant |
| Group membership | Determines which authentik groups are sent for team assignment, confirm whether Docker maps groups to default teams or requires manual assignment | Confirm in tenant |
| Default team | Target team for newly provisioned members, confirm how the default is set and whether it changes for existing members | Confirm in tenant |
| Deprovisioning signal | Deactivating a user in authentik should remove or suspend the Docker member, verify the removal behavior and seat release | Confirm in tenant |
Hardening the authentik side of a Docker SSO deployment
Docker SSO moves sign-in, team membership and deprovisioning into authentik, so a weakness there becomes a weakness in every Docker organization it serves. The cards below cover the authentik deployment itself, who can reach Docker, recovery paths, the SCIM credential and the pull path that developers and CI systems share.
Run a supported authentik version
Check the supported version list in the authentik security policy before you deploy or upgrade. Versions 2026.5.x and 2026.8.x are listed as receiving security fixes, and the project announces security releases at least 24 hours in advance, so schedule a window to apply them. Confirm which release your instance runs and whether your team has a named owner for watching release notices. An unpatched identity provider is a direct path into every Docker organization it signs in.
Treat PostgreSQL as the single data store
authentik keeps its configuration and data in PostgreSQL, apart from uploaded files, and since the 2025.10 release it no longer uses Redis. That makes the database the one place to back up, restore and monitor. Test a full restore of the authentik database and the media storage on a separate host, and confirm the recovery time you would accept if the database fails. Plan connection capacity for the higher PostgreSQL connection count that the 2025.10 release notes warn about.
Limit which groups can reach Docker
Map only the authentik groups that should hold Docker seats to the Docker organization, and use the default team settings to place them in the right teams. Review who can change group membership in authentik, because that person controls Docker access indirectly. Document which authentik group maps to which Docker team, and remove any broad or legacy group that grants access by accident. Confirm with Docker how group changes take effect for existing sessions.
Keep a recovery path for the owner
Once Docker SSO is enforced, an organization owner who loses access to authentik may be unable to administer the Docker organization. Keep at least two named owners whose accounts sit on the verified domain and are reachable outside the SSO path. Store recovery credentials in your secrets manager with access logging, and test the procedure before enforcement. Confirm with Docker how an owner regains access if the identity provider is unavailable.
Protect the SCIM token
The SCIM provisioning token lets an external system create, change and remove Docker users, so it carries the same weight as an administrator credential. Store it only in a secrets manager, limit who can view it, and rotate it on a schedule and after any staff change. Confirm where authentik stores the token and who can read it from the admin interface. Review the provisioning log after each rotation to catch failed deprovisioning.
Review pull tokens and mirrors
If CI runners or developers pull through a shared path, review the Docker Hub access tokens that path uses and the organization's token inventory. Docker Hub pulls are rate-limited per IPv4 address or IPv6 /64 subnet for unauthenticated users, so a shared egress IP can cause failed builds. If you run a pull-through mirror of Docker Hub, configuring credentials on it exposes private images unless the mirror itself is secured, so restrict network access and authentication first.
Why Docker Hub pull limits still matter after SSO is enforced
Enforcing SSO through authentik changes how people sign in to Docker, not how many images they can pull from Docker Hub. Pull limits apply to the account and network making the request, so an organization that moves every developer onto Docker Business through authentik can still hit throttling in CI runners, build farms or shared egress IP addresses. Docker's usage documentation sets 100 pulls per 6 hours for unauthenticated users per IPv4 address or IPv6 /64 subnet, and 200 pulls per 6 hours for Docker Personal accounts. Pro, Team and Business accounts get unlimited pulls subject to fair use, so the paid tier is the main lever for removing the quota, but fair use is not a number you can plan against.
The limits are not stated consistently. Docker's pricing page describes Docker Personal as including 100 Docker Hub pulls per hour with reasonable use when logged in, which does not match the 200 pulls per 6 hours in the usage documentation. Before you size a rollout or write a runbook, ask Docker in writing which limit is enforced for each account type you will use, and whether that limit applies to the organization account, the individual user or the source IP. Record the answer in the change ticket so the figure does not drift between the pricing page and the documentation.
Docker's blog post on Docker Hub policies says Docker will announce any future enforcement of rate limit changes at least 6 months in advance. Treat that notice period as the planning window for any change that affects your pull volume, and assign an owner to watch Docker's announcements alongside your authentik upgrade calendar. In the meantime, a pull-through cache of Docker Hub built on the Registry image can reduce repeated pulls, but Docker's guidance warns that credentials configured on the mirror expose private images unless the mirror itself is secured.
Common Docker SSO and SCIM failures and how to fix them
This table lists the failures most often seen when enforcing SSO and SCIM for a Docker organization through authentik, with the likely cause and the first fix for each. Work through the rows in order: many symptoms share a cause in email matching or plan eligibility, so check those before changing provisioning settings. Check the authentik worker logs and the Docker organization audit view before changing anything.
| Failure | Likely cause | First fix |
|---|---|---|
| User lands on a personal Docker account instead of the organization | The user signed in to Docker directly, or the organization has not yet enforced SSO, so the browser session did not route through authentik. | Have the user sign out of Docker, then sign in again through the organization's SSO login URL. Confirm enforcement is active in the organization settings and check the Docker audit view for the sign-in event. |
| Email mismatch on a verified domain | The authentik email attribute differs from the Docker account email, or the domain is not verified in the Docker organization, so Docker cannot match the identity. | Compare the authentik user email with the Docker account email character by character. Correct the authentik profile or the Docker account, then confirm the domain is verified before retrying sign-in. |
| User missing after SCIM push | The user is not in a group or scope the SCIM provisioning path sends, the user record failed validation in the worker, or the Docker plan does not include SCIM. | Check the authentik worker logs for the provisioning task and error text. Confirm the user belongs to the group bound to the Docker application and that the organization is on Docker Business, which the Docker pricing page lists as the plan with SSO and SCIM. |
| Removed user still holds access | The user was deactivated in authentik but the SCIM deprovisioning request did not complete, or the user still has an active Docker session or a valid organization access token. | Confirm the user is inactive in authentik, check the worker logs for failed deactivation requests, and review the Docker organization audit view. Revoke any organization access tokens the user created and remove the user from the organization directly if it remains listed. |
| Owner locked out after enforcement | SSO was enforced before the organization owner's email matched a verified domain, or the owner account was not linked to an authentik user. | Use a recovery path that the organization owner set up before enforcement, such as a second owner account, and confirm the owner's authentik email matches the Docker account. Plan enforcement with a tested owner fallback before turning it on. |
| Default teams not applied | Team mapping depends on group membership or attributes that authentik does not send, or the default team was configured after the user first signed in. | Verify the group names and attribute values in the authentik application mapping, then trigger a fresh sync for an affected test user. Check the audit view to see which teams were assigned on the last sign-in. |
Questions buyers ask before enforcing Docker SSO with authentik
Which Docker plan is required for SSO and what does it cost?
Docker SSO and SCIM provisioning are listed only for Docker Business, so that plan is the one to budget for. Docker's pricing page lists Docker Business at $24 per user per month, with no annual or monthly split shown for that tier in the supplied figures. Team at $15 per user per month billed annually and Pro at $9 per user per month billed annually do not include SSO. Your total is the per-seat price multiplied by the number of users Docker charges for, so ask Docker for the exact billing terms, minimum seats and any tax before you commit. Docker's pricing page also links to legacy plans that applied before December 10, 2024, so confirm which plan your existing account falls under.
Can our in-house team set up Docker SSO with authentik alone?
Often yes, if you already run authentik and have someone who owns both the authentik provider configuration and the Docker organization settings. The work spans three areas: the Docker Business subscription and organization owner access, verified domain ownership with matching user emails, and the authentik SAML provider and application. Teams without recent SAML experience usually find the email matching and default team mapping the slowest parts, because a mismatch leaves users unable to sign in. A partner can take the build as a fixed-scope engagement and hand over a tested configuration and runbook, while your team keeps the day-two ownership. Decide early who will hold the Docker owner account and who approves changes.
How long does the integration take and what drives the duration?
The duration depends on the state of your identity data and how many Docker teams you need to map, not on the protocol itself. The biggest drivers are whether your users already have authentik accounts with the same email addresses as their Docker accounts, whether your domain is ready for verification, how many default teams and SCIM mappings you want, and how many test accounts you need for sign-in, team assignment and removal. Ask any provider for a written schedule based on your scope, and confirm which items are blocked by your own approvals or DNS changes. Duration estimates should come from the written scope, not from a generic figure.
What access and roles does the work need from our team?
You need three roles and they should be named before work starts. A Docker organization owner must be able to configure SSO, verify the domain and manage the SCIM token. Someone with control over DNS for your domain must add the verification record. An authentik administrator must create the SAML provider, application, bindings and any property mappings. The integration fails quietly if these people are unavailable at the same time, so agree on change windows. Ask for a list of the permissions each role needs and remove any access once the work is signed off.
Which authentik edition do we need for Docker SSO?
The Docker integration described in the authentik documentation works with the authentik platform and its standard SAML provider, so the open-source edition is the starting point for the protocol side. The edition question matters for your other needs. Google Workspace and Microsoft Entra ID integrations, mTLS, password history, enhanced audit logging and ticket-based support for subscriptions over $1k are listed as Enterprise features on the authentik pricing page at $5 per user per month billed annually plus $0.02 per external user per month. Confirm with authentik that the Docker configuration you plan uses only open-source features before you rely on that conclusion for procurement.
How are leavers deprovisioned after SCIM is enabled?
With SCIM, Docker receives provisioning and deprovisioning requests from authentik, so disabling or removing a user in authentik should remove their Docker membership after the sync runs. Without SCIM, SSO controls sign-in only, and a user may keep an active Docker seat until an owner removes them manually. Test the full leaver path, including the time between an authentik change and the Docker update, and check what happens to repositories and access tokens that the leaver owned. Document who owns the offboarding process, because a disabled authentik account does not revoke tokens that were already issued.
Do Docker pull limits change after we turn on SSO?
SSO itself does not change pull limits, but the plan does. Docker's usage documentation sets unauthenticated Docker Hub pulls at 100 per 6 hours per IPv4 address or IPv6 /64 subnet, and 200 per 6 hours for Docker Personal accounts. Pro, Team and Business accounts get unlimited pulls subject to fair use. Docker's pricing page describes Personal as 100 pulls per hour with reasonable use when logged in, which differs from the usage documentation, so confirm the enforced limit with Docker. Docker's February 21, 2025 blog post says future enforcement changes will be announced at least 6 months in advance, which is a useful checkpoint when you plan builds and CI runners.
How DeployOpen scopes and delivers the Docker SSO integration
DeployOpen scopes the Docker SSO integration in writing before any work starts, because the outcome depends on facts outside authentik. The written scope names the Docker organization, the Docker Business subscription the client already holds or plans to buy, the organization owner who will perform the Docker-side steps, and the domains to be verified. It also records who controls the authentik deployment, where it runs and which default teams and SCIM provisioning behavior the client expects. Because Docker's SSO and SCIM provisioning are listed only for Docker Business, the first scoping question is whether that subscription is in place, and the quote follows from the answers.
During planning, DeployOpen works through the verified domain and email matching checks that decide whether a user can sign in at all. Each user's authentik email must match their Docker account on a verified domain, so the plan inventories which addresses exist in authentik, which accounts already exist in Docker, and which users are on personal addresses that will not match. DeployOpen then implements and tests the authentik side in the client's own infrastructure, including the Docker SAML provider and application, the default team assignments and the SCIM settings, using a test user before any production group is switched on. Testing covers sign-in, the first-login behavior for new users, and removal of a leaver. Effort depends mostly on the number of domains, the state of existing Docker accounts and how many teams need mapping, and the client should ask the quote to show each of those items separately.
