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. (https://github.com/aaronrenner/phx_gen_auth/issues/38)
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.
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.