Access Token Being Revoked/Deleted: v3.16.0

[tmknight]

Version 3.16.0
Perpetual/non-expiring access token being deleted/revoked several times per day resulting in inability to connect to service. Requires login to NordVPN account to generate a new token to establish connection.

Version 3.15.5
No issues. Access token remains intact.

Linux: Ubuntu Ubuntu 22.04.2 LTS

[ph202107]

I also lost a permanent token but then created a 30-day token three days ago. That token has been working OK so far.

[paulams]

Hello and thank you for getting in touch.
Due to security reasons the tokens are being invalidated on logout in the new app version unless the users explicitly request the token to be persisted using the --persist-token logout option.

[tmknight]

That appears to be a new parameter; where is that parameter documented (other than --help)? Also, in my scenario, no explicit logout is being performed. This is occurring on connect, though could be via a new login session. You've removed the ability to use username and password:
Logging in via ‘--legacy’, ‘--username’, and ‘--password’ flags is deprecated. Use ‘nordvpn login' or ‘nordvpn login --nordaccount’ to log in via browser

How can we designate in v3.16.0 that we are using a perpetual token at login to avoid this undesired behavior of token revocation?

[Savolro]

Hi! From the application's point of view, the long living token is no different from the normal API token with a short lifespan. It's also possible to do nordvpn login --token <short_living_token>, application just tries to use the token for API calls, API decides if it is valid or not. Options we had for this change were:

• Introduce a way to tell the application "I will re-use my token, do not delete it" on logout (or login, it would end up pretty much the same). We chose this option as it gives more control to the users and still deletes most of tokens;
• In case login happened with --token flag, it is automatically treated as persistent. In case you really need to delete token, which was created e. g. not via Nord UCP, you'd need to figure out ways to call API manually or we'd have to make a command just for token deletion, which would just add additional noise to the application;
• Ask API for token's lifespan and decide if it is a long living token. While this could be quite an automatic way and would still allow you to manually delete token via UCP if needed, it would add additional API call for quite an unnecessary thing.

There could be more options but I think they would fall pretty much into these categories. As I mentioned, we decided to go with the first approach as it is quite a middle ground for security, usage and flexibility.

Regarding documentation, we'll add this to our manpage as well. If you have more ideas to make it more visible or make the flow more convenient, please let us know.

[tmknight]

Thanks for the explanation. My experience has been improved once I incorporated --persist-token