stephane

Token based authentication from phx_gen_auth

After the great work done in phx_gen_auth, I was wondering if it would be possible to modify phx_gen_auth to support --no-html to generate a token based authentication instead of the session based authentication. (Support --no-html · Issue #38 · aaronrenner/phx_gen_auth · GitHub)

I started a little draft (Auth api by StephaneRob · Pull Request #1 · StephaneRob/mix_phx_gen_api_auth_demo · GitHub) from a new phoenix application where I generated the session based authentication with phx_gen_auth, and tried to convert it to a token based authentication.

But as there is a lot work to adapt the generator (and certainly out of the scope of phx_gen_auth), I would like to know if there is a need/interest for a dedicated generator?

30 comments

/phoenix #authentication #token

0 5198 30

2022-11-05 19:01:35 UTC

First Post!

thojanssens1

The session based authentication works with tokens. Can you give a little more precision?

Post #1

Most Liked

mattei

A-ha! Thanks for the reply - you replied to my comment on Hacker News earlier.

I ended up going with the phx.gen.auth generator and basically ripping sessions out, while keeping token generation for API authentication. The server just returns a base64 encode of the binary bytes generated as token on the server. On the client, I use next-auth to store the session token and user. It’s surprisingly elegant and I’m happy with it.

I tried Guardian but the implementation was a little messy and the generator was much cleaner. I also found Pow just wasn’t great for API use, too many open ends when it comes to things like email confirmation and whatnot.

This is my boilerplate so far, with the above customizations: GitHub - matteing/stack: My stack for new products. · GitHub

Here is the Plug where I ripped out sessions and tied everything together: https://github.com/matteing/elixir-boilerplate-testground/blob/main/lib/useindie_web/auth.ex

Here is the auth token creation function, with the added encoding step: https://github.com/matteing/elixir-boilerplate-testground/blob/main/lib/useindie/auth/user_token.ex#L29

I hope my repository serves as a starting point for others looking to retrofit the auth generator for APIs! I managed to do it with a good degree of success.

Post #29

lud

For SPAs my team just use regular cookie ; it works fine. JWT are not meant for app authentication. Projects/boilerplates with Vue or React using JWT for app auth are everywhere and it is a shame.

Though I guess if you want your API to support token authentication for server-to-server usage, then it feels clumsy to implement both authentications on the same routes. But that’s just a custom plug.

Post #27

LostKobrakai

In memory in a js context is just as unsafe to xss attacks as local/session storage. Anything accessable to js is prone to such attacks. The only save solution is a http(s)_only cookie, which can’t be read by the js runtime.

Post #7

Last Post!

mattste

I’m implementing a similar approach for my team’s Absinthe API. I’m curious about folks’ approaches to session expiration.

The plan is to have our Remix app set a cookie to store the bearer token. I’m considering just telling the frontend team the following specs:

Set your cookie expiration to <60 days (even though our backend session is set to 60 days).
This bearer token may be expired at any time (if we detect a security breach). In those scenarios, it’s your responsibility to have the user re-authenticate.

Ideally, the frontend app continuously checks for the session cookie expiration and shows an alert to the user that their session will expire shortly and they will be logged-out. It’d be unfortunate if the user submitted a form only to find out they’re no longer logged-in.

Post #30