Troubleshooting: Token Exchange Fails With "failed_to_verify_subject_token" for Private OIDC IdPs in SecureAuth CIAM

Version Affected: SecureAuth CIAM
 
 

Overview

When configuring a private OpenID Connect (OIDC) Identity Provider (IdP) — one not publicly reachable — in SecureAuth CIAM for OAuth 2.0 Token Exchange, an attempt to exchange a token can fail with failed_to_verify_subject_token.

Cause

SecureAuth CIAM (also referred to as ACP) is a cloud SaaS platform. To validate the incoming subject_token, ACP must resolve the OIDC Discovery endpoint and fetch the JSON Web Key Set (JWKS) URI for the token issuer's public signing keys. If the issuer's Discovery endpoint or JWKS URI is only reachable behind a corporate VPN, or is blocked by a firewall with no public allowlist, ACP cannot verify the token's signature, and the exchange fails with this error.

Resolution:

Ensure the following two endpoints are publicly accessible to ACP — they do not need to expose the entire IdP, only these specific endpoints:

• The OIDC Discovery endpoint (for example, https://idp.company.com/.well-known/openid-configuration)
• The JWKS URI returned in the discovery metadata

To keep this exposure as narrow as possible, restrict access to just these endpoints using IP allowlisting: allowlist SecureAuth's SaaS outbound IP ranges, expressed as Classless Inter-Domain Routing (CIDR) blocks, on the firewall protecting the IdP, so only ACP can reach them. See SecureAuth's SaaS Platform IP Addresses page for the current ranges.

Then, in the ACP Admin Console:

1. Register the OIDC IdP.
2. Enable Token Exchange.
3. Set Issuer to match the iss claim in the tokens exactly.
4. Provide the Discovery endpoint.
5. Test the token exchange once the firewall rules are in place.

Special Considerations

ACP matches the iss claim in the incoming token to the IdP's Issuer field exactly — any mismatch also results in failed_to_verify_subject_token. Manually validating a JSON Web Token (JWT) with a tool such as jwt.io is not sufficient, since ACP must reach the JWKS URI itself to validate in real time. Because OAuth 2.0 Token Exchange relies on trust in the system issuing the original assertion, only configure this for an issuer you have high confidence in.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.