1

I'm trying to make my web-app's authentication with JWT.

I chose that because JWT is good for scaling-out (horizontal) the system since we wont need to store anything (such as session data) in server.

I also want to make my login form with "Keep me login" option. Then I found the magic refresh_token solution.

It's a good solution.

However, I concern how it can accomplish the scale-out purpose? Because, AFAIK, we have to store data about refresh_token in database or something like that.

P.s: I'm new to distribution system if the explanation above is wrong plz help correct me. Thanks

TJTran
  • 73
  • 1
  • 8

1 Answers1

1

The refresh token is being held by the client, no server-side storage should be needed (unless you are thinking about some "strange" usage scenario). So no horizontal scaling issues. On the server, you only keep client_id and secret (which is env var or similar, so not an obstacle for horizontal scalability).

There's a similar discussion: How to securely keep my users signed in with refresh tokens?

Edit due discussion in comments. The server validates access token always (if it's not expired, if a signature is valid, if the whitelisted issuer, if contains the required scope, etc.). A refresh token is used to request a new access token when the old one is expired, that's its only purpose.

And yes server needs some data for validation, but it's provided by the OAuth2 service provider through a .well-known endpoint or similar. So the server needs to be able to communicate with a service provider to be able to fetch the info required for validation.

Those .well-known endpoints are usually public, for example:

Gintautas Kišonas
  • 71
  • 3
  • 1
    *something* will need to store the refresh token on the server, because otherwise how can the server know it's valid? – Evert Jul 20 '21 at 15:23
  • 1
    @Evert question was about was to store it to keep user logged in - from user/system side, not how oauth2 service provider validates it. – Gintautas Kišonas Jul 20 '21 at 15:37
  • @GintautasKišonas sorry for confusing you. Actually, my question is about validating the refresh_token same as Evert commented. As I understand, on the server, we should store something about refresh_token to validate it from client's request. So each server will have different data about refresh_token of 1 user. And i feel it's hard for scale-out same as session-cookie authentication. Or there is other solution to do that, plz tell me – TJTran Jul 20 '21 at 15:55
  • 1
    Edited answer elaborating purpose of refresh token - you request a new access token by passing refresh token to oauth2 service provider. You should not interpret it in any way, it's just stored as the ticket to extend your visit – Gintautas Kišonas Jul 20 '21 at 16:17
  • 1
    @GintautasKišonas your assumption was that there was an existing OAuth2 server, but unfortunately for many new JWT implementors everyone reinvents the wheel. – Evert Jul 20 '21 at 17:05
  • 1
    @Evert ok agree that didn't come to my mind that someone might want to implement their own OAuth2 service provider when there are plenty of free SaaS or selfhosted ones – Gintautas Kišonas Jul 20 '21 at 17:29
  • @GintautasKišonas thanks, could you suggest me the keywords to find these "there are plenty of free SaaS or selfhosted ones"? – TJTran Jul 21 '21 at 07:12
  • 1
    Y sure. Keywords would be identity management and OIDC. Unfortunately, Google search yields a lot of intermediates or highly-priced enterprise-grade results. I personally can recommend Auth0 and Firebase as free ones and Azure Active Directory as cheap one. If you want to self-host it - IdentityServer is the best from what I have tried. Any major platform usually has one - I have tried some implementation on top of Django for example - well it works for some basic use cases, but overall self-hosted is a bumpy ride. Would generally recommend starting with Auth0 - it's both easy and versatile. – Gintautas Kišonas Jul 21 '21 at 08:50
  • 1
    @GintautasKišonas thank you very much, I will try them – TJTran Jul 21 '21 at 09:04