[auth_jwt] Using database.secret as cookie secret

[jesusVMayor]

Hi, i'm starting to work with auth_jwt with cookies, and I'm seeing some things that i see as inconsistent.

_get_jwt_cookie_secret function is returning allways the database.secret parameter, and is used to call _encode and _decode in ir.http functions, that means that we don't have a way to use the validator secret_key field as secret key, and there will be allways only one secret key for all validator and always will be the database secret.

• Why not use the secret_key field of the validator to encode and decode?
• Another thing that im don't know if is a bug, _auth_method_jwt is always setting the cookie again, with the cookie_max_age parameter of the validator, why not let the client handle the expiration of the cookie?

[sbidoul]

Hi,

Why not use the secret_key field of the validator to encode and decode?

This is because the secret_key field of the validator is meant for another purpose (i.e. decoding the JWT token itself). Actually, it may not even be set if we use public key to validate the JWT tokens.

In which scenario is it a problem to sign the cookie with database.secret?

Another thing that im don't know if is a bug, _auth_method_jwt is always setting the cookie again, with the cookie_max_age parameter of the validator, why not let the client handle the expiration of the cookie?

This is by design so the client stays authenticated as long as it is using the API. But what do you mean exactly by "why not let the client handle the expiration of the cookie?"

[jesusVMayor]

I see a problem if there is an external auth server, the server issues a token, the token its received in odoo and then odoo starts to issue new tokens in the cookie with a different signature, and expiry time. In every response the cookie is renewed, with a new expire in the payload and the cookie based on cookie_max_age field. I see it as a security issue, the JWT can't be invalidated, if the token is compromised an attacker could be accessing the system without a way to remove the access, the only way will be changing the database.secret, and this will casue problems with CSRF token, mail links...
If you want to use the JWT to manage sesions, its needed to implement it in a more complex way, using also a refresh token who could be invalidated for example.

We must differentiate the authorization server and the resource server.

• If odoo is the authorization server and the resource server in different controllers: The token should be consistent, have a expiry time who requires a new authentication after the expiry time, or implement a refresh token saved in the user who could be invalidated.

• If the authorization server is a external system, and odoo is only a resource server: Odoo shouldn't mess with the token, the external system is in charge of the token, its expiry and the renewal mechanisms. If we want to save the token in a cookie during his lifetime, the cookie shouldn't be decoded and signed again with a new expiry time, just take the header, and put the same token in the cookie, just decode to validate it, and maybe to put in the cookie the same expiry that is in the payload.

[sbidoul]

Thanks for the explanation. In the use cases we have had so far, we have other mechanisms to invalidate.

I'll comment on your PR.