Identity Brokering "fetch failed" Error Due to Network Restrictions

This article addresses an issue that occurs when configuring Identity Brokering using an OpenID Connect (OIDC) connection to an on-premise or Virtual Private Network (VPN)-restricted Identity Provider (IDP).

After a user successfully authenticates with the IDP, the login flow fails upon redirect. The following error is displayed:

fetch failed

This failure prevents the token exchange from completing and results in an "access_denied" message.

• Identity Brokering

• OpenID Connect (OIDC) connections

• On-premise Identity Providers (IDP)

• VPN-restricted Identity Providers (IDP)

The OIDC brokering process involves both front-channel (the user's browser) and back-channel (server-to-server) communication.

During the front-channel communication, the user's browser, which is on the VPN, successfully signs in to the IDP and receives an authorization code.

The failure occurs during the back-channel communication. The user's browser redirects back to the server with the code. The server then attempts to make a direct, server-to-server HTTP request to the IDP's Token Endpoint to exchange this code for an id_token and access_token.

Since the server is on the public internet and not on the VPN, the connection attempt to the IDP's Token Endpoint fails. This failure results in the fetch failed error. Because the token exchange cannot be completed, the user cannot be validated, and the login terminates with an "access_denied" message.

1. Identify the required OIDC endpoints that must be publicly or semi-publicly reachable:

   • Token Endpoint: Essential for exchanging the authorization code for tokens (the point of failure).

   • UserInfo Endpoint: Used to fetch the user's profile data after token receipt.

   • JWKS URI: Used to fetch the IDP's public keys (JSON Web Key Set (JWKS)) to verify the signature of the id_token.

2. Choose one of the following implementation options:

   • Option A: Make Endpoints Public Make the necessary OIDC metadata and token endpoints publicly accessible on the internet, secured via HTTPS. These endpoints contain no sensitive user credentials and are intended to be consumed by clients.

   • Option B: Allow-List Public Internet Protocol (IP) Addresses Update the IDP's firewall and network rules to explicitly allow inbound traffic from the specific public Internet Protocol (IP) addresses if the endpoints cannot be made fully public.

3. If using Option B, add the correct IP addresses for the tenant's region to the allow list. The list must be provided to the network team.

NOTE: Allow-listing is not only for Identity Brokering. If custom code executing (Rules, Hooks, or Actions) calls a service inside the network, or if an on-premise Simple Mail Transfer Protocol (SMTP) provider is configured, the firewall must also be configured to allow inbound traffic from the relevant IP ranges.

The complete, authoritative list of public IP addresses, categorized by region, is available in the Auth0 Documentation: Allowlist.