What is the workflow of refreshing the token, in an API-client scenario?

Getting advice
,
1

I’m using Keycloak now and I simply love it. Though it’s hard to set up, I’m pretty content.

Now I want to improve workflows. Here’s my current problem.

Let’s say my Keycloack instance is running on accounts.example.com.

I have a react.js client at example.com and a dotnet 6 API at api.example.com.

Now consider this workflow:

  • User logs in
  • Gets the token in react.js
  • Browser sends that token on each request to the API (Authorization: Bearer token header)
  • Everything works fine until the token expires
  • User has filled a form in react.js
  • He pushes the submit button. Post request goes to API with the expired token.
  • API realizes that the token is expired.

I’m stuck here. If API asks for a new token using refresh token, then we actually DDoS attack our own Keycloak. Because for each react.js request, we should get a token.

If API returns an error saying that the token is expired, then what should we do in the client app? If we redirect the user to Keycloak, form data is lost and the user needs to re-fill the form. If we don’t redirect the user, how should we refresh the token? Also, it’s still a bad UX, since the user needs to submit a form twice and spend extra time to compensate for refreshing the token.

Please guide me on how can I improve this scenario?

Right now, my implementation is this:

  • User submits a form or reloads data from the server
  • Server (dotnet) response with an error that the token is expired
  • Client (react.js) shows a message that the user needs to re-login and redirects the user to the login URL
  • If the user is still logged in into the Keycloak, the user would be redirected back, but loses form data in react.js
  • If the user is not logged in into the Keycloak, he would log in again and would be redirected back, again with lost data.
2

Your frontend should manage correct state of tokens - it should refresh it when it is expired. So frontend checks before api call if token is still valid (that’s simple token decode and exp claim check, auth lib has function for that usually) and if not then refresh token is executed + API call with valid token (still valid token or new refreshed token) is executed.

Axios is used for API calls usually, so interceptors are used to inject/renew token. Example Using Axios interceptors for refreshing your API token. which is not the best, because it renews token when API rejects token and not before - that double API calls.

Another example of not the best implementation is Keycloak - Guide - Vue.js where frontend has own infinite loop where token is refreshed periodically.

1 Like
3

See my GitHub - dasniko/keycloak-reactjs-demo: Demo for React.js and Keycloak SSO integration. reference, there are also some videos linked.

If you use the official keycloak-js lib and axios, this is an easy way of doing it automatically with interceptors, like @jangaraj already said. It‘s also shown in the code and video.

2 Likes
5

Thank you for explaining the flow. I’ll test it.

6

I use keycloak.js and axios exactly. This is the apparent benefit of using well-known libraries. Thank you. I’ll watch it.

7

That‘s IMHO bad, as then the users session will never expire, even if the user doesn‘t use the application actively, but leaves the browser open.

The keycloak-js lib has this awesome function updateToken() which one should use to check the token before actually using it. Thus, also the response interceptor in the first mentioned link is not needed, as the application can check the update the token, if necessary, and doesn‘t need to wait for a 401 from the API call. No double requests :slight_smile: