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)
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?
Yes, my idea was to adapt the generator to remove templates files, and return json instead. On login a token is returned with other information like user email.
The main difference is that this token need to be sent for each request by the front application, and need to be fetch in the authorization header by the server.
The remember me cookie is used as refresh cookie to refresh the session via the /users/me enpoint to allow the front application to fetch an access token.
Not really. It has been since long discouraged to store the token in local-/sessionStorage (xss attacks).
I have a project based on Absinthe/GraphQL and cookies work just fine.
It is better to compare the means of transport of the token, i.e. localStorage+HTTP header VS Cookie.
“Session vs token” makes little sense to me.
If you still need to add the token in the header, I’d like to know why. Cross domain requests?
If you use cookies you’re still likely in a “webapplication using the api” context and less likely in a mobile app or even server to server type communication context. For the latter there’s neither xss nor csrf possibility if I understand those correctly. Your suggestion is certainly correct for a web context, but that’s not all the things interacting with apis.
@LostKobrakai, yes it’s exactly the use case I’m interested in. Be able to consume an API easily from different devices.
@thojanssens1 agree that it’s discouraged to store token in local/session storage. The token returned by the API should be kept in memory (react context, redux state, vuex…).
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.
I think that it’s not really as unsafe as local/session storage, because the token doesn’t stay in the browser.
The refresh cookie is stored as http_only cookie.
In my humble opinion, this seems essential to phx_gen_auth if it is to become part of the standard Phoenix framework. A lot of people use Phoenix just for their API, so a lot of people will want to be able to do:
mix phx.new --no-html --gen-auth # I don't know what the actual flag will be
It already is merged in to phoenix and it’s still a valid tool even if limited to session based authentication with logins – especially given how much more diverse, with various different tradeoffs, authentication for api’s is.
I’m often puzzled at the dismissal for APIs and their technologies in this forum. I’ve seen multiple API authentication questions be shot down immediately here: “JWT is unsafe”, “tokens are unsafe”… That’s understandable, but we have to authenticate our single page apps somehow, and people use tokens.
It’s the difference between theory and pragmatism.
As someone who’s new to Elixir and Phoenix, it’s incredibly off-putting and a shame considering how suitable Phoenix is for the task of building APIs. It’s a pleasure.
Thanks for the clarification, it’s just been a little frustrating as someone new to the community who’s been trying to implement an auth solution for API use.
I’ve seen tons of questions spiral into theoretical debates and not get solved, and I wish that wasn’t the case, because it can be very difficult for beginners like me to find up-to-date information and pointers.
I’ll likely be writing a tutorial sometime on implementing API auth, once I get a little bit better at Phoenix and Elixir
And yes, Phoenix rocks for API development. It’s a pleasure.
