Linuus

Guardian/JWT vs Phoenix.Token?

Hi!

(There may be some rubber ducking going on here but… anyway )

I’m building a backend API for a mobile app and try to figure out a good way to handle the authentication. I’ve already setup the initial user registration using Comeonin etc. so now I’m trying to settle on some token format to use.

I found this: User authentication in Phoenix? but it’s more focused on regular web apps and not APIs.

A lot of people seem to use Guardian and JWTs.

Is there any reason to use a JWT over something like Phoenix.Token?

Both JWT and Phoenix.Token can be verified without having them stored in the DB, but that means that we can’t invalidate the tokens (without invalidating ALL tokens). Right? This feels a bit scary to me. Am I just overly cautious?

To solve this, you have two options (that I know of):

Use a short expiration time
- In a mobile app, the user has to sign in often which is annoying.
Store the tokens in the DB and only tokens that are present among the user’s tokens are valid
- Why use a JWT or Phoenix.Token if you still check them in the DB? You can just store a random string without data encoded in it or other complex features.
- The DB will end up with a lot of stale tokens (may not be a big issue, but still)

What do you use on your APIs?
Why do you use that?

55 comments

/phoenix #authentication

123 23130 55

2017-02-13 22:13:23 UTC

Most Liked

michalmuskala

I was recently given a link to an article, which perfectly summarises my thoughts on JWT: Stop using JWT for sessions - joepie91's Ramblings

Post #11

karmajunkie

If all you’re doing is storing the session token, I’d probably reach for ETS first. If you’ve already got a per-user process going (and its truly account-related, not something where you’d just be tacking on some random piece of info) then I’d look at making it a part of that state. But I’d probably still echo it out to a database unless you’re ok with everyone’s session dying when you do a deploy or restart your node for whatever reason, and you’re also ok with the complications that will arise from needing to do session lookup in a cluster (assuming you want to run more than one node in production.)

I don’t want to trivialize the function; session management is one of those things that gets real complicated real fast at the edges. And frankly I’m new enough at this ecosystem that I’d want to have someone more experienced weigh in on what would be idiomatic and proper. But do keep in mind what the draw for BEAM is in the first place: excellent concurrency and state management tools that go far beyond just a record in a database somewhere.

Post #9

mbriggs

I’m not saying one thing is better then another, im actually arguing against the idea that there is one golden hammer. Everything has tradeoffs in authentication, you can list the negatives of anything and come to the conclusion it is bad. And be right! But there is also good.

Modern webapps tend to be written in something that lives on the browser, and communicates with the server via API. They also tend to have mobile apps, as well as public APIs. Phoenix apps tend to use websockets (channels). JWT works well for all of those cases, while session id in a cookie matching a row in a db work well for html forms. So authentication gets a lot easier for the other cases, and the tradeoff is invalidation gets more complicated. Are session cookies bad because they are really clunky to use in non browser situations? Of course not. Its all about tradeoffs and using the right tool for the job.

Post #55