Search code examples
angularidentityserver4openid-connect

Troubleshooting Identity Server Angular clients

I have an IdentityServer4 implementation with MVC and Angular client applications. Both working fine most of the time. Sometimes however, the Angular client apps get stuck in a some sort of redirect loop I suspect, based on reports. Similar to this

https://www.scottbrady91.com/OpenID-Connect/Help-Im-Stuck-in-a-Redirect-Loop

The client apps use implicit flow. I'm not present at the time of the errors and not able to be since this is a global 24/7 operation. What is the best way to implement logging at the Angular app level, or troubleshoot this in general?

Solution

  • Good question, since OAuth solutions involve multiple endpoints and reliability is often underestimated. It is a challenge to deliver a resilient solution that supports fast problem resolution.

    UNDERSTANDING REDIRECT LOOP CAUSES

    In my experience these are the most common causes:

    • Authorization Server returns an error response to the login redirect in error / error_description fields - in this case the correct behaviour is for the Web UI to report the error clearly and stop processing

    • Web UI processing of the login response fails, eg when verifying the id token's JWKS signature - again the Web UI should stop processing and report the error clearly

    • The API returns a permanent 401 to the Web UI when a valid token has been supplied - in this case the API may be configured incorrectly - the details of the 401 failure need to be logged - was the token not found / expired / did signature verification fail?

    • The API returns the wrong status code - eg access to resource denied should be returned to the Web UI as a 403 and a technical problem should be returned as a 500

    • There is a cookie decryption error - common in clustered environments - sounds like this is not relevant to your case though, since you are using implicit flow and your Angular client is cookieless

    RELIABILITY ACTIONS DURING DEVELOPMENT

    I always encourage my teams to work like this once the basics are complete (though I have limited success - lol):

    • Test at least a couple of failure scenarios
    • Review code paths for important behaviour - eg API status codes
    • Ensure good error displays in UIs, to help enable fast problem resolution
    • Deliver solid API error responses to the Web UI, and log causes of failures

    SOLUTION TO COMPARE AGAINST

    This write up of mine may give you some ideas on an approach. Steps 10 and 17 deal with simulating Web UI and API failures during development and ensuring the desired behaviour. Some related code below: