authentik and Zammad SSO integration

How authentik signs Zammad users in over OIDC or SAML

If you run a self-hosted Zammad helpdesk, you probably want agents and customers to sign in with one set of credentials managed by authentik instead of keeping a separate Zammad password for each person. authentik's integrations catalog documents both OpenID Connect and SAML for Zammad, and Zammad's admin documentation confirms that third-party login works through SAML and OpenID Connect, among other providers. In practice, authentik acts as the identity provider: Zammad redirects the browser to authentik, the user authenticates there under your flows and policies, and authentik returns an assertion or token that Zammad uses to log the user in. The exact provider settings, redirect and callback URLs, and certificate or client values come from the authentik Zammad guide and Zammad's third-party application settings, so copy them from those sources rather than from memory, and confirm them against the Zammad version you run.

Before you build anything, decide which protocol fits your setup. OpenID Connect is usually the simpler path when authentik issues tokens with the claims Zammad needs, such as a stable subject identifier, email address and display name. SAML is the better fit when your wider estate already runs on SAML assertions and you want one federation model for every application. Whichever you pick, settle the identifier first: the claim or NameID that Zammad uses to match an existing account decides whether a returning user lands in their old profile or gets a duplicate. Plan the attribute mapping on paper, including which authentik user attributes populate the Zammad email, login and firstname and lastname fields, and whether Zammad should create accounts automatically on first sign-in. Automatic account creation is convenient, but it also means that anyone who can authenticate in authentik gets a Zammad account, so tie it to the groups or applications you intend to allow.

What you need in place before the authentik Zammad SSO setup

Both systems need to be in a known-good state before you touch a single login setting. Confirm the release lines, the supporting services and the hostnames first, because most failed SSO attempts trace back to one of these foundations.

authentik release line

Run a release line that still receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as supported, and 2026.8.4, published on October 14, 2026, is the latest release on the GitHub releases page. Check your running version against those lines before you add a Zammad application, and plan the upgrade path if you are on an older line. Confirm the exact version in your own environment rather than assuming it.

Zammad release line

Choose between the 7.2 line and the 6.5 line and run the latest patch in that line. Zammad 7.2.2 was released on 8 October 2026, and security release 6.5.5 followed on 15 October 2026. Confirm the SAML or OpenID Connect settings you plan to use exist in your installed version's admin interface, since the login options are part of the application you are configuring.

PostgreSQL and Redis versions

Zammad stores its content in PostgreSQL 15 or newer and requires Redis 7 or newer for realtime websocket communication. Verify both versions on the Zammad host or container before the SSO work starts. Note that authentik itself no longer uses Redis, so your Redis instance serves only Zammad, and its availability affects how quickly agents see live updates after sign-in.

Reverse proxy and HTTPS hostnames

Pick the public hostnames for Zammad and authentik and issue certificates that both systems trust and can reach from each other. Zammad supports Nginx or Apache as the reverse proxy. Confirm that the authentik issuer URL and the Zammad callback URL resolve from the browser and from the Zammad server, since the token exchange happens server to server. Mismatched schemes or hostnames are the most common cause of redirect errors.

Admin accounts on both sides

Keep a local administrator account in Zammad that does not depend on SSO, so you can recover if the identity provider settings break. On the authentik side, use an administrator who can create providers, applications and property mappings, and record who owns the change. Confirm that the Zammad administrator can access the security settings where third-party login is configured.

Test user group and sample accounts

Create a dedicated authentik group for SSO testing with one agent account and one customer account. Keep both accounts out of production groups until attribute mapping and automatic account creation behave as expected. Confirm which email address and name each test user carries, because Zammad matches and creates accounts using those attributes and mismatched values produce duplicate users.

Choosing OpenID Connect or SAML for Zammad

OpenID Connect suits a team that wants the lighter setup path and is not already invested in SAML. The client is registered with a client ID and secret, the identity information arrives as claims in an ID token, and the browser flow is built on standard OAuth 2.0 authorization code exchange. For Zammad, this usually means fewer moving parts on the application side because there is no signing certificate to exchange and rotate by hand.

Client registration: Zammad receives a client ID and secret from authentik, which is simpler to copy and rotate than a metadata document.
Callback URL: Zammad expects a redirect URI on its own hostname, so the external URL configured in Zammad must match the one registered in authentik exactly, including scheme and path.
Certificates: There is no SAML signing certificate to manage on the Zammad side, although TLS on both hostnames still matters.
Attributes: Name, email and group values come from standard and custom claims in the token, so the scope and claim mapping in authentik define what Zammad receives.
Account matching: Confirm which claim Zammad uses to match or create the account, since email changes upstream can create duplicate customers.

Confirm in the authentik Zammad guide which OpenID Connect options the current release exposes before you copy any values.

Setting up authentik Zammad SSO step by step

This sequence takes you from an authentik provider for Zammad to a tested login for agents and customers, with automatic account creation switched on only after those tests pass.

Choose the protocol and confirm prerequisites
Decide between OpenID Connect and SAML before building anything, using the comparison in the decision section of this page. Confirm the public HTTPS hostname that users will type into the browser for Zammad, the Zammad version you run, and who in your team will own the authentik and Zammad administration. Ask your Zammad administrator to confirm that the third-party login settings are reachable from an admin account. The step is done when you have written down the protocol, the public Zammad hostname and the named owners, and a test admin account can open Zammad's settings.
Create the authentik provider and application
In authentik, create an OAuth2/OIDC or SAML provider for Zammad, then create an application that uses it, following the Zammad guide in the authentik integrations catalog. Set the redirect or assertion consumer URL to the public Zammad hostname, not an internal address or a container name, because the identity provider sends the browser back to that exact value. Assign only the groups or users who should be able to sign in. The step is done when the application appears in the authentik library and a test user assigned to it can see the Zammad tile in the user interface.
Record the issuer or metadata values
Copy the values Zammad needs from authentik: for OpenID Connect, the client ID, client secret and issuer URL for the application; for SAML, the metadata document or the issuer, signing certificate and single sign-on URL. Store the client secret in your secrets manager rather than in a shared document. Check each value by opening the issuer or metadata URL in a browser from the Zammad host and confirming it loads without a certificate error. The step is done when the values are recorded and the metadata or discovery endpoint responds from the Zammad server.
Configure the matching third-party login in Zammad
In Zammad's administration settings for third-party applications, enable the OpenID Connect or SAML option that matches the provider you built, and paste the recorded values into the fields. Keep automatic account creation switched off at this stage, so the first test cannot create accounts unexpectedly. Save the configuration and confirm the login button for the provider appears on the Zammad sign-in page. The step is done when the button is visible to an unauthenticated browser and the settings save without validation errors.
Test agent and customer sign-in with existing accounts
Use a test agent account that already exists in Zammad, and a test customer account if you serve customers through the same instance, to sign in through the authentik button. Confirm that the browser returns to the public Zammad hostname, that the session opens, and that the agent sees the agent interface and the customer sees only the customer portal. Check the Zammad user record afterward to confirm it matched the existing account by the expected identifier, such as email address. The step is done when both test logins succeed and no duplicate user record was created.
Enable automatic account creation after the tests pass
Once existing-account logins behave correctly, turn on automatic account creation in the Zammad settings for the provider. Then sign in with a new test user from authentik who has no Zammad account, and confirm that one is created with the expected role and email address. Review the created user record in Zammad's user administration, including roles, groups, organization and the attributes mapped from authentik. The step is done when the new account exists with the correct attributes and you have written down any attribute that did not map as expected.
Review attribute mapping and lock down the rollout
Compare the mapped attributes in the created test record against the attribute mapping you planned, and correct the authentik property mappings or Zammad settings where role or name values are wrong. Remove the test accounts from production groups, document the final redirect URL, client settings and owners, and restrict the authentik application to the groups allowed to sign in. Confirm the setup again after any authentik upgrade or Zammad upgrade by repeating the agent and customer test. The step is done when a written record of the final configuration exists and the repeat test passes on the production hostname.

Mapping authentik attributes to Zammad accounts

This table lists the identity fields the authentik and Zammad integration has to carry, the authentik source for each one, and the Zammad field it fills. Use it as a checklist for the guide and for a test account, since the exact claim and attribute names must be confirmed in the authentik Zammad guide and Zammad's third-party documentation before you build the mapping.

Identity field	authentik source	Zammad field	Confirm in guide and test account
Unique identifier (login or email)	Username or email attribute on the authentik user, sent as the subject or mapped claim	Login or email on the Zammad user record	Confirm which claim is used as the unique key and that a second login with the same value matches the same account
Email address	Email attribute on the authentik user	Email field on the Zammad user	Confirm the claim name and that the address is verified before it is used to match an existing customer or agent
First name	Given name attribute on the authentik user	Firstname field on the Zammad user	Confirm the claim or attribute name and that a blank value does not overwrite an existing name
Last name	Family name attribute on the authentik user	Lastname field on the Zammad user	Confirm the claim or attribute name and how Zammad handles a missing last name
Group or role membership	Group names or a role claim sent by the authentik provider or scope mapping	Zammad group and role assignment (agent or customer access)	Confirm whether Zammad maps groups automatically or only assigns a default role, and test one agent and one customer account
Authentik user identifier	Stable internal ID (UUID or pk) if the guide sends it	Stored external identity reference on the Zammad user, if supported	Confirm the guide uses this value and that it stays stable when a username is renamed in authentik
Automatic account creation	Users who sign in for the first time, plus the attributes above	New Zammad user created on first login	Confirm whether new users are created automatically or only after an admin approves them, and which role they receive by default

What automatic account creation changes for agents and customers

Automatic account creation decides who becomes a Zammad user and what role they get, so it is a access control decision, not just a convenience. When authentik creates a Zammad account on first sign-in, every identity that authentik lets through the Zammad application can end up with an account. Manual administration drops away, but the question of who may sign in moves into authentik's application access bindings and group rules. Before you enable creation, decide which authentik groups correspond to Zammad agents, to administrators and to customers, and confirm that the attribute mapping sends those groups into the role logic you expect. Treat the mapping as part of the design, not a setting to fill in later.

The main risk sits with customers. If the Zammad application is bound to a broad set of authentik users, or to a group that includes people who are not customers, any authenticated identity can become a customer account and open tickets under that identity. Keep agent and administrator access on a narrow, separately managed group, and check that the default role for new accounts is the least privileged one. Also decide what happens to existing local Zammad accounts that share an email address with an incoming identity. Confirm in a test instance whether the sign-in matches the existing account or creates a second one, because duplicate accounts split ticket history and ownership. Review the current behavior against the authentik integrations catalog entry for Zammad and your Zammad version's third-party login settings.

Test before you open sign-in to everyone. Create one agent test user and one customer test user in authentik, sign each in through the chosen protocol, and inspect the resulting Zammad roles, group memberships and organization assignment. Repeat the test with a user who already has a local Zammad account using the same email address, and record whether it was matched or duplicated. Only after those three results match your design should you widen access to the full agent group or the customer population. Keep the test accounts and the decision record, because they are the evidence you will need when you review the mapping after the next Zammad or authentik upgrade.

Hardening the authentik to Zammad sign-in

A working SSO connection is not the same as a hardened one. The controls below cover transport, access scope, break-glass recovery, second factors and release currency, and each one closes a gap that a single misconfiguration can open between authentik and Zammad.

HTTPS for both hostnames

Serve authentik and Zammad over HTTPS only, with valid certificates on both hostnames and a renewal process someone owns. The redirect URIs, issuer URL or SAML endpoints registered in authentik must match the public HTTPS addresses exactly, so a certificate lapse or a mixed-scheme callback can break sign-in for every agent at once. Confirm renewal alerts reach a team, not one person's inbox.

Limiting who can sign in

Bind the Zammad application in authentik to a group or policy so that only the agent and customer populations meant for it can authenticate. Without this, every authentik user who can reach the application may be able to create an account on first login, depending on your enrollment settings. Test with a user outside the permitted groups and confirm the attempt is denied.

Break-glass local admin

Keep one local Zammad administrator account with password login available, stored in a sealed credential vault and tested on a schedule. If the authentik connection, certificate or identity provider fails, this account is how your team restores service. Document who may use it, when, and how each use is logged and reviewed afterward.

Multi-factor for agents

Require a second factor in authentik for agent groups before they reach Zammad, since agents hold access to customer data and internal ticket history. Enforce the factor in the authentik authentication flow for those users rather than relying on the helpdesk's own settings. Confirm which factor types your agents can enroll and how account recovery works when a device is lost.

Supported release lines

Run authentik on a release line listed as receiving security fixes, and run Zammad on a line that is still getting security updates. Zammad published security releases on both its 6.5 and 7.x lines in the same month, so do not assume one line is safe because another is current. Subscribe to both projects' release notices, since authentik gives at least 24 hours' notice of security releases, and plan a window to apply them.

How to test authentik Zammad SSO before agents depend on it

Run the test plan in a staging instance of Zammad and authentik before any agent or customer signs in through the new path. The core of the plan is a set of named test cases, each with a recorded result: a successful login for each role you intend to map (agent, administrator and customer, if customers also sign in through authentik), a denied login for a test user who sits outside the permitted authentik group, and a check that the user's role and group memberships in Zammad match what the attribute mapping was designed to produce. Use one test account per case so a failure points to a single cause. Confirm in your own environment how the Zammad side handles a user who is denied at authentik, since that user should never create a Zammad account.

Add three checks that teams often skip. First, logout and session behavior: sign out of Zammad and confirm whether the authentik session also ends, then confirm that a second browser cannot keep working after the test user is disabled or removed from the group. Second, a login after a password change in authentik, which verifies that the account still matches on the same identifier after the credential changes. Third, a rollback test that re-enables local Zammad login and confirms that a pre-existing local administrator can still sign in. Write down the exact steps needed to restore that local login before go-live, because an SSO misconfiguration without a working fallback can lock out every agent.

Treat testing as recurring work, not a one-time gate. Repeat the full plan after each Zammad upgrade and each authentik upgrade, and after any change to the provider, redirect settings or attribute mapping. For every run, record the authentik version and the Zammad version under test, the protocol used (OpenID Connect or SAML), the test accounts and the outcome of each case. Check the current authentik integration guide for Zammad against your configuration at each run, because the steps it documents may change between releases. Keep the run records with your change log so that a future failure can be traced to the version change that caused it.

Common authentik Zammad SSO failures and their fixes

This table lists the failure points most often seen when authentik signs users in to Zammad, with the likely cause and the first check for each. Work through the rows in order, because a wrong public hostname or proxy setting can make later checks look like identity problems.

Failure point	Likely cause	First check
Redirect or callback URL mismatch	The redirect URI registered in the authentik provider does not match the public Zammad hostname, including scheme, host and path.	Compare the redirect URI in the authentik provider with the callback address Zammad uses, character by character, and confirm the hostname matches what users type in the browser.
Certificate or metadata mismatch after rotation (SAML)	The signing certificate or metadata in Zammad was replaced in authentik, or the old metadata was kept after a rotation.	Re-download the current metadata from authentik and confirm the certificate in Zammad matches the active signing certificate on the authentik SAML provider.
Missing or wrong claim or attribute	authentik does not send the email, login or name attribute that Zammad expects, or the attribute name differs from the Zammad mapping, so account creation fails.	Inspect a test login's returned claims or assertion attributes and confirm the names and values match the Zammad third-party login mapping.
Wrong role after sign-in	Group mapping is incomplete, so users who belong to the right authentik group receive no matching Zammad role or fall back to a default role.	Check that the group claim is sent, that the group names match exactly, and that the role assigned in Zammad corresponds to each group expected for agents and customers.
Wrong URLs built behind a reverse proxy	The proxy changes the host or scheme (for example, HTTP to HTTPS), so Zammad generates links and redirects that point to the internal address.	Confirm the proxy forwards the public host and protocol headers, and check that the Zammad public URL setting matches the address users reach.
Duplicate accounts from an existing local login	A user already has a local Zammad account with the same email address, and the SSO login creates a second account instead of linking to it.	Search Zammad for the user's email address before the SSO test, and decide whether existing accounts should be linked or merged before enabling automatic account creation.

What authentik Zammad SSO costs and what it needs from your team

Does authentik and Zammad SSO carry a license fee?

Not for the integration itself. Self-hosted Zammad has no license fee, and the optional self-hosted support subscriptions are Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to Zammad's pricing page. authentik Open Source is free to use, and its code is under the MIT license for most of the repository. The OpenID Connect and SAML configuration for Zammad is available in the community edition, so you do not need an Enterprise subscription for this integration. Confirm the current edition terms on the authentik pricing page before you commit, since Enterprise is priced per user and per external user.

How long does an authentik Zammad SSO integration take?

Duration depends mainly on how many roles and groups must map to Zammad permissions, how many environments you stage, and whether your reverse proxy needs changes. A single protocol with one group mapping and a staging test is a short task, while a multi-group model with customer and agent separation, plus reverse proxy work, takes longer. A written scope should state the environments, the protocol, the number of mappings and the test cases, so the timeline follows from those items. Ask any provider to show how each of those factors changes the plan.

What drives the cost of this integration up or down?

The main cost drivers are the protocol choice, the number of role and group mappings, the staging effort, and the reverse proxy changes.

Protocol: OpenID Connect and SAML both work with the authentik guide, but SAML certificate exchange and attribute mapping add steps.
Mappings: each group that decides agent or customer rights adds rules to build and test.
Staging: a separate test instance of authentik and Zammad lets you verify logins before production cutover.
Reverse proxy: Zammad needs Nginx or Apache in front of it, and redirect URLs must match the public hostname.

Fewer mappings and a single environment reduce effort. More roles, multiple Zammad instances or a new proxy design increase it.

Can an internal team set up Zammad SSO with authentik alone?

Yes, if your team already operates both platforms and has someone who can read identity and proxy configuration. The authentik integrations catalog documents both OpenID Connect and SAML methods for Zammad, so the steps are published. The risk lies in the details: claim names, redirect URLs, automatic account creation rules and the rights a new user receives at first login. Teams without recent authentik or Zammad experience often test these on a staging system first, so budget for that test before a production change.

What does the identity team need to provide for this work?

The identity owner must supply the authentik administrator access, the group structure that identifies agents and customers, and the attribute names your users carry, such as email and display name. They also decide which authentik groups should create Zammad accounts automatically and which accounts should stay local. The helpdesk owner must confirm the public hostname, the agent and customer roles in Zammad, and any existing local accounts that need to be linked or kept. Both owners should agree on the test users before the work starts.

What should the helpdesk team need to provide?

The helpdesk owner needs to provide administrator access to Zammad, the list of roles and groups that agents and customers hold today, and the target deployment method, such as package installation, Docker Compose or the Kubernetes Helm chart. They should also confirm whether Elasticsearch, Redis and Memcached are already in place, since those affect the environment being tested. Support scope also matters: Zammad's Kubernetes support covers only the application, so platform issues need a separate owner.

What should a quote for this integration include?

A quote should follow a written scope and list the protocol, the number of environments, the group and role mappings, the automatic account creation rules, the reverse proxy changes, the test cases and the handover items. It should name what is one-time work, such as configuration and testing, and what recurs, such as upgrades or support retainers. Ask for the assumptions behind each line, including which Zammad and authentik versions are targeted and what the client must provide. DeployOpen provides quotes based on a written scope, so the scope document is the basis for any price.

How DeployOpen scopes and delivers authentik Zammad SSO

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For authentik and Zammad SSO integration, we start from a written scope that fixes the protocol choice, the attribute mapping and the account creation rules before any configuration begins.

How we scope

Confirm whether agents, customers or both sign in, since that decides login rules and account creation.
Record the protocol decision between OpenID Connect and SAML, with the reasons and the Zammad settings each path needs.
Agree the attribute mapping for email, name, login and group or role claims in the written scope.

How we build

Configure the authentik provider and application for Zammad using the documented OpenID Connect or SAML method.
Set Zammad third-party login, redirect or assertion URLs and automatic account creation to match the agreed scope.
Test agent and customer sign-in paths, including existing local accounts, before any user population is switched over.

How we hand over

Deliver written configuration records covering authentik, Zammad settings, mappings and the chosen protocol.
Document the test cases used, their results and the known limits of the attribute and group mapping.
Walk your administrators through routine changes such as certificate or secret rotation and adding new roles.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and testing are available as a retainer, including checks after Zammad and authentik releases.
Ask for a quote based on the written scope, which sets out the one-time build work and any recurring support.