We have a react app using auth code with pkce . When user is not assigned to an App they are getting an endless loop to /login/callback and /authorize endpoint with error “User is not assigned to an app” . I don’t understand why I’m getting the loop . This is causing Okta rate violation limit . Please help me with the issue below you have a screenshot of implementation what am I doing wrong ?
It looks like your customAuthHandler checks if there is a previous authSate or if the user is not authenticated and does a redirect to login if not. If you have your secure route setup so that when a user accesses your application (/*) it checks for authentication and redirects if not.
Then when the user redirects back to Okta with the error your app page will reload, see the user is not authenticated and go through the loop again.
I have followed your React samples so it’s pretty much the same . The only thing that is different is the routing . I can’t do any modification on routing because the app is on production . Do you have any workaround solution for the above problem or I should create a meeting with your team ?
The behavior for OAuth applications is to redirect to the redirect_uri from the authorize call with the error message.
The recommendation would be to either update the application as soon as possible to either change the secure routing, or check for an error message and behave accordingly depending on the error without attempting another authorize call.
For now possible options would be:
Ensure all possible users that can launch this application have access to it by assigning them the application in your Okta Org.
Verify that your Okta Org is setup for client based rate limits. This should return a 429 to any specific client after 60 authorize requests within a 60 second period. (if the client continues authorize requests even if a 429 is returned this won’t have any effect)
Potentially you could have the redirect_uri goto another server process that checks if it is an error or not. If no error then redirect back to the current rediret_uri, if an error handle accordingly. This of course means you would need to have a way to configure the redirect_uri for an app already in production and is not really a solution you would want to run with for very long.