Expire session tokens after X amount of time; Refresh on use

[marfavi]

Currently, session tokens are valid for an extended amount of time. This can pose security risks, as prolonged token validity increases the chances of unauthorized access if a token is compromised. Implementing a short-lived session token that can be refreshed also enables the implementation of AnalogIO/coffeecard_app#169.

Proposed change

Implement a system where each session token expires after a specified duration, e.g., X minutes of inactivity. Additionally, the token should be refreshed (i.e., its expiration is extended) each time it's used. This approach balances security with user convenience, ensuring sessions remain active as long as the user is actively using the app but expire after a period of inactivity.

Rationale

This change is aimed at enhancing the security of our application by reducing the risk of token misuse. It also aligns with standard security practices in apps handling items that have monetary value, e.g MobilePay.

Key points

1. Token Expiration: Define a reasonable default for the token expiration time, such as 15-30 minutes of inactivity.
2. Refresh Mechanism: Ensure that each valid request to the server refreshes the token's expiration time.
3. User Experience: Consider how expired sessions will be handled on the client-side. For instance, each time the app is switched to, a ping call to the server can ensure that the stored session token is still valid. If it expired, the user would be prompted to enter their PIN to get a new token (as per User should reenter his PIN code after 2 hours of inactivity coffeecard_app#169).

[jonasanker]

@marfavi Thanks for bringing this up. The backend part of this has been long due (like #71) and was created a long time ago. From the backend perspective, there are a few things around this issue that we should consider, as well as what scope we want to take in related to the authentication and current token implementation. My motivation for initially bringing this up for the backend was based on the observation that we currently have implemented our login mechanism e.g. storing passwords, managing login and issuing tokens etc. Here there are a few things which we should optimize e.g. hash algorithm and token lifetime time.

However, as the general saying is you should never build your own authentication layer but always rely on battle-tested implementations. With this in mind, the discussion should probably be around what authentication/identity provider we will you for the future, whether should we keep storing passwords ourselves, should rely on a third-party provider and protocol and so forth.

I have spent some of the vacation reading up on this and will shortly share my thoughts for the backend in #71 . I can also share it here, doesn't matter to much where we will track the discussion.