5.4 Validating IDP Attestations

IDP attestations can be validated like standard OIDC ID tokens in the Authorization Code Flow [3] with a few modifications. Users must:

1. Verify that the IDP domain in the iss field of the JWT matches the IDP in the ADN’s DNS TXT record and the IDP returned by the Zoom server. This ensures that the IDP is authorized to sign on behalf of the account ADN (as specified in Section 5.1).

2. Use OpenID Connect Discovery to ensure that the key used to sign the JWT is valid. To do this, make a request to https://examplecorp.generic-idp.com/.well-known/openid-configuration) for the JWKS, the keys used to sign the OIDC ID token.

3. Validate the JWT, including checking its signature and expiration date.

4. Validate that the zoom-identity-snapshot value and email address match what is provided by the Zoom server. We take several measures to improve the security and privacy of the attestation validation process. To ensure confidentiality and authenticity of DNS queries in step 1, clients obtain the DNS TXT record by making a DNS over HTTPS (DoH) request to the DNS resolver 1.1.1.1 (operated by Cloudflare), using Cloudflare’s JSON-formatted DoH API endpoint. We have deployed Zoom-hosted proxy servers, described below, to hide client IPs from external servers in steps 1 and 2. However, a client’s proxy and network configurations may prevent the client from successfully connecting to our Zoom-hosted proxy. If the Zoom client detects a proxy, it will attempt sending requests both via the detected proxy (which reveals its proxy’s IP to the target domain), and via the Zoom proxy. To reduce latency, the client will send the requests simultaneously and use the response that returns first. If neither request succeeds, then attestation validation will fail. In more detail, the client uses the Zoom-hosted proxy servers in step 1 when sending a DoH request to a supported DNS resolver, and in step 2 when requesting JWKS belonging to other users’ IDPs. The client first establishes an HTTPS connection to the proxy service, over which it sends a HTTP CONNECT request to establish a tunneled connection to the target domain. The proxy server authenticates the request, and also confirms that the target domain is an expected domain (e.g. that it is a subdomain of a known IDP domain). The client now establishes a HTTPS connection with the target server through the tunnel. This allows the client to use TLS to fetch the requisite data, but not reveal the client IP address to network eavesdroppers or the target domain. In order to mitigate abuse, the proxy checks that the target domain (in the TLS ClientHello) and the target port (in the HTTP CONNECT) are expected, but is not otherwise involved in the standard TLS handshake and certificate validation process for the target domain