1. Sometime this year.. not sure exactly when. 2. Sure. But there isn't a straightforward guide to it in our docs yet. For CLI, you will have to open the browser, log the user in there, and make the CLI poll your backend to know if the user logged in or not. Once logged in, the poll can return a JWT to the CLI (which it can use as an API key of sorts)

If yes, then you are right - the JWT based auth will not give you that. But you can achieve most of the same behaviours: The session object let's you do: - updating the payload in the access token. This can be done with JWT based auth too since you can create a new JWT in the API with the new payload and return that - which your CLI command should save for subsequent requests. - revoke the session: You can send a 401 to the CLI client in this case and the client should then remove the saved JWT - get the user id: You can get this from the JWT as well. What you will not get: - An easy way to list and revoke CLI sessions offline (unless you don't use a JWT and issue opaque session tokens from your db) - Security features like rotating refresh tokens. - Ability to change the JWT payload of a CLI session in offline mode. But this can be solved too by not using JWTs and instead using opaque tokens. The downside to using opaque session tokens for CLI is that you will have to do a db / cache call for all API requests from the CLI. ---------- So it really depends on your requirements!

Thanks for the in-depth answer! By the way what do you mean by opaque session tokens?

which is a reference to a row in the db