Possible bug: AuthorizationException

We have an issue with the AuthorisationException for token refresh: in our view, it is thrown too quickly, for example even in the case of connection problems or 500 server errors. Our apps have always responded to an AuthorisationException by logging the user out, as we assumed that an AuthorisationException represents an authorisation error that must be resolved by logging out. We believe that, for example, a connection problem or a 500 error represents a temporary error that should under no circumstances be responded to with an AuthorizationException, as this is misleadingly interpreted as a reason to log the user out. We have now fixed the problem by checking the cause in the AuthorizationException and evaluating it accordingly. We only log the user out if it is a genuine authorisation error. Otherwise, we have now introduced a ‘stale state’, which indicates a temporary problem, for example, but keeps the user logged in.
The issue can be easily replicated using Airplane Mode on Android or iOS: if we try to refresh the page whilst in Airplane Mode, we immediately get an AuthorizationException.

Our question is: would it perhaps make sense to extend Okta’s exception handling so that we receive different exceptions that distinguish between various types of authentication failure? Do you perhaps have another suggested solution that we are not yet aware of?

We have at least fixed the bug so that we generate four different exceptions following the evaluation of AuthorizationException: TemporaryRefreshFailureException, ProtocolRefreshFailureException, UnknownRefreshFailureException and SessionInvalidRefreshFailureException, although only SessionInvalidRefreshFailureException represents a genuine authentication error for us.

We would be grateful for a reply; thank you in advance.

This should be the reference to the code in the library that deliver the exception:

Hey, thanks for asking this question,

I checked the error shapes, if you are referring to the file shared by Noya on okta-oidc-android, but a bit of background on your SDK versions will help us give you the right guidance.

Given the pattern okta-oidc-android is now legacy architecture, we don’t have active plans for overhauls in it for now, we do however actively work on okta-mobile-kotlin from what we learned from our customers which isn’t a drop-in replacement but a better architecture for mobile authentication overall. You might want to migrate if you are using legacy as a best first step.

Please raise a GH issue in okta-mobile-kotlin, we have the devs actively triaging issues and if taken up, the fix will be in the next release cycle.