Questions about Token and refreshToken invalidating after Nakama restart

Runtime Framework
,
1

Hello and thank you for the great work,

I have a question around authentication and sessions. When I do a successful login, I receive both token and refreshToken and store them on client side.
But when I restart the Nakama server, token is not valid anymore and I try to call sessionRefresh method, but the refreshToken is also invalid.

I think this is a general concept, but I have tested this on the server framework and also the Flutter SDK I’m using and also help building here: GitHub - obrunsmann/flutter_nakama: Pure Dart Client for Nakama Server 🌟🥰🤩

Any idea how to handle this? Because I think I’m not following some best practices.

2

Hi @aminalaee, that is the expected behaviour to invalidate all auth tokens when the server restarts. Furthermore, even if tokens never got invalidated they’d still expire. We’d recommend catering for re-authenticating workflows in your game.

3

Hello Sean,
Thanks for the reply. I ununderstand that I would handle token expriy, but what if I want to update my Go plugins, I need to restart the server, right?
Why would all users need to authenticate again because some minor backend change in the plugins?
Am I missing something?

4

Are you using open-source version?

5

Yeah, is there a difference?

6

If your server running by open-source version, the session cache is in-memory cache. So when the server restarts, all tokens are no longer valid

7

If that’s the case I think it should be documented somewhere.
Now I’ve made so much progress with my app and have to think about some other way.

8

The open-source version is good for MVP. If you want to make something prod, you should use the cloud version or fork and make some changes

9

Can anyone from the heroiclabs team confirm this?

@sean @mofirouz

10

What you’re observing is not a production-readiness consideration, just a scenario that has to be handled by clients no matter what: tokens can expire, be invalidated by a logout or server-triggered ban operation, or become invalid for any other reason including the signing key on the server being changed.

Clients must always be prepared to handle server responses that say their session token and/or refresh token is invalid, and then re-authenticate as needed.

1 Like
11

Thank you for the answer and explanation.

Sorry the last question I have is that what is the suggested way of doing that with Nakama?

Let’s say the authentication is with Email and Password, and after server restarts how can the client re-authenticate seamlessly without storing the email/password locally to do so?

To be more specific it’s not clear to me why the refresh token is invalidated after the restart, there’s no way to get the token again after that part.

Thanks again

12

What I said applies to all tokens, including refresh tokens. Having tokens that never expire or get invalidated is bad security practice.

As mentioned you should be prepared to handle token rejection at any point. If the session token is rejected, try to refresh it with the refresh token. If the refresh token is rejected, prompt the user to re-authenticate (or do it seamlessly via methods like device ID).

In your case I recommend linking both email/password and device ID to a Nakama user account. That way you can seamlessly re-authenticate using the device ID without prompting the user for their credentials again.

1 Like