How authentik signs Zoom users in over SAML
This integration uses SAML 2.0 with authentik as the identity provider and Zoom as the service provider, so a user who already signs in to authentik can reach Zoom without a separate Zoom password. SSO in Zoom depends on the account: it requires a Zoom Business, Education or Enterprise account with an approved vanity URL, according to the authentik integrations catalog. If your organization is on the free Basic plan or a Pro plan, stop here and confirm your subscription tier with Zoom before you plan any further work. The Zoom vanity URL is the company-specific sign-in address that Zoom uses for SSO, so it needs to be requested and approved in the Zoom admin portal before the SAML configuration can be finished. The work splits across two administrative consoles. In authentik, you create a SAML provider and application, set the signing certificate, define the Assertion Consumer Service and entity values that Zoom publishes, and decide which groups or policies may reach the application. In the Zoom web portal, a Zoom admin enters the identity provider metadata, enables SSO, sets the vanity URL and tests sign-in with a pilot account before enforcing it for everyone. Confirm with your Zoom account team which admin roles can change these settings, because a mistake in the Zoom portal can lock out every user on the account. This section concerns only that sign-in path. It does not cover Zoom Node, which is a separate on-premises appliance for hybrid media and recording, and it does not change where meeting media is processed.
What the Zoom account and authentik deployment need first
Zoom SAML sign-in depends on decisions made on both sides before any configuration begins. The Zoom account type, the vanity URL and the admin who can change SSO settings sit on the Zoom side, while the authentik version and its public HTTPS endpoint sit on yours. Confirm each card below before scheduling the build.
Zoom account type and plan
SSO in Zoom requires a Zoom Business, Education or Enterprise account, according to the authentik Zoom integration guide. Basic and Pro accounts are not enough for this build, so confirm the plan on the account that will own the SAML application before work starts. Ask Zoom whether your current contract includes the account type you need, because a plan change can alter billing and admin roles.
Approved vanity URL
Zoom SSO uses an approved vanity URL for your organization, so the sign-in path is tied to a company domain. Vanity URL approval and domain ownership checks are handled by Zoom, not by authentik or DeployOpen. Request the vanity URL early and confirm the approved value in writing, because the SAML configuration and user login paths depend on it.
Supported authentik version
Run a version that still receives security fixes. authentik's security policy lists 2026.5.x and 2026.8.x as supported, and it announces security releases at least 24 hours in advance. Choose one of those release lines, pin the exact patch version in your deployment files, and plan an upgrade path so you do not drift onto an unsupported line.
Public HTTPS endpoint for authentik
Zoom's SAML flow redirects browsers to your authentik instance, so authentik needs a stable, reachable HTTPS hostname that users and Zoom can resolve. Decide the hostname, the TLS certificate source and the reverse proxy in front of the server container before configuring the provider. Confirm that the certificate chain is trusted by browsers, since a broken chain blocks sign-in for every user.
Zoom admin role for SSO
Only a Zoom account administrator with rights to change account-level sign-in settings can enable SAML SSO and upload the identity provider details. Name that person before the build, confirm they can sign in to the Zoom web portal with their own account, and agree who keeps a second admin in place. Without this role, the authentik side can be ready while Zoom sign-in remains unchanged.
Test users and fallback access
Prepare a small pilot group in authentik and at least one Zoom account that can sign in with a password or another method if SAML fails. Keep a break-glass administrator in authentik and record how to reach it outside the SSO path. Verify these accounts before enforcing SSO for the full organization, so a misconfigured attribute does not lock every employee out of meetings.
Configuring the Zoom SAML application in authentik
This sequence connects authentik as the SAML identity provider to a Zoom account with a verified vanity URL, then confirms that a test user signs in and is created on first login. Each step ends with a check you can run before moving on.
Confirm the Zoom account and vanity URL
Before touching authentik, confirm with your Zoom administrator that the account is a Zoom Business, Education or Enterprise account and that an approved vanity URL is in place. The authentik Zoom guide lists these as prerequisites for SSO in Zoom, and the vanity URL becomes the company-specific sign-in address used in the SAML setup. Ask who holds the Zoom account owner or administrator role, because that person will complete the Zoom side. The step is done when you have the account type, the vanity URL and the name of the administrator in writing.
Create the SAML provider and application in authentik
In the authentik admin interface, create a SAML provider and an application that uses it, following the Zoom guide on the authentik integrations catalog. Set the ACS URL, audience and issuer values as the Zoom guide specifies for your vanity URL, and choose a signing certificate for the provider. Bind the application to a group or policy so only the intended users can start the flow. The step is done when the provider and application are saved and the provider shows a valid signing certificate.
Export the metadata and signing certificate
From the authentik SAML provider, export the metadata document and the signing certificate that Zoom will trust. Keep the file names and locations recorded so the Zoom administrator receives the same version you tested. If your authentik deployment uses a different hostname for its public endpoints, confirm that the metadata contains the public URLs users actually reach. The step is done when you can open the metadata file and find the entity ID, the SSO endpoint and the certificate, and the Zoom administrator confirms receipt.
Configure SSO in the Zoom admin portal
The Zoom administrator signs in to the Zoom web portal and enables single sign-on for the account, entering the identity provider details from the exported metadata or the values the Zoom guide lists. Use the vanity URL that was confirmed in the first step, and keep SSO in a test state until the first login succeeds if the portal allows it. Record which users, if any, keep password sign-in during testing. The step is done when Zoom saves the SSO configuration without validation errors and shows the vanity URL as the sign-in address.
Assign test users and check the NameID
Add one or two test users in authentik who belong to the group bound to the application, and make sure their email addresses match the accounts that will be used in Zoom. Sign in to the application as a test user and inspect the SAML response, either with an authentik event log entry or a browser SAML tracer. Confirm that the assertion arrives with the NameID format and value you configured, normally the user's email address. The step is done when the NameID in the assertion matches the expected value for each test user.
Run a first login and confirm provisioning
Sign in to Zoom through the vanity URL with a test user who has no existing Zoom account, then check whether Zoom creates the user on first login and which account type and role it receives. Compare the attributes Zoom received with the mapping you configured in authentik, including name and email fields. Repeat with a user who already has a Zoom account to see how the existing profile is matched. The step is done when the new user appears in the Zoom admin portal with the expected name, email and role, and the existing user signs in without a duplicate account.
Record the results and widen the rollout
Write down the tested NameID format, the attributes Zoom accepted, the account type and the role each test user received, and any errors seen during testing. Ask the Zoom administrator to confirm which users keep password sign-in and how administrators will recover access if the identity provider is unavailable. Only after these results are documented should you expand the authentik group bound to the Zoom application. The step is done when the test record is approved by the account owner and the rollout group is defined.
Mapping authentik attributes to Zoom user fields
This table compares each identity attribute authentik sends in the SAML assertion with the Zoom user field it should populate. Read it as a checklist: the email or NameID value must match the Zoom account email exactly, or the login will not bind to the intended user. Confirm the exact Zoom attribute names and mapping behavior in your own tenant before go-live.
| Attribute | Typical source in authentik | Zoom profile field | What to confirm |
|---|---|---|---|
| SAML NameID | Property mapping on the SAML provider, usually set to the user's email | Login identifier matched to the Zoom account email | Value matches the Zoom account email for every user, including case and domain |
| Email address | authentik user email attribute exposed through a SAML property mapping | Primary Zoom account email | Same address the user already holds in Zoom, or the account will not match on first login |
| First name | authentik user name attribute, split into given name claim | First name on the Zoom profile | Claim name Zoom expects, and whether first name is populated for all users |
| Last name | authentik user name attribute, split into family name claim | Last name on the Zoom profile | Claim name Zoom expects, and how users with single-word names are handled |
| Group or department | authentik group membership or a custom attribute mapping | Zoom group or department field, where supported for your plan | Whether Zoom reads this attribute on login and which Zoom plan supports it |
| Vanity URL and account type | Not sent in the assertion; set on the Zoom side | Account must be Business, Education or Enterprise with an approved vanity URL | Account type and approved vanity URL are in place before SAML is enabled |
| Certificate and signing settings | authentik SAML provider signing certificate and metadata | Zoom SAML configuration fields | Certificate in Zoom matches the one authentik signs with, and is renewed before expiry |
What happens to a user on first login
On the first SAML sign-in, the account that a user lands in depends on what already exists in the Zoom account for that email address. Before rollout, confirm with Zoom whether the user's email domain is verified and owned by your organization, because SSO only applies to users on domains the account controls. Confirm also whether users already exist with a password or a Zoom login. A user who already has a Zoom profile on the same address may be matched to that profile rather than given a new one, so you should check for existing accounts, shared addresses and personal Zoom accounts before you enable SSO. Confirm the account type with Zoom as well, since the SSO requirement in the authentik integration guide is a Zoom Business, Education or Enterprise account with an approved vanity URL. Ask Zoom exactly how first-login matching and user creation behave for your account type, and test with a small group of accounts first.
The authentik side decides which identity the user presents, so the email value sent in the SAML assertion must match the Zoom account's email exactly, including case and domain. Use an illustrative test: if authentik sends a username that differs from the address registered in Zoom, the user may be treated as a new account or refused, depending on Zoom's configuration. Check which attributes the Zoom SAML configuration expects, and verify them in a test login with a non-admin user before you move the wider group. SAML sign-in creates or matches the account at login time, but it does not remove, suspend or change roles on users, and it does not keep group membership in sync. That work belongs to SCIM provisioning, which is a separate configuration step with its own requirements. This page covers SAML sign-in only, so confirm with Zoom what happens to an account when a person leaves, whether the login is blocked, and whether the license or user record persists.
Hardening the authentik side of Zoom SSO
Zoom trusts whatever authentik asserts, so the identity provider is where most of the hardening happens. The cards below cover the SAML trust material, who can reach the Zoom application, the authentik release you run, the strength of the sign-in flow and the local sign-in path kept for emergencies. Work through them before you enable SSO for all users.
Signing certificate and rotation
The SAML signing certificate on the authentik SAML provider is what Zoom uses to verify that an assertion really came from your authentik instance. Confirm that assertions are signed, record the certificate expiry date, and check which certificate Zoom holds before you replace it. Plan the rotation as a two-step change, adding the new certificate on the Zoom side before authentik starts signing with it, so sign-in does not break on cutover day. Store the private key only in the authentik certificate store and restrict who can export it.
Restricting access with policies
Assigning the Zoom application to a group in authentik is the main control on who can sign in. Bind the application to a named group with a policy binding, and confirm that users outside that group receive an access denied page rather than a Zoom account. Remember that group membership in authentik does not remove an existing Zoom account, so review which accounts already exist in the Zoom admin portal and decide how leavers are handled.
Staying on a supported release
Run an authentik version that still receives security fixes. The authentik security policy names the supported release lines, and the project announces security releases at least 24 hours in advance, so assign someone to watch for those notices and schedule the update window. Check the authentik upgrade notes before moving to a new release line, since a sequential upgrade path may apply. A SAML provider on an unpatched identity server is a weak point in front of every Zoom user.
Enforcing MFA in the authentik flow
Zoom does not see the second factor that authentik checks, so MFA must be enforced in the authentik authentication flow before the SAML response is issued. Attach an MFA stage to the flow used by the Zoom application, and confirm that it runs for every user, including administrators. Test enrollment for users who have not yet registered a factor, and decide whether to block sign-in or prompt enrollment. Ask Zoom whether the account carries any setting that bypasses your IdP for specific roles.
Break-glass access to Zoom
Decide whether local Zoom password sign-in stays enabled for a small set of administrators. If authentik or the SAML trust fails, a locked-out Zoom tenant cannot be recovered without a local path, but a local password is also a route around MFA. Keep at most a few named break-glass accounts, store their credentials in a sealed vault, enable MFA on them, and alert on every use. Test the recovery procedure before go-live, and confirm with Zoom how the local sign-in option is turned on and off for your account type.
Why Zoom SAML sign-in fails and how to fix it
This table lists the failures most often seen when Zoom SAML sign-in is set up with authentik, with the likely cause and the fix for each. Check the rows in order, since account eligibility and vanity URL approval block the flow before any certificate or attribute check can succeed.
| Failure | Likely cause | Fix |
|---|---|---|
| Zoom rejects the SAML response with an ACS or entity ID error | The ACS URL or entity ID copied into the authentik SAML provider does not match the values Zoom shows for the account, often because of a typo, a trailing slash or a different vanity URL. | Copy the ACS URL and entity ID again from Zoom's SSO settings, paste them into the authentik provider exactly, and save before retesting. |
| Sign-in works once, then fails after a certificate change | The signing certificate in authentik was rotated or regenerated, but Zoom still holds the older certificate from the previous metadata upload. | Export the current signing certificate from the authentik provider, upload it to Zoom, and test with a single user before asking others to sign in. |
| Zoom cannot match the user to an account | The NameID or email attribute sent by authentik differs from the email address on the Zoom user, such as a different domain, casing or an alias. | Align the authentik user's email with the Zoom account email, then confirm the NameID format and attribute mapping in the SAML provider. |
| SSO option is missing or sign-in is refused for the domain | The vanity URL is not yet approved for the account, so Zoom does not enable SSO for that subdomain. | Confirm the vanity URL is approved on the Zoom account before configuring SAML, and ask Zoom support to approve it if it is still pending. |
| SSO cannot be enabled on the account | The Zoom account is not a Business, Education or Enterprise account, so the SSO setting is not available on that plan. | Check the account type in Zoom's admin portal and confirm the plan with Zoom before planning the SAML work. |
| Assertion rejected as expired or not yet valid | The authentik host clock or the Zoom side is out of sync, so the timestamps in the SAML assertion fall outside the accepted window. | Confirm the authentik host and its containers use correct time through NTP, then retry the login and check the logs for timestamp messages. |
Questions buyers ask before configuring Zoom SSO with authentik
What does Zoom SSO with authentik cost, and what drives the price?
The cost has three parts: the authentik edition, the Zoom plan, and the people time to configure and test. authentik's Open Source edition is free, but the pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month. Enterprise is only needed if you also want features such as SCIM-style provisioning from a directory, which the pricing page does not list as Zoom-specific, so confirm the provisioning need before you choose an edition. On the Zoom side, the pricing page lists Business and Pro per user per month, and SSO requires a Business, Education or Enterprise account, so check which plan your users already hold. Ask any partner for a fixed-scope quote that separates one-time configuration from recurring licence and administration costs.
How long does Zoom SSO setup take, and what can delay it?
The configuration itself is short, but the schedule depends mostly on the Zoom vanity URL approval. SSO in Zoom requires an approved vanity URL on a qualifying account, so request it first, because Zoom controls that approval and its timing. While you wait, build the authentik side: the SAML provider, application, and the attribute mappings for email, first name and last name. Then test with a small pilot group before switching the whole organization. Ask a partner to state the approval dependency and the testing window in the written scope.
What does our internal team need to provide before the work starts?
Prepare four things before work starts:
- A Zoom Business, Education or Enterprise account with admin access and the vanity URL request ready.
- A running authentik instance that you control, with an administrator who can create SAML providers and applications.
- The list of pilot users, their email addresses, and the groups that should be allowed to sign in.
- A decision on whether existing Zoom accounts will match the identities authentik sends, since Zoom matches users by email.
Also confirm who approves changes to the Zoom admin portal and who can test sign-in from outside the office.
Can our own team configure Zoom SSO with authentik without a partner?
Yes, if your team already runs authentik and has someone comfortable with SAML. The steps are documented in the authentik Zoom integration guide, and the work is mostly configuration in two admin consoles plus testing. A partner adds value when the team lacks SAML experience, must meet change control or evidence requirements, or needs the work fixed in writing with a test plan and rollback steps. Self-managed work carries the risk of misconfigured attribute mappings that lock users out, so plan a pilot and keep an administrator account that uses a separate sign-in path.
Does Zoom Node change how Zoom SSO with authentik is set up?
No. Zoom Node is a hardened appliance on your premises that hosts modules such as Meetings Hybrid, Recording Hybrid and Chat Hybrid, and some modules can keep Zoom media traffic inside your network. Sign-in is still handled through the Zoom account and its SSO configuration, so the SAML setup with authentik stays the same. Node does change where some traffic flows and how the platform is administered, so plan that work separately and confirm with Zoom which modules and plans apply to your organization.
What should we check after SSO goes live?
Check sign-in for each pilot group, confirm that new users land in the correct Zoom account and role, and verify that a user who should be blocked cannot sign in. Review the attribute values Zoom receives against what your directory holds, because a mismatch in email or name is the most common cause of duplicate or unusable accounts. Keep a documented rollback path, including how to reach Zoom with a local administrator account, and record who owns ongoing changes to attribute mappings after handover.
Who pays for ongoing Zoom and authentik costs after setup?
Recurring costs are the Zoom subscription per licensed user, any authentik Enterprise subscription per user, and the internal time to run the identity platform, handle joiners and leavers, and review access. One-time costs are the configuration, testing and documentation. Ask for a quote that states both separately, and confirm whether the authentik hosting and upgrade work sits with your team or inside a retainer. Confirm Zoom pricing with Zoom directly, because the pricing page lists plans and billing terms that can change.
What this integration does not cover
This page covers SAML sign-in to Zoom with authentik as the identity provider. It does not cover Zoom Node, the on-premises appliance that hosts modules such as Meetings Hybrid, Recording Hybrid and Chat Hybrid, and it does not cover Zoom Phone. Those products have their own licensing, administration in the Zoom web portal and network design, and an authentik SAML application does not configure any of them. If your plan includes Zoom Node or a hybrid media path, scope that work as a separate project, because the questions it raises (where media flows, what the appliance can reach, who administers updates) are not answered by the sign-in configuration described here.
Recording storage and data routing are also outside this page. Zoom's recording formats (MP4, M4A, TXT, VTT and CC.VTT files) and the data center region settings that admins of paid accounts can change for meeting and webinar data in transit are controlled inside Zoom, not in authentik. Region settings do not cover Zoom Phone, and participants joining from an excluded region can still join. Confirm the current region options, retention behavior and download permissions in Zoom's account settings and Zoom's documentation before you write a data handling position, since a SAML login does not change where recordings are stored.
Provisioning is a separate decision. This page covers how users are created on first login, but SCIM provisioning and deprovisioning of leavers are not covered here. Before you rely on automatic removal of accounts when someone leaves, check Zoom's current documentation for SCIM support on your account type, the required admin roles and any plan conditions, and test a deprovisioning event in a non-production Zoom account. Until that check is complete, plan manual account review as the fallback for offboarding.
