Troubleshooting: OIDC Application Logs Show "No Token Present. Request Is Not Authorized."

Version Affected: All
 
 

Overview

If an OIDC realm has authentication problems on the IdP side (sometimes visible as login looping), the relying party (RP) application's own logs may show No token present. Request is not authorized., sometimes along with Token validation failed and an HTTP 401 Unauthorized response. For a related but distinct clock-skew issue that affects direct calls to the SecureAuth API rather than an OIDC application, see Troubleshooting: Clock Skew of Message Is Outside Threshold During API Call.
 

Cause

This happens when there is a clock skew between the IdP server and the server the OIDC application is running on. OIDC tokens are only valid for a specific time window; if the application server's clock is ahead of the IdP server's, the application rejects the token as not yet valid (or already expired) even though the IdP issued it correctly.

Resolution:

1. Review the affected realm's IdP-side logs to confirm the access token (and any other expected tokens) is actually being issued.
2. Decode the issued token at jwt.io together with the customer or application owner to confirm its issued-at and expiration claims are valid.
3. If the IdP is issuing the tokens correctly, the application side's own logs need to be reviewed next.
4. Even if the IdP server's and the application server's clocks appear to match at a glance, compare the exact timestamps the application's logs record for when the token was sent and received — they may be in epoch seconds and need to be converted before they can be compared directly. A skew can still show up here, where the application treats an IdP-issued token as invalid because the application server's clock is running ahead of the IdP server's.
5. Correct the time drift (for example, with Network Time Protocol (NTP)) on whichever server is out of sync.

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.