exact same problem here : each backup restart onedev and we lost all our session (cookie session ?).

Time to pass to bearer token authorization...

If you select to remember login, OneDev actually encrypts your password with a secret key and then store that encrypted password as a cookie in your browser. For security reason, each time OneDev is restarted, the secret key will be refreshed to avoid stored password being cracked. As a result of this, it will no longer be able to decrypt previously stored encrypted password and then ask you to re-login

Now with SSH auto-generated server private key, This situation can be improved by encrypting the password with that key instead of using different key for each restart.

Will ship this improvement in 3.2.2

I don't understand why you encrypt the passwd in a cookie ?

The OAuth2 approach with an authorization: Bearer {token} do not store any passwd and can be persistent after server restart without any Session module (statefull).

PS : i like the new OneDev logo

You are right, we can also use access token here. Both are secure, and using access token might be simpler considering OneDev has access token concept now.

Thanks for the remind.

Clarification

OneDev did not store encrypted password in cookie. User password is only used to calculate hash at login time, and OneDev does not store it afterwards in any form.

Storing user access token in cookie is also insecure. Instead, OneDev encrypts user id with server private key and stores that in cookie.

Usually, the json web token get retrieved after login and save in local storage (web browser). Then, a http header "Authorization : Bearer" is added to each request without the need of cookie or session. At the end, the server check the jwt signature and so access/deny request.

From my understanding, using bearer token in this case is equivalent to session from security perspective, as session id can be seen as a form of bearer token.

If the JWT approach requires to store access token in browser local storage, I think it will be less secure than current approach, as OneDev does not store any sensitive information at browser side at all.

Nevertheless, once changed to use server private key to encrypt user identify information, the session will persist between server restarts, without sacrificing security.

From a security perspective, token or session id are quite the same. But the first provide some quite interesting features :

• natively stateless without the need of session module, so when server restart, the token is still valid (except when passphrase change or date expired).
• JWT is RFC7519, part of the OAuth2, and so login can be in another server/domain (SSO support).
• as http header, it is perfect for running restapi

well, as soon as the session can survive to a server restart, i'm ok with it.