> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/admin-corner/account-and-endpoint-management/sso-field-guide.md).
# SSO Field Guide
## Introduction
Integrating single sign-on (SSO) with Zoom offers administrators user management and security options that can simplify account management. Once configured, users authenticate using their company credentials against your company’s identity provider instead of using alternative authentication methods like Oauth through a third-party app or a direct username and password with Zoom.
This document provides a comprehensive overview of SSO configurations and settings within Zoom, in addition to troubleshooting and security information.
## Configuring SSO
#### SSO Requires a Vanity URL to get started
An account must have an approved vanity URL before configuring SSO. Once the Vanity URL is approved, Zoom administrators can access the [SSO configuration](https://zoom.us/account/sso) page through the advanced options submenu on the web portal. Refer to our support article on [Vanity URLs](https://support.zoom.us/hc/en-us/articles/215062646-Guidelines-for-Vanity-URL-requests) for more information.
#### Zoom SSO works with any SAML 2.0 or OIDC identity provider
Zoom can integrate with any identity provider that supports Security Assertion Markup Language (SAML) 2.0 or OpenID Connect (OIDC) authentication.
#### Zoom administrators can manage user profile information and licensing through response mapping or SCIM integrations
Administrators can manage user profile information and licensing through response mapping or System for Cross-Domain Identity Management (SCIM) Application Programming Interface (API) requests, depending on the features available from the identity provider. Both user management methods offer near-equal functionality for profile information mapping and licensing management, but some SCIM mappings require manual configuration.
For a comprehensive list of SCIM capabilities, refer to our [SCIM API documentation](https://developers.zoom.us/docs/api/?ampDeviceId=157cfe5d-7f7a-45eb-afb0-efde5a7d3feb\&SessionId=1778697171616).
#### Zoom administrators can manage user account status through SCIM, but not SAML or OIDC
Because SCIM allows identity providers to communicate directly with Zoom at any time, user accounts can be *activated*, *deactivated*, *created*, or *deleted* through SCIM integrations automatically. For example, if a user’s account in Active Directory is disabled, or if they are unassigned the application, SCIM can send an automatic deactivation request for the user’s account within Zoom. This feature is dependent on the capabilities of the identity provider’s SCIM application and functionality may vary by provider.
#### Limited identity providers offer SCIM for Zoom
Many identity providers do not have a SCIM integration built for Zoom as a part of their services. Accounts using an identity provider that does not support SCIM with Zoom must use response mapping for automated user management.
#### SCIM requires an associated domain to automatically provision users
Accounts that use SCIM to manage and provision users for SSO **must** associate the email domain with Zoom. Failure to associate the domain will result in user provisioning failures. Refer to our support article on [Associated Domains](https://support.zoom.us/hc/en-us/articles/203395207) for more information on the process.
### SAML Configuration Guide
The following links include guides for configuring SSO with SAML.
{% hint style="success" %}
**Zoom Tip**
Click the ✔ in the Provider or Zoom Documentation column to open a new window to instructions.
{% endhint %}
If the identity provider your business utilizes is not listed above, we recommend searching the provider's knowledge base for a Zoom-specific integration guide. If one is not available, SSO can still be configured by matching key identifiers from your IdP within Zoom's SSO configuration screen. Refer to Zoom's support center for more information on a [quick start guide to SSO](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060673) and what information is required to complete this process.
### OIDC Configuration Guide
Zoom supports OIDC discovery, which can automatically populate common identity provider details such as the issuer, authorization endpoint, token endpoint, and signing keys. Because OIDC relies on standardized configuration values, provider-specific Zoom documentation is generally not required; when discovery is unavailable, the necessary values can be entered manually.
As a result, standards-compliant OIDC identity providers can generally be configured with Zoom even when a provider-specific integration guide is unavailable. Refer to Zoom's support center for more information on [configuring OIDC SSO](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0083701).
### Additional Configuration Options
#### Zoom can support multiple Vanity URLs and/or multiple identity provider applications
Zoom accounts can support multiple Vanity URLs, multiple identity provider (IdP) configurations, or a combination of both. Supported configurations include:
* Multiple Vanity URLs that share a common IdP configuration.
* Multiple Vanity URLs, each with an independent IdP configuration.
* A single Vanity URL associated with multiple IdP configurations.
These configurations are enabled through Zoom Support and are not configured through the standard SSO administration interface. Submit a [support request](https://support.zoom.com/hc/en/contact?id=contact_us) to enable this feature, along with the desired Vanity URL and IdP configuration and the intended authentication outcome.
{% hint style="info" %}
**Note**
OIDC authentication does not currently support multiple Vanity URLs or IdPs. If you are not sure if this situation applies to you, speak with your Zoom account team for more information.
{% endhint %}
#### On-premises Active Directory can use the AD Sync Tool instead of SCIM
Accounts that want to automate user provisioning through SCIM but do not have a cloud-based identity provider can use the Active Directory (AD) Sync Tool application developed by Zoom for managing their users. This application runs on Oracle JDK 8 and simulates SCIM provisioning by managing users through API commands. See our support article on the [AD Sync Tool](https://support.zoom.us/hc/en-us/articles/115005865543-Managing-the-AD-Sync-Tool) for more information.
{% hint style="success" %}
**Zoom Recommendation**
The AD Sync Tool requires precise configuration for user management. Thorough testing and review of the tool’s configuration is required before full implementation to avoid service disruption.
{% endhint %}
#### Identity providers can even authenticate meeting participants that don't have a Zoom account
Accounts that want to require users to authenticate their identity but do not wish to provide Zoom accounts can configure an external authentication profile with their identity provider. When enabled for a meeting, users who attempt to join must authenticate their login credentials against your identity provider to gain access. This is a common configuration for schools that do not provide accounts to all students but require authentication to join classes. Refer to our support article on [configuring external authentication](https://support.zoom.us/hc/en-us/articles/360053351051-Configuring-external-authentication-for-K-12-schools) for more information.
#### Changing the identity provider requires re-configuring SSO within Zoom
Accounts that are changing identity providers must redo their SSO configuration within Zoom. This includes updating all fields within the configuration page to match their new identity provider. Accounts are encouraged to confirm that response mappings will not change with the new identity provider.
No additional configurations or changes should be required, assuming there are no further changes.
#### Customers with sub-accounts can configure SSO from the master or sub-account
Customers with sub-accounts have two options for configuring SSO:
1. All users authenticate using the master account’s Vanity URL and are automatically logged into the sub-account through advanced response mapping ([some mapping limitations apply](#mapping-users-to-a-sub-account-will-only-apply-a-meeting-license-and-add-ons))
2. Each sub-account has a unique Vanity URL and independent SSO configuration, used exclusively by members of that sub-account
Each configuration offers unique benefits, with the second option offering the most flexibility. Customers considering implementation of either configuration should discuss with their account team which configuration is best suited for their needs.
## Provisioning Methods
#### Provisioning modes and SCIM are two different mechanisms, and they can be used together
Provisioning *At Sign-In* and *Prior to Sign-In* are the two available values of a single SSO setting. They govern whether Zoom will create an account for a user at the moment they authenticate, or require that the account already exist. SCIM is not a third value of that setting — it is a separate, API-driven mechanism that provisions users independently of authentication, and it operates alongside whichever provisioning mode is selected.
| Provisioning Method | How It Works | Prerequisites | Creates Accounts | Deactivates Accounts |
| -------------------------------------------------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------- | ------------------------------- |
|
At Sign-In (Just-in-time)
| Creates the account when the user first authenticates | None | Yes | No |
|
Prior to Sign-In (Pre-provisioning)
| Verifies a user is authorized to sign-in via SSO | An account with the SSO login type. Often used with SCIM provisioning. | No, but is often used with SCIM | No, but is often used with SCIM |
| **SCIM** | Syncs user data from the identity provider on its own schedule via APIs | IdP SCIM support and an associated domain | Yes | Yes, if supported by the IdP |
### At Sign-In
#### Provisioning at sign-in creates the account and the SSO login type in a single step
With the *At Sign-In* setting (also known as just-in time provisioning), a user who is assigned the Zoom application within the identity provider and who receives any supported Zoom license will have an account created for them the first time they authenticate. Nothing has to exist in Zoom beforehand. This makes it the simplest option to stand up, and the reason it is recommended when first configuring SSO on an account.
Provisioning at sign-in is also compatible with SCIM — the two can run at the same time. In practice, however, SCIM usually removes the need for it, because accounts already exist by the time a user authenticates for the first time.
### Prior to Sign-In
#### Provisioning prior to sign-in depends on something else having created the account or login type first
The *Prior to Sign-In* setting (also known as pre-provisioning) does not provision anything automatically. Instead, it enforces a condition: a user may authenticate only if their Zoom account already exists and carries the SSO login type. Something else must therefore be responsible for creating those accounts, and there are two practical options.
* **SCIM provisioning**, which creates accounts automatically from the identity provider as users are assigned the application.
* **Bulk CSV upload** with the *SSO User* option selected, which creates accounts and applies the SSO login type in a single import.
This is why pre-provisioning and SCIM are so frequently paired. Pre-provisioning states a requirement; SCIM is the mechanism that satisfies it at scale.
Zoom Administrators can confirm whether an account has an SSO login type by viewing the user account on the [User Management](https://zoom.us/account/user#/) page within the web portal and looking for the “SSO” icon underneath the user’s email.
Location of the SSO icon under a user's email.
If the icon is present, the user is provisioned for SSO; if the icon is missing, the user will not be able to sign in via SSO while pre-provisioning is enabled until it is added. A Zoom administrator can add this login type by adding users in bulk via a CSV file and selecting the “SSO User” option or have the user authenticate while Provision at Sign-in is enabled.
Example showing the SSO User option for bulk uploading.
### SCIM
#### SCIM provisions users through APIs and never asserts identity values like SAML or OIDC
SCIM differs from response mapping in a way worth stating plainly. Response mapping — whether through SAML assertions or OIDC claims — carries user information *as part of an authentication event*. Nothing is applied until the user signs in, and the information travels inside the assertion.
SCIM carries no assertions or claims at all. The identity provider calls Zoom's API directly on its own schedule, sending user information whether or not the user has ever signed in. This is what allows SCIM to create, update, deactivate, and delete accounts without user involvement, and it is why SCIM can manage account status while response mapping cannot.
SCIM is compatible with either provisioning mode, and is most often deployed alongside pre-provisioning.
Refer to the [SCIM for Entra ID and Okta Field Guide](/admin-corner/account-and-endpoint-management/scim-guide.md) for more information on configuring SCIM for your account with either Entra ID or Okta.
{% hint style="success" %}
**Zoom Recommendation**
When configuring SSO and SCIM together on a new account, enable *Provisioning at Sign-In* first. It helps guarantee that users can authenticate while the SCIM integration is still being validated. Once you have confirmed that SCIM is creating accounts with the SSO login type applied, switch to *Prior to Sign-In* if the tighter control is wanted.
{% endhint %}
## Security Settings
#### Zoom administrators can enforce automatic logout after a defined length of time
Zoom administrators can configure Zoom to automatically log users out of active sessions after defined lengths of time, customizable from 15 minutes to 180 days. This process will set the Zoom access token to expire at the predetermined length once the token is generated. This token has no relationship to an identity provider and is unique to Zoom.
#### A domain must be associated and managed to enforce SSO authentication
Zoom administrators can enforce SSO authentication *only* if the email domain is associated and managed within Zoom. When this is enabled, all users authenticating using your company domain(s) will be automatically redirected to your identity provider’s authentication page, regardless of platform.
Once the domain is approved and managed, a Zoom administrator can enforce SSO authentication through your account’s [security page](https://zoom.us/account/setting/security) under **Sign-in Methods**. Refer to our support article on [Associated Domains](https://support.zoom.us/hc/en-us/articles/203395207) for more information on associating and managing a domain.
#### Specified users can be exempt from enforced SSO authentication
Zoom administrators can exclude specific users from enforced SSO authentication. Excluding specific users (such as an admin account) may be useful if an SSO configuration breaks and an account administrator needs non-SSO access to the Zoom account. Admins that are exempt can sign into admin.zoom.us at any time in the event of an account lockout or broken SSO configuration (user must have the standard **admin** role). If a Zoom admin cannot access the account, they must contact Zoom Support for assistance.
To enable a user exception, navigate to the account [security page](https://zoom.us/account/setting/security) on the web portal under advanced options, locate the list of enforced domains, and add an exception through the edit list.
Example of domain list for SSO.
#### Mobile and desktop clients can be configured to require users to use SSO authentication
Zoom clients can be preconfigured to automate SSO functionality, including automatic login, automatic logout, SSO-only authentication on the device, and more through Group Policy, mobile device management (MDM) services, and mass deployment clients.
For a complete list of configuration possibilities, refer to our configuration options for [Group Policy](https://support.zoom.us/hc/en-us/articles/360039100051), [iOS](https://support.zoom.us/hc/en-us/articles/360022302612-Using-MDM-to-configure-Zoom-on-iOS), [Android](https://support.zoom.us/hc/en-us/articles/360031913292-Using-MDM-to-configure-Zoom-on-Android), [Mac](https://support.zoom.us/hc/en-us/articles/115001799006-Mass-deploying-preconfigured-settings-for-Mac) and [Windows](https://support.zoom.us/hc/en-us/articles/201362163-Mass-deployment-with-preconfigured-settings-for-Windows).
#### Office 365 users can automatically sign in to the Zoom for Outlook add-in using SSO credentials
Customers that use Office 365 can automatically sign their users into the Zoom for Outlook add-in using SSO credentials. This can be paired with a [custom add-in manifest](https://support.zoom.us/hc/en-us/articles/360041403311) that pre-populates the account’s vanity URL, creating a seamless authentication experience for users. This feature uses the user’s SSO session token if it is active, or will prompt for a new authentication with your identity provider if no active session is found.
A Zoom admin can enable this setting on the account's [security page](https://zoom.us/account/setting/security) under the **advanced** menu.
Example of admin setting for SSO with Outlook add-in.
## Response Mapping
In response mapping, **attributes** are categories of data defined by **values**, and are used to pass information from the identity provider to a service provider like Zoom. Mapping attributes and values is essential for automating user profile information and managing user licenses.
Zoom response mapping is broken into two halves: *basic* and *advanced*. Basic mapping is used to map basic profile information, including name, phone number, department, etc., while advanced mapping is used to manage dynamic license assignments, assign user groups, user roles, and more.
This section covers the fundamentals of basic and advanced response mapping and highlights unique conditions required for some features.
#### Zoom supports response mapping through both SAML and OIDC
Zoom can configure response mapping through either SAML or OIDC. SAML identity information is exchanged in XML-formatted assertions, while OIDC identity information is provided through JSON Web Key sets (JWKs). In either case, Zoom can use the attributes or claims received from the identity provider to map user profile information, licensing, groups, and other supported account settings.
#### Fundamentals: Attributes and Values
Most identity providers pass basic profile information using plain attribute names and values. For example, an employee’s department may come through with an attribute of department and a value of Human Resources. The following table demonstrates the relationship between attributes and values when passing information on a user.
| Attribute | Value |
| ---------- | ------------------------------ |
| firstName | John |
| lastName | Smith |
| email | |
| department | Human Resources |
By correctly assigning an attribute to a response mapping, user information can be automatically applied to a user profile to simplify the account creation and management process.
### Basic Mapping: Profile Information
Basic Mapping is used to apply profile information like first name, last name, department, phone number, cost center, and location from a directory to a user’s profile. Many of these categories are self-explanatory and can be easily configured; however, some categories require explanation for proper configuration to prevent unanticipated consequences or application errors. The following section highlights unique mapping options and configuration settings for basic mapping. Refer to our [Basic Mapping article](https://support.zoom.us/hc/en-us/articles/115005888686-Setting-up-basic-SAML-mapping) for a complete list of supported attributes.
#### Default license type only applies to *brand new users*
The default license type option will apply the designated license to all *brand new* users that are provisioned within the account through first-time authentication. This does not apply to users that are authenticating for a second time, users that have consolidated into the account from a previous account, users that are provisioned through SCIM, or users that have been manually invited.
For information on *updating* user licenses with authentication, refer to the license configuration under [Advanced Mapping](#advanced-mapping-licenses-add-ons-and-access).
#### A default license type of *None* will not allow new users to authenticate unless advanced mapping is configured to assign a license
Zoom users must have an assigned license type (Unassigned without Zoom Meetings Basic, Zoom Workplace, etc.) to login to the Zoom service. If a default license type of None is selected, new users cannot sign in or create a new account unless they will receive a license through [Advanced Mapping](#advanced-mapping-licenses-add-ons-and-access).
#### Most basic mappings will re-apply on login, unless otherwise specified
Most basic mappings will update every time a user signs in by default, *except* *for* first name, last name, display name, and phone number. By default, these four mappings will only apply the first time a user authenticates and will not re-apply again, even if updated by a user or admin. Zoom administrators can change this behavior by enabling the option for **Update at each SSO login** on the response mapping page.
Example of Update at each SSO login option.
#### Phone number mappings should include a country code and area code if outside the United States
Phone numbers mapped through assertions should include the user’s country code and area code when possible. Zoom will assume a country code of +1 if not defined by default.
Accounts that do not retain country codes within their directory can edit their assertions within their identity provider to automatically include these if necessary.
#### Each user can have up to three phone numbers and one fax number mapped to their profile
Zoom administrators can configure up to three separate phone numbers and one fax number mapping for each user. Each phone number must be unique and cannot duplicate the value of another field.
Example of phone number options for each user.
#### Profile pictures must be mapped from either a publicly accessible URL or encoded with Base64
Accounts that want to map profile pictures from their directory must map the images using either a publicly-accessible URL or encode the image in Base64 when asserting.
### Employee Unique ID
**The Employee Unique ID changes the primary identifier Zoom uses to identify users and helps prevent duplicate user accounts after an email change**
The *Employee Unique ID* is a feature Zoom offers to assist with identity management. By default, the primary identification for a Zoom user is their **email** **address**. This means that if the work email login type is ****, then Zoom will always identify this user by that e-mail address. This identifier is what allows integrations like SSO or Facebook and Google OAuth accounts to associate the user with the same Zoom account.
However, this identification process can be problematic if a user’s name or email changes. For example, if **** has an email change to ****, Zoom cannot safely determine these are the same person (because the fundamental identifier is different) so Zoom will create a new account the first time **** logs in.
To simplify this issue, Zoom offers the Unique Employee ID feature, which changes the primary identifier of a user from their email address to an established unique ID. *This does not change a user’s Zoom username*, but instead offers an alternative identifying attribute. This change allows Zoom to dynamically update a user’s email address within Zoom if:
* a *new* email address is accompanied by a known Unique Employee ID; and
* the affected user’s email domain is associated within Zoom
For example, if **** authenticates and passes a value of 12345 (their employee number) for the Employee Unique ID attribute, Zoom will now identify the user within the account by the asserted value. If John authenticates again using the email **** while still passing the Employee Unique ID of 12345, Zoom will identify that is now **** and will dynamically update the user’s email within the account if the domain is associated.
Identity administrators should be *positive* that no two users will overlap with the same Employee Unique ID value before establishing a mapping for this category. If another user authenticates and passes the same value, the email will update again to the new user and can cause significant disruption to user services and experience.
**The Employee Unique ID feature requires associated domains to change a user’s email**
The Employee Unique ID feature cannot update a user’s email address unless the email domain is officially associated with your account profile. Refer to our support article on [Associated Domains](https://support.zoom.us/hc/en-us/articles/203395207) for more information.
**Admins and Owners cannot update their email through the Employee Unique ID**
Admin and owner emails within Zoom cannot be updated through the Employee Unique ID feature. This is intended as a security measure to prevent unauthorized access. Admins and owners must change their email through their profile page.
**User emails can only be updated once per day through the Employee Unique ID**
User emails can only be updated once every 24 hours through the Employee Unique ID feature. A user must wait a full calendar day from the previous update before updating their email through SSO again.
Diagram of an example flow for updating user emails.
**Setting the attribute to \ will use the asserted NameID of the user**
Mapping the Employee Unique ID attribute to **\** will automatically use the asserted NameID value of the user as their unique identifier. This can be a beneficial tool if your identity provider asserts a NameID other than a user’s email, like a User Principal Name (UPN) or similar value that does not change. Do not use this value if users’ NameIDs match their email.
Example of the <NameID> admin setting.
### Advanced Mapping: Licenses and Add-ons
The Advanced Information Mapping section can dynamically apply licenses (including Zoom Phone), add-ons, and user access groups to users as they authenticate. Unlike basic mapping, advanced mapping contains many nuances that can require diligent attention when configuring, depending on the complexity of your environment. This section highlights the nuances for configuring advanced response mapping. Refer to our [Advanced Mapping article](https://support.zoom.us/hc/en-us/articles/115005081403-Setting-up-advanced-SAML-mapping) for a complete list of supported attributes.
#### Advanced mapping applies every time a user authenticates
Unlike basic mapping, which has optional updates for some categories, advanced mapping configurations will apply every time a user authenticates, according to the top-down order of application.
For example, if a user has a basic license and then authenticates through SSO passing an attribute and value mapped to granting a full license, the user will be instantly granted the full license. If the user’s profile is then changed within the identity provider to move them back to a basic license, they will be re-assigned the basic license once they reauthenticate within Zoom.
#### Advanced mapping allows multiple attributes and values per category
Unlike basic mapping, which allows only one attribute per category, advanced mapping can support multiple attributes and values for each category. This allows for significant flexibility when managing user licensing and access through security groups within your identity provider as seen in the following configuration.
Example of advanced attribute mapping.
{% hint style="success" %}
**Zoom Tip**
Attributes can vary by identity provider, notably for security groups. Confirm with your identity provider or through [response logs](#response-logs-tell-you-which-saml-values-and-attributes-are-being-asserted) how attributes are asserted.
{% endhint %}
#### Advanced mapping applies licenses from the top-down when multiple attributes are asserted
If a user passes multiple attributes or values that are configured for advanced mapping, Zoom will map the licenses from the top-down. See the following example:
Example license type selection in admin settings.
According to the above configuration, if a user were to pass an attribute for both **global\_users** and **marketing**, because **marketing** is the highest in the configuration, this attribute will be applied to the user, and the remaining applicable attributes will be ignored.
Alternatively, if the configuration was set with **global\_users** as the highest, as seen in the following screenshot, if a user’s assertion contained **global\_users**, **marketing**, **human** **resources**, and **IT**, because **global\_users** is the highest priority, only a basic license will be asserted.
Example of adjusting the order of priority
Zoom administrators can adjust the order of application when editing the mapping values using the ↑↓ arrows within the editor.
{% hint style="success" %}
**Zoom Recommendation**
Configure the advanced configurations from the most specific to most general to prevent license misapplication.
{% endhint %}
#### Webinar and Large Meeting mappings can share a common value to apply both add-ons
To simplify the application process, Zoom administrators can configure the same attribute and value twice to apply both webinar and large meeting add-ons to the users, as seen in the following image with the **global\_users** value. These add-ons can also be independently configured if desired, as shown with the **webinar\_only** and **large\_meeting\_only** values.
Example of attributes for large_meeting_only and webinar_only.
#### Specified users and User Groups can be exempt from specific mappings
Every option under Advanced Mapping can be configured to exempt specific users and User Groups from mapping behavior. This can be beneficial for preventing VIP users from service disruption due to a potential change in licensing.
Example of user exemptions.
#### Zoom supports up to five custom attributes
Zoom administrators can configure up to *five* custom attributes for adding user data to their Zoom profile under the [advanced user management](https://zoom.us/account/user#/advanced) page. After adding the custom fields, Zoom Administrators can configure the mapping on the [Response Mapping](https://zoom.us/account/sso/mapping) page.
Example of Custom Attributes
#### Mapping users to a sub-account will *only* apply a meeting license and add-ons
Mapping a user to a sub-account will only apply a user’s meeting license and add-ons like Webinar and Large Meetings to the sub-account. User Groups, IM Groups, User Roles, etc., will not apply and must be configured within the sub-account.
Customers that require more flexibility for response mapping with sub-accounts will require a unique Vanity URL and new SSO configuration within the sub-account.
### Advanced Mapping: User and Contact Group Assignment
User Group and Contact Group assignment is the one area of advanced mapping that operates in two distinct modes: *standard mapping* and *multi-mapping*.
* **Standard mapping** applies a single match. An administrator can configure many attribute-and-value pairs, but when a user authenticates, only the first matching entry takes effect and the rest are ignored. Reaching a specific outcome therefore depends on precise, exact configuration. This is the default behavior for all accounts.
* **Multi-mapping** is an optional mode that applies every match. A single authentication can match multiple attributes and values at once, assigning the user to multiple groups in one pass. This makes it well suited to accounts with complex group structures that place users across a wide variety of User Groups and Contact Groups. Multi-mapping must be enabled through Zoom Support.
#### **Standard mapping assigns a user to the first matching User Group or Contact Group**
Under standard mapping, when a user’s assertion matches multiple configured values within the User Group or Contact Group category, Zoom applies only the topmost matching entry in the configuration. The entries are evaluated in top-down order, and the first one that matches is applied. All remaining matches within that category are ignored.
For example, in a configuration containing twenty attribute-and-value pairs mapped to different User Groups, a user whose assertion matches several of those pairs is placed only into the group associated with the highest matching entry.
#### A single value can add a user to multiple groups, and the first group added becomes the Primary Group
Zoom administrators can configure User Group mapping to add a user to multiple groups with one value. This behavior applies in both standard mapping and multi-mapping.
The first user group added will be set as the user’s Primary Group and will determine the user’s default settings *unless an underlying group has a setting locked*. For more information on User Groups, refer to our [support article](https://support.zoom.us/hc/en-us/articles/204519819-Managing-user-groups-and-settings).
In the following image, if a user passed the values for **Leadership**, **Human Resources**, and **Regulated**, they would only be placed into the groups for **Leadership**, because it is the first match and no further matches apply.
Example of standard User Group mapping.
#### Multi-mapping assigns a user to every matching User Group and Contact Group, for up to 50 rule matches
When multi-mapping is enabled, Zoom applies *every* matching entry within the User Group and Contact Group categories rather than only the topmost match. The same attribute can be configured up to fifty times, and each configured value that matches an assertion places the user into its associated group.
This means a single attribute passed with fifty distinct values, each mapped to a different group, can place a user into all fifty groups in a single authentication. This enables a one-to-one relationship between identity provider security groups and Zoom groups, so that adding a user to a security group within the identity provider assigns them to the corresponding Zoom group at their next authentication.
In the following image, if a user passed the values for **leadership**, **testing**, **AI**, and **human\_resources** with multi-mapping enabled, the user would be placed into all of the user groups, because Zoom will apply the first 50 rule matches when multi-mapping is enabled.
Example of multi-mapping User Groups
The Primary Group designation is unaffected by the mapping mode. In both standard mapping and multi-mapping, the first matching group added becomes the user’s Primary Group, unless an underlying group has a setting locked.
#### Multi-mapping simplifies group assignment in large enterprise environments
Multi-mapping reduces the configuration precision required to assign users to multiple User Groups or Contact Groups. Under standard mapping, placing a user into several groups depends on an exact top-down configuration that resolves correctly in one evaluation. Multi-mapping removes this constraint by applying all matching entries at once, which supports environments where users belong to many groups and where per-attribute, per-value configurations would otherwise be difficult to execute in a single pass.
#### Multi-mapping requires activation through Zoom Support
Multi-mapping is not enabled through the standard SSO administration interface. Enabling the feature requires submitting a [support request](https://support.zoom.com/hc/en/contact?id=contact_us) to Zoom asking that multi-mapping be activated for the account. Until the request is processed, User Group and Contact Group assignment operates under standard first-match behavior.
### Advanced Mapping: Auto Mapping
#### Auto Mapping serves as a fallback that assigns users to a User, Channel, or IM group named after their asserted value when no explicit rule matches
Auto Mapping can be used to automatically assign users to a User Group, Channel, and IM Group named after their asserted value. Unlike other advanced mapping components, which can be configured to assign a user to any group based on the value, Auto Mapping always assigns a user to a group based on the exact value. If the group previously did not exist, it will be automatically created.
Auto Mapping functions as a fallback and only applies when a user’s assertion does not match any of the explicit rules configured in the advanced mapping sections above. If a user is already assigned to a group through an explicit rule—for example, placed into a User Group based on identity provider security group membership—that explicit assignment takes precedence and the corresponding Auto Mapping rule is ignored. In the same example, a User Group auto-mapped from the user’s department value would not apply, because the explicit User Group rule has already matched.
Example of an Auto Mapping configuration.
For example, if Auto Mapping is set to map a user into the groups based on their department, and the user did not match an explicit rule for that category, then if their department value is not already defined for the User Group, Channel, or IM Group, users will be automatically assigned into a group that matches their department name, as shown in the following table:
| Attribute | Value | Does Zoom Group already exist? | Result |
| ---------- | --------------- | ------------------------------ | ------------------------------------------------- |
| Department | Human Resources | Yes | User added to Human Resources group |
| Department | Marketing | Yes | User added to Marketing group |
| Department | Sales | No | Sales group is created, user added to Sales group |
## Troubleshooting SSO
#### Response logs can be saved for troubleshooting
Zoom can save response logs from authentication attempts for seven days after an authentication. These response logs can be an invaluable tool for troubleshooting configuration and user errors, in addition to response mapping configurations. Review the section on [troubleshooting errors with response logs](#using-saml-response-logs-to-troubleshoot) for more information.
{% hint style="success" %}
**Zoom Recommendation**
Enable saving response logs to make troubleshooting easier.
{% endhint %}
#### Using Response Logs to Troubleshoot
Saved response logs can be an invaluable tool for troubleshooting configuration and user errors, in addition to response mapping configurations. If your Zoom SSO configuration is set to save response logs, they can be accessed through the [Response Log](https://zoom.us/account/sso/saml_logs) tab available within the SSO configuration page in Advanced Settings. To view response logs, click **View Details** next to an authentication attempt.
#### Most authentications will display in the response logs
Most failed or unsuccessful authentication attempts will display on the response logs page. If an authentication attempt does not display, it is most likely Zoom did not receive an assertion from your identity provider, or saving response logs is disabled.
#### Response logs can tell you if your configuration is incorrect or your certificate is outdated
When saving response logs is enabled, the identity provider’s information is asserted to Zoom to authenticate identities for each party. If an asserted setting or string of information, like the X509 certificate or issuer ID is different from Zoom’s current configuration, an error will appear advising that the information “does not match the current SSO Settings.” A Zoom administrator can update the SSO configuration to match these asserted values if they are correct to resolve the error.
Example of incorrect configuration warnings.
#### Response logs tell you which values and attributes are being asserted
Reviewing response logs can assist with resolving response mapping configurations by verifying what attributes and values are being asserted by users as they authenticate. These can be compared to the configuration to ensure the attributes and values match.
Example of information being asserted by the identity provider service.
If attributes or values are missing, the information is not being asserted by the identity provider service. Users experiencing this issue are encouraged to reach out to their identity provider support services for more assistance.
#### Response Logs include an error code and brief explanation, if unsuccessful
If a user cannot authenticate or receives an error, the response logs contain an error code and brief explanation of the error.
Example error code and explanation.
Most issues can be identified and resolved by using these error messages. If you cannot resolve the error, reach out to Zoom Support for additional assistance.
#### Web Tracking ID Errors
If a user fails SSO authentication, they will receive a WEB Tracking ID error code. These codes are not an error message related to a specific failure, but are instead a unique log ID that can be reviewed in Response Mapping for identifying authentication issues.
Example of a user-facing error with a WEB Tracking ID error code.
To identify the error, if response logging is enabled, navigate to the [Response Log](https://zoom.us/account/sso/saml_logs) tab available within the SSO configuration page in Advanced Settings. From there, enter the WEB tracking ID into the Tracking ID field and search to populate the response log
Example of searching the Response Log with the aforementioned WEB Tracking ID error code.
The response logs should display the received assertion and an error code and message at the bottom of the response that can be used for additional troubleshooting.
### SCIM Troubleshooting
### Errors
#### User Not Exist or Not Belong to this Account
This error occurs when a targeted user’s email address fails to provision due to an already existing account. Zoom administrators are encouraged to reach out to the user directly and manually invite the user to the account.
Example of a provisioning error.
#### You Can’t Add Paid Users
This error occurs when SCIM attempts to provision a user when there are inadequate licenses on the account. To resolve the error, the user must be provisioned as a basic user, or a license must be made available for provisioning.
Example of a provisioning error.
### Using SCIM Logs to Troubleshoot User Provisioning
Zoom provides the most recent 100 API request logs in the [Zoom Marketplace](https://marketplace.zoom.us/). A Zoom administrator can use these logs to confirm what information is being sent and received through provisioning APIs. To access the logs, sign into the Zoom Marketplace as a Zoom administrator and click **Manage**. On the following page, select **Call Logs** under **Personal App Management**. From there, click an entry to expand the API logs and review the contents.
The following image shows an example of a SCIM user provisioning request, with the user’s identity and licensing attributes highlighted for reference.
Example of a SCIM user provisioning request.
Like response mapping, Zoom can only apply information that is submitted from the identity provider in the provisioning request. Use these logs to confirm that user identity and licensing attributes are being submitted from the identity provider. If expected information is missing from these assertions, contact your identity provider for support.
## Data Flows and Authentication
#### SAML Authentication
The following diagram details a user’s SAML authentication flow when initiating a single sign-on session with Zoom.
Diagram of an example SAML authentication flow.
#### OIDC Authentication
The following diagram details a user’s OIDC authentication flow when initiating a single sign-on session with Zoom.
Diagram of an example SAML authentication flow.
#### SSO Web Login Token
After a user authenticates, the user's session is built within their browser, and has a life of two hours by default. If the user continues to actively use their Zoom web page, the session will refresh; however, if the user does not use their web page for two hours, the token will expire and the user must reauthenticate. Zoom admins can configure this active session length on the [Security](https://zoom.us/account/setting/security) page under Users need to sign in again after a period of inactivity and **Set period for inactivity on the web (minutes)**.
#### Client Login Token
When a user attempts to authenticate via SSO within a client, the user’s machine will open a web browser and redirect them to the identity provider’s login page. After a user authenticates, the user’s browser will receive a Zoom client launch token. Once a user clicks the “open” or “launch” button, the browser uses the URL schema combined with the launch token to open the Zoom client.
The Zoom client will use the launch token to obtain the access token and the refresh token from Zoom server. The client will use the access token for a length of two hours at a time, and upon expiration will use the refresh token to gain a new set of tokens, which are stored within the client’s local database. This refresh process is unlimited by default, and can continually cycle through tokens until a user signs out or the tokens expire. Zoom administrators can customize the session length on the [SSO settings](https://zoom.us/account/sso) page under [*enforce automatic logout*](#zoom-administrators-can-enforce-automatic-logout-after-a-defined-length-of-time).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://library.zoom.com/admin-corner/account-and-endpoint-management/sso-field-guide.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
