Hi,
I’ve been using OKTA since many months in my ASP.NET application.
Since a week, every day my application runs fine until late afternoon but then suddenly the application starts to throw an 400 at login. Basically after login at OKTA org page, the app is going into a sort of “loop of sign in” and then this error appears:
Is this meaning that OKTA is returning (to authorization-code/callback) an header which is too long?
Why should OKTA return such a big header? Is because is suddenly receiving corrupted data from the application?
Why is this loop present?
The modification that I’ve recently done to my app are:
The server started to call other APIs (completely OKTA unrelated); I read that this might be a problem with the DefaultRequestHeaders but that doesn’t seems the case as I debugged them
There are some new ajax calls that need OKTA server side; also in this case I read that they can create problems, but I debugged and removed them
Moreover:
There is a now trigger which calls an action of my app every hour. Maybe this prevents the app to “clean” itself at some point? So maybe was the problem always present, but not appearing?
Everything is completely fine from morning to afternoon, then I need to restart the IIS app otherwise people can’t use the app.
I believe that typically this error is not about the headers Okta is returning, and, at least anecdotally, this has sometimes occurred due to the size of the cookie OWIN is using for the user session.
Are only certain users affected or are all users? I believe this can happen if the token is oversized (due to containing a large number of custom claims, a massive groups claim or two, etc). See this article for example. If you reduce the number/size of custom claims being returned, does the issue persist?
