Greg Weber

No, that goes against all recommendations. Longer lived tokens however can be given as refresh tokens that should be stored securely and [exchanged for new tokens](https://medium.com/hackernoon/the-best-way-to-securely-manage-user-sessions-91f27eeef460). This requires increased backend...

Given that there are already server side sessions it would be more secure to use a more traditional session-based approach to auth. Alternatively, the session can be used to increase...

It seems that the dashboard also persists sessions (and therefore passwords) to disk since they can be recovered on restart (although I assume they are encrypted). I have outlined how...

Sorry, I did not fully understand the code quite right. Along those lines, I might not be understanding the implementation, but I believe the [token is not encrypted](https://github.com/dgrijalva/jwt-go#signing-vs-encryption). Thus stealing...

oh, great, glad I missed that encryption. So the biggest issue is still the title of this issue that tokens are being used for 24 hours but the normal recommendation...

That would be preferable for a normal web session use case. Sessions allow logging out the user, including automatically when they are inactive. Would you store the session in etcd...

That makes sense for dashboard-ui. Like a normal session, you would want a maximum session time and automatic logout of inactive sessions. In the long-term I would like to have...

In the long-term we need a coherent auth system in TiDB that will allow for auth to PD/TiKV and work with TiDB users. I think that in any proposal, such...

I would suggest that security issues should not be automatically closed

I believe that we accidentally (this is definitely a bug as indicated by the docs) fixed this [on our fork](https://github.com/pingcap/errors/blob/master/errors.go#L305)