Skip to main content
When you integrate with Auth0 services, we recommend you configure your APIs according to current networking standards. Review the following DNS resolutions, Transport Layer Security (TLS) configurations, and HTTP optimization strategies designed to make sure your application handles infrastructure changes and maintains resilient connections to Auth0 services. Following these standards for DNS, TLS, and HTTP ensures compatibility with our global delivery network, improves request reliability through proper retry logic, and maintains the security of your authentication traffic.

​
DNS and hostname resolution

​
Use Auth0 provided hostnames

Always connect to Auth0 using the provided hostnames, not the underlying IP address. Auth0’s infrastructure depends on DNS-based traffic steering for load balancing, cloud and CDN routing, and regions failover. We recommend against using DNS-based filtering since naming of cloud infrastructure may change over time.

​
Respect DNS Time to Live (TTL)

Always honor the DNS TTL provided by DNS. TTL values are often low (e.g. 30 to 300 seconds) for applications to respond to infrastructure changes quickly.

​
DNS caching

Use your operating system DNS resolver where possible. When using your own (application-level) resolver, ensure it caches responses no longer than the TTL.

​
Support multiple A/AAAA records

Auth0 may return multiple IP addresses for a given hostname. APIs should distribute connections across returned IPs through round-robin or randomized assignment. Set to failover immediately if one address is unreachable.

​
Transport Layer Security (TLS)

Auth0 only supports HTTP requests with TLS. We recommend you use the latest versions:
  • TLS 1.3 strongly recommended
  • TLS 1.2
  • TLS 1.1 and below are not supported

​
Use modern cipher suites

Avoid using highly customized client cipher suite configurations. Use default secure settings from your runtime unless you have compliance constraints (e.g., FIPS). Clients with limited cipher suite support may be rejected. To review the available cyphers, read TLS (SSL) Versions and Ciphers.

​
Support Server Name Indication (SNI)

APIs must use SNI TLS extension on all HTTPS traffic to Auth0. Traffic without SNI will not be accepted.

​
Honor certificate validation

Do not:
  • Disable certificate validation
  • Pin certificates
Auth0 renews and replaces certificates automatically and frequently. Certificate pinning can cause service disruptions.

​
Allow intermediate certificate rotation

Our certificate chain may change periodically. Ensure your TLS client:
  • Trusts any valid, publicly-trusted certificate authority in the OS trust store by default
  • Updates the OS trust store as part of regular updates
  • Does not pin intermediate certificates
  • Rejects only invalid chains

​
Enable TLS session resumption and reuse

Allow TLS session tickets or session IDs in HTTP/2. This reduces the TLS handshake overhead.

​
HTTP

​
Use a modern HTTP protocol

Use HTTP/2 or HTTP/3. These provide connection multiplexing, use HTTP header compression and require less TCP connections. If your client supports HTTP/2 automatically, use HTTPS endpoints and let the client negotiate HTTP/2 or higher.
Avoid HTTP/1.1 unless required. HTTP/1.1 is fully supported but is less efficient. Use is discouraged unless necessary.

​
Enable and reuse persistent connections

Configure your API to reuse HTTP connections to reduces request latency and improve reliability. Review the following recommended settings:
  • Keep connections open for up 300 seconds
  • Limit max idle connections to a reasonable number
  • Avoid creating a new HTTP API object per request to leverage existing connections
  • Rotate connections periodically to refresh connection health

​
Request Retries

We recommend implementing request retries for operations that are safe to retry: idempotent requests. When retrying due to transient network or server-side errors, inspect the HTTP Retry-After response header, which should determine how long an application should wait before making another request. Example: Retry-After: 300 If the header is present, wait the specified number of seconds before retrying a request. Adherance to the Retry-After ensures fair usage and prevents cascading failures or rate-limiting. If Retry-After is not present, use exponential backoff to determine the retry interval. Do not try more than three attempts.

​
Auth0 SDKs

We recommend the following best practices when configuring your environment or application to use Auth0 SDKs.

​
Use official Auth0 SDKs

Prioritize official or referenced SDKs for your platform and language. Use official Auth0 SDKs rather than building custom HTTP application or API integrations. These libraries are maintained to adhere to the best practices, abstracting the complexity of low-level networking and security compliance.

​
Choose the applicable SDK

Auth0 provides specialized libraries for different integration patterns. Ensure you select the SDK that matches your architectural use case:
  • Authentication and Authorization SDKs: Use these SDKs for end user login and obtaining tokens. Choose the SDK based on your application type:
    • Single-Page Applications (SPA): JS/TS libraries handle token lifecycles and PKCE flows in the browser (e.g. React, Vue, Angular).
    • Regular Web Applications: Server-side libraries manage sessions and cookie-based transactions (e.g. Node.js, ASP.NET Core, PHP).
    • Native/Mobile Applications: Platform-native libraries interact with system browsers and secure storage (Swift, Kotlin, React Native).
  • Backend Service and API: Validates incoming Access Tokens in your APIs. These libraries handle cryptographic signature verification and caching of JSON Web Key Sets (JWKS).
  • Management API SDKs: Programatic performance of administrative tasks such as creating new users and rotating Client Secrets. Handles rate-limiting headers and retry logic.
By using official SDKs, you ensure your integration automatically supports:
  • Resilient HTTP connection pooling and keep-alive settings.
  • Correct implementation of retry logic with exponential backoff and Retry-After header respect.
  • Adherence to current TLS and security standards.