How do you do tokens and permissions? #REST

[OvermindDL1]

@satom99

On tokens, once you have retrieved the token from the Authorization header, how do you verify you have issued that token in the past? Do you store it in your database and check whether an entry for it exists (and thus make sure you have indeed issued it) and what user it is liked to? Do you have a separate table for tokens just so you can have numerous tokens for an user, over a single one that is perhaps stored in the users table in a token column? Do you use Phoenix.Token and verify/4 it to get its stored user id and go from there? Why would you use Phoenix over generating a random string of a certain length each time you want to issue a token - how would this be done in Elixir?

On permissions, lets say we have a specific resource post that you want an user to have access to edit but not delete. How do you store and handle this kind of permissions? Perhaps a table named post_permissions with a bit with the user’s permissions? That would fit the case where there’s a single resource to handle, how would it go though for a system where post is just one of the many restricted resources?

Two standard ways when in-system like that. Either put the permissions in the database and look up the user’s permissions when needed, or store the permissions inside the Phoenix.Token directly, saving the database call, however that also means it will not be cleared out if, say, they are removed permission from later, however using very short-lived tokens is perfectly fine for that.

@wfgilman

Just use Guardian: GitHub - ueberauth/guardian: Elixir Authentication · GitHub

I am using Guardian to do everything you discuss in your post.

@satom99 is already using Phoenix.Token, which can do everything Guardian can do in this context but without the extra dependency and cost of JSON deserialization

@Graeme

The library guardian handles most of these things. The token does not have to be stored in a database, instead it is encrypted using a secret key. If someone provides a valid token (ie: it was encrypted with the correct key) then you know it was issued legitimately without checking a database. Unfortunately you usually do need to store some state in the database to handle sign out (or a token being invalidated for other reasons).

People really need to quit recommending Guardian for areas where it is ill-suited. This is a perfect user-case for what they are already using, Phoenix.Token. Guardian is great for things like passing credentials to a remote non-connected server. If you are using it in the same server then it is just needless overhead.

@Graeme

In the case of Guardian they recommend storing the token in a database so that it can be removed when you revoke it (GuardianDb exists to make this easier.

And doing that you then remove the entire advantage of using Guardian at all (which is to keep you from having to hit a database when doing a cross-site call), why use Guardian at all in this case??

@Graeme

That’s one way to do it. Another way is to encode a date that the token was issued and then just store in the database the date the user last logged out. Any token with a date older than that will be rejected. This means that a logout would kill all tokens for that user (which may be a bug or a feature).

Still hitting the database, you may as well put the permissions in the database itself then and don’t use a token at all but instead just the session to hold the link, of which you can easily wipe if, say, they log out elsewhere so the session is then wiped from the database preventing replay attacks. Guardian on the other hand would let you trivially perform replay attacks, so quit suggesting it please! ^.^;

@Graeme

If you are going to store each token in the database with some metadata anyways then that would probably work fine if it is a sufficiently long cryptographically random string. Honestly I like that technique but if you use a JWT (or similar) then you have the potential for stateless logins. You could have ten load balanced servers and as long as they all have the same secret key they can individually validate tokens and derive the user and their claims without hitting a database or requiring any single point of failure.

Stateless logins are nice, but you generally want short-lived tokens then to minimize replay attack abilities, and JWT is useful only if passing to another server; again if you are doing this all in the same server that you control then use Phoenix.Token, it is not as heavy, can hold arbitrary data, is faster, but does require that the server is on the BEAM or so all using the same key, JWT allows you to send data safely from server-to-server.

@Graeme

If you use JWT you could use claims for this. From my experience a lot of people end up just rolling their own permissions table that links to users or something similar.

JWT claims are just simple on/off, fine for very simple things, but not good for more detailed permission types.

@Graeme

That means that if you issue a token that is valid for 10 days and then a user’s cookie gets stolen, they cannot just click logout or change their password or anything in order to secure their account. The token will continue to work for the full 10 days.

Exactly! This is the replay attack, they just replay the old token. If it is all in-system then better to keep it in the database and don’t use tokens at all!

@wfgilman

Good point. I use GuardianDB to store the tokens and a sweeper to delete all expired tokens. In your api pipeline in the router you can ensure that a resource can be loaded from the token provided (i.e. checked against the database) and invalidate the request if not.

If you are having Guardian hit the database anyway, they why are you using Guardian at all?! It makes no sense!

@satom99

Thanks for the replies. In a previous topic, I was told not to use Guardian over Phoenix.Token when not encoding permissions into the token itself. Which gets me to a few questions; do you agree? In the case I am storing the tokens manually and only need to verify and sign it (with a secret key), wouldn’t Phoenix’ approach just do fine? And in the case I am anyway checking against a database whether a token is still valid, why would I need to encode an user id into the token whilst I can just get what user it’s linked to from the previous validating step? Thus, wouldn’t generating a random string securely do the trick instead?

On both cases, signing and generating a random string, why Phoenix.Token and not Joken or any other library? How would you generate a random token, perhaps doing this or using a more dedicated library?

What are the pros and cons from a security perspective? In what way is a signed token safer compared to a random string?

• If you are doing the authentication and authorization all in the same server and you’ll be hitting the database anyway, don’t use tokens, just use Phoenix’s Session and the database, you have significantly greater control.
• If you are doing the authentication and authorization all in the same server and you don’t always need to hit the database for short-lived authorization permissions, use Phoenix.Token and put the allowed permission inside the token itself (like via Phoenix.Token.sign("perms", [:read, :edit]) or whatever, you can encode whatever you want in it in any form that you want).
• If you are doing authentication on one server and doing authorization on ‘another’ server and those two servers do not use the same secure phoenix keys, then and only then is JWT (Guardian) useful. Don’t use it otherwise, it is not safe and/or not secure in other contexts.