This feature allows account admins to use Okta to authenticate members of their account in end-to-end encrypted Zoom meetings. The account specifies an account domain name (ADN) to identify the account, which other meeting participants use to confirm that the account has delegated Okta to authenticate the user’s email address and device key.

Upon joining an E2EE meeting, a user whose account has enabled this feature, can authenticate to Okta to get an attestation proving their email address and device. Once a meeting attendee is authenticated, a blue shield will appear next to their name in the meeting participant list. Other meeting participants can then hover over the icon to display information about that person, including their company domain (ADN) and corresponding Okta-authenticated email address. Other attendees can confirm these identifiers to ensure that they are meeting with the expected party.

This feature significantly reduces the possibility of a meeting intrusion or other unauthorized activity, even against a powerful attacker who manages to compromise the Zoom server infrastructure. Other meeting access control mechanisms such as passcodes and waiting rooms rely on the integrity of the Zoom server. Even end-to-end encrypted meetings could be eavesdropped on if participants do not check the security code. Okta Authentication for E2EE allows users to prove their credibility by displaying their email address and ADN in a way that cannot be tampered with even if Zoom itself is compromised, and provides an alternative to checking security codes.

Notes:

• The information selected to be shared will be visible to the host and all participants in the meeting.
• Okta Authentication for E2EE does not apply to display names, which might or not be freely chosen or changed depending on the specific meeting and account settings.
• You will always need to be signed in to Zoom through your Okta Single -Sign-On to display Okta Authentication for end-to-end encryption in meetings.

To learn more about how to enable or disable this feature or join a meeting using Okta Authentication, follow these instructions:

• Enable Okta Authentication for end-to-end encryption as an admin for your account.
• Enable or hide Okta Authentication for end-to-end encryption to join a meeting as a participant.

For more details about the technical design and security properties, please refer to the Zoom Cryptography Whitepaper.

How Okta Authentication for end-to-end encryption works

In order for the account to delegate authentication to Okta, the account’s ADN hosts a DNS TXT record indicating the Okta instance they want to use. Verifying clients will fetch this record using DNS over HTTPS (using the 1.1.1.1 DNS service from Cloudflare). It is important that the ADN is able to designate Okta instance in a way that cannot be tampered with by the Zoom servers, and that the verifying user trusts the account’s ADN.

Okta issues attestations using a custom variant of the OpenID Connect protocol, designed such that only the authenticating client (and not Zoom itself) can select which device signing key(s) are part of an attestation. Other meeting participants verify these attestations by confirming with the ADN that they were issued by the expected Okta instance, and that they contain the expected email address and device.

We take several measures to guarantee the privacy of the users who verify and display these attestations. Unless the verifying client has a local proxy configured, requests to Cloudflare (for the DNS records hosted by the other participant’s ADNs) and Okta are sent through a Zoom-hosted proxy, in a way that hides the client’s IP address from these servers but does not compromise their TLS connection. If a local proxy is configured, the proxy’s IP address might be revealed to the DNS server and to Okta.