API tokens and session keys can outlive parent

[ammario]

In:

• /users/{user}/keys/tokens [post]
• /users/{user}/keys [post]

we do not ensure that the new token expires before or at the parents' expiry. So, it's possible for an application to escape the user's intended timebox by immediately trading the limited token for an unlimited token.

[Emyrk]

This is expected behavior in all applications.

If this was not possible, then you could not create application tokens.

Browser tokens from /login inherently have a shorter lifetime since we can refresh them more often from the more frequent api interactions. So I think we need to live with this for the time being. @ammario

---

So if the goal is to prevent session extension, then we should instead implement a way (like a new scope) that revokes the ability to make more api tokens. If we revoke that perm via a scope or other means, then the session cannot be extended.

I think adding new scopes at this point might make it more difficult to change authz solutions, which we are currently investigating.

[ammario]

Understood that the login token has to be a special case. And agree that we should push this until after AuthZ architecture settles.

[Emyrk]

@ammario the login token and likely the cli-auth token. But trying to determine which tokens have more privileged then others gets tricky imo to do "magically".

---

I would be curious to hear the problem this is trying to solve. In normal operation, a user should be able to create more tokens from their existing auth.

The cases where the sessions should not be extendable probably mean there is some other token source that is not the actor themselves. Eg: could be an admin making a token for the user.

In the case where the token source is different, we could just have the ability to create these "restricted tokens" (w/e that means). This could also be extended to not only disable session extending, but also disable some other permissions. Like changing the password, which could be used to then login again.

So I think there is a solution that is more holistic approach of created "restricted" tokens that can be generated to limit scope for security purposes. I will make sure this is added to the requirements of any Authz changes.