CODEWITHSUNDEEP
authenticationexceptionoauth-2.0jwtrefresh-token
qwerqwer
qwerqwer

Reputation: 1

Handling Refresh Token Renewal: Redirect or Throw Exception?

I'm implementing an authentication system using access and refresh tokens. When the access token expires, I use the refresh token to get a new access token. However, I'm uncertain about how to handle the case when the refresh token itself expires or is invalid.

  1. Redirecting the user to the login page when the refresh token is expired/invalid.
  2. Throwing an exception, which the client-side logic will catch to initiate a re-login process.

I've also heard that throwing exceptions is recommended because it allows both the client and server to evolve independently.

Is it standard or recommended to handle refresh token expiration with redirection, or is throwing an exception considered better practice? I am curious about which approach is more appropriate in different situations

Upvotes: 0

Views: 1350

Answers (2)

akdombrowski
akdombrowski

Reputation: 1140

It's a bit unclear whether you're implementing your own authorization server and what exactly would throw the exception or redirect. It would help to clarify what you mean by "implementing an authentication system".

Assuming you're talking about implementing your own authorization server (because you refer to the client separately), the server should return an error when the refresh token is invalid as stated in section 5.2 Error Response of RFC 6749:

5.2.  Error Response

    The authorization server responds with an HTTP 400 (Bad Request)
        status code (unless specified otherwise) and includes the following
        parameters with the response:

       error
             REQUIRED.  A single ASCII [USASCII] error code from the
             following:

             ...

             invalid_grant
                   The provided authorization grant (e.g., authorization
                   code, resource owner credentials) or refresh token is
                   invalid, expired, revoked, does not match the redirection
                   URI used in the authorization request, or was issued to
                   another client.

Further info exists in section 6 (which links to the above section).

The client should then decide what to do with that error which may include asking the user to login again.

It's not necessary that an app ask the user to login with a failed refresh token exchange. If the server were to automatically redirect, the client wouldn't be able to implement whatever logic they wanted. As a quick example, perhaps the client needs access to a protected data stream that it feeds somewhere else for analytics. It does this in the background when the user isn't around because the dashboard would keep changing as the user tried to view them. It wouldn't make sense to redirect in this situation automatically.

Upvotes: 0

Gary Archer
Gary Archer

Reputation: 29301

Usually token refresh is done while the client is calling APIs. If a refresh token expires then you still need to complete the client side logic to call APIs, before redirecting.

function callApi(): Data | null {
   ...

    // Trigger a login
    location.href = authorizationRequestUri;

    // Complete the API request
    return null;
}

Personally I prefer to throw a LoginRequiredException rather than return null as above, since it simplifies code further up the call stack. Note that code execution of the API request does not complete immediately after the above redirect. The return null and error rendering code will execute first, though the error rendering code can be written ignore a login required exception.

Frontend clients often lay out a tree of views that make API requests concurrently. In this case you should only perform the login redirect once. One option is to wait for all views to attempt their API calls, then, if one or more returned a login required result, a coordinator can trigger the login redirect only once, as in this code of mine.

Such code could be written in multiple ways, depending on coding preference. You should reason out your preferred API client journey that deals resiliently with expiry conditions though, since the logic can be tricky in places.

Upvotes: 0

Related Questions