Token based authentication from phx_gen_auth

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

Usually You do not treat authentification for an API the same as You would for a full Phoenix project.

For an API it is common to add a token in the header for each request. It is then decoded into auth info server side…

It is not the same, but You can use plug to solve both, except the authentication is managed differently.

But I have not really tried phx_gen_auth, just once… and it did install controllers, templates and views. This is not required for a JSON API.

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.

If your js runtime has access to your token so has an attacker exploiting an xss vulnerability.

You’re right ! the only safe place would be an http only cookie.