Effective Refresh Token Revoking with Kong API Gateway

1

Hello,

I’m actively working to bolster the security posture of our API ecosystem by leveraging Kong as our API Gateway. A critical component of this endeavor is implementing a robust refresh token revocation process. Our goal is to ensure swift and complete invalidation of refresh tokens upon user logout or compromise to safeguard against unauthorized access.

We’ve adopted OAuth 2.0 for authentication, relying on refresh tokens to manage user sessions. However, I’m seeking clarity on the optimal approach to revoking refresh tokens within the Kong environment. I’m curious to know if Kong provides built-in functionalities for this purpose or if a custom solution is necessary. Additionally, I’m interested in best practices for securely storing and managing these sensitive tokens to maintain compliance.

Our technology stack includes MuleSoft API and Integration, and I also came across this resource Revoke Refresh Tokens. I’m confident this community’s expertise can provide even deeper insights to help me resolve these issues. I’m eager to learn about any specific considerations or challenges related to refresh token management in this integrated setup.

I would greatly appreciate any insights, recommendations, or documented examples from individuals who have successfully addressed similar challenges or possess expertise in secure token management within the Kong ecosystem.

Thank you for your time and valuable contributions!! :pray:

2

Hi @mariasokolova , I will list some of the good practices for refresh tokens in general. If you are an enterprise customer, you should check out the OpenID connect plugin where we will handle this for you. RefreshToken is not a mandatory token. If used, it must be opaque (not a JWT).

  1. RequestToken must be used to request new accessToken upon expiry of the accessToken
  2. Expiry of refreshToken itself is typically greater than accessToken. This is controllable in the authorization server settings based on usecase. For example mobile or other devices will have expiry in months so they have better user experience. For web apps, expiry is set higher than accessTokens (typically +5/10min)
  3. New token must be requested only after expiry and not preemptively

With open ID connect plugin, Kong handles all of this.

Hope this helps. Thanks