OIDC Realms require multiple attempts to login when Amazon Cognito is involved

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

    Description:  
    After configuring an OIDC Realm which goes through Amazon Cognito, Authentication attempts will sometimes appear to 'fail' and push the end user back to the IdP Authentication Prompt

     

    Cause:  
    The cause of this can quite often be down to the Amazon Cognito Lambda Trigger timeout being exceeded.

    Amazon Cognito Lambda Triggers have a default, hard coded and non-configurable (at this point in time), timeout of 5 seconds, see the below link for more information
    https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools-working-with-aws-lambda-triggers.html

    If this 5 second timeout is exceeded it will push the end user back to the Authentication Prompt again for another attempt.

    The 5 second timer is started at the point the Authorization Code is generated and sent back to the OIDC Application. From that point the Authorization Code must be exchanged for the Access/ID Token(s) within 5 seconds.
    You can see these calls within a SAML Tracer output, the below screenshots show a timed out Token Exchange attempt

    The Authorization Code is generated and sent back to the Application at 10:50:53

    The Exchange request for the Access and ID Tokens comes back from the Application 6 seconds later at 10:50:59


    Due to the 6 second time difference the Cognito timeout limit of 5 seconds has been breached and the request is cancelled due to the timeout

     

    Resolution:  
    - It could simply be caused by network delays, if the request is held up anywhere along the route for too long, it can cause the process to breach that 5 second Cognito timeout.

    - When then Application sends the Authorization Code back to IdP to exchange for the Access and ID Tokens, this is done 'behind the scenes' and directly between the Application Servers and the IdP Servers (the client machine/browser is not involved in this process).
    As that is the case, the Application's request could land on a different IdP Server (which we will refer to as the 'code exchange server') to the one the end user is landing on in their Browser (which we will refer to as 'authorization code server'). If the Realm on the 'code exchange server' has not been 'woken up' or 'warmed up' and loaded into memory, it can take some time for this to occur and this will cause the Timeout to occur. Realms can be warmed up by simply sending a CURL command to them within a scheduled Task

     - When the Authorization Code exchange request lands on the 'code exchange server' there is a login process which occurs for the requesting user, if the call to authorize the user takes longer than expected due to a slow Domain Controller or a busy network, this can also breach the 5 second Cognito Timeout

     

     

    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.