Troubleshooting: OIDC Authentication Fails and Returns to the Login Prompt (Lambda Edge Sensor Timeout)

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected: All
     
     

    Overview

    Configuring an OpenID Connect (OIDC) realm that goes through an AWS Lambda@Edge sensor can sometimes cause authentication attempts to appear to fail, pushing the user back to the SecureAuth Identity Platform (IdP) authentication prompt for another attempt.

     

    Cause

    AWS Lambda@Edge sensors used with Amazon Cognito enforce a hard-coded, non-configurable 5-second timeout. The timer starts the moment the authorization code is generated and returned to the OIDC application; if the application does not exchange that code for the access and ID tokens within 5 seconds, Cognito cancels the request and returns the user to the authentication prompt. See AWS's documentation on Cognito Lambda triggers for more detail.

    The two screenshots below, taken from a SAML Tracer session, show a timed-out token exchange. The authorization code is generated and returned to the application at 10:50:53:

    HTTP trace showing a GET request to OidcAuthorize.aspx with response_type=code and a redirect Location header returning the authorization code to the application, timestamped Wed, 05 Jun 2024 10:50:53 GMT.

    The exchange request for the access and ID tokens comes back from the application 6 seconds later, at 10:50:59:

    HTTP trace showing the token exchange request returning an HTTP 302 with a Location header of error_description=Read timed out&error=invalid_request, timestamped Wed, 05 Jun 2024 10:50:59 GMT.

    Because that 6-second gap exceeds the sensor's 5-second limit, the request is cancelled as timed out.

     

    Resolution:

    This is a timing issue rather than a configuration error, so check for delays in the following places:

    • General network delay anywhere along the request's path can push the exchange past 5 seconds on its own.
    • The code exchange happens directly between the application server and the IdP server, without the user's browser involved. If that request lands on a different IdP server than the one that issued the authorization code, and the realm has not been "warmed up" (loaded into memory) on that server yet, the extra load time can push the exchange past the limit. Keep realms warmed up by sending them a periodic request from a scheduled task.
    • A slow domain controller or a busy network can slow down the user's login step on the code-exchange server, which can also push the total time past the 5-second limit.




     

    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.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.