Can phx.gen.auth be used for API authentication?

Can you expand on what you mean by “work with a JSON API”? I can think of two scenarios that meet that description and they have different answers for your question.

If you mean “connected to a JS frontend via JSON-formatted requests”, the conversion wouldn’t need to change that much. The biggest change might be with the details of where authentication data is in the request; best-practice with JSON APIs would be a bearer token, versus the cookie-based session used by default.

If you mean “as an authentication system for a JSON API called by other programs” (either via HTTP Basic or API key), the generated code would be a lot less useful.

Ah yeah sorry I can see how that would be confusing. I mean the former - connected to a JS frontend. I’ve read in a few different places how JWT’s are apparently subjectively worse than sessions. Thoughts on that? Why wouldn’t the cookie-based session be good practice?

JWT is a token that allows you to maintain user sessions. So what do you mean that they are worse than sessions?

Cookie is designed to work without the JS frontend. By default, cookie session in phoneix is http only (not accessible by the js) and unencrypted (but signed so is tamper-proof). If you log in via conventional http that it is fine; if you want to have fancy login in javascript driven frontend, then it is not as easy to work with.

A bearer token is an opaque token, whereas a JWT token in the cookie session contains trusted data. With a bearer token you keep all session data server side in a ETS table or something, so it is safer and easier to work with in js.

Could you elaborate on this please? I think whether we work with cookies or not it doesn’t matter? As long as the server has an appropriate success/failure response for its login service? I guess you see something I don’t see:)

phx.gen.auth stores it in DB. Storing the sessions in ETS wouldn’t allow having long lasting sessions (e.g. 60 days default for phx.gen.auth when remember-me is checked) without a huge cost in memory? Anyway it might be an option indeed but interesting that you mentioned that one as an example instead of some relational DB.

Without a concrete design I cannot comment anymore. You probably have some requirements that we don’t know, so no one else can design it for you. If you have a plan, but want a second opinion, then please post your plan first.

I’d like to latch on to this question if I may.

My plan is to have my users sign up and log in using standard phoenix generated html. Essentially a customised version of the pages generated by:

mix pix.gen.auth Accounts User users

While they are logged in, users will interact on the site through a Vue Single Page Application which fetches and updates data using an API written in phoenix served from the same site.

What I’ve managed to do so far is to

• start with a phx.new project (i.e. with ecto and html),
• Vue-enabled it at the hand of Caleb Weeks’ blog post and Steven Pallen’s project,
• added authentication using phx.gen.auth and
• added a basic API added with phx.gen.json.

What I now need to figure out, with your help, is:

• where to find the token on the vue client side,
• how to get the token into the API call (I’m using axios),
• how to retrieve- and
• check the token again on the API side to limit API calls to only those arriving with valid and current tokens and also to retrieve “session” data linked to the token in the database (cached in ETS), which never the client code never get to see.

I’m aware that somewhere between none, some or even all of this is already taken care of by the generated code and/or various third-party libraries like Guardian. But I’m given to the idea that the best framework is no framework and want to ensure that I understand what the code I am using does and how.

So far, I am loving Elixir a lot, for that reason (I’ve come to Elixir from Erlang and PHP) but I am still very new to it.

General comment: a typical API is not going to have any stateful behavior that would require a session.

I know, session data sounds like the “stateful behaviour” which RESTfull APIs are not to get hung up with, which is why I put session in quotes. My application isn’t typical and I’m well aware of the implications of keeping per-user or even per-session information in an API server. We’re not talking about a real session which used to refer to a process or server execution context staying inthe memory of a specific instance of a server which meant that future interactions needed to go back to the same instance which might be too busy now or for a different instance to reconstruct the execution context from the database just to continue execution of the next request. That was the MO of IIS and Apache which lead to stateless or RESTfull servers gaining popularity. What I call a “session” is more like data specific to the user for which the token which got issued when they logged in. There is a whole system of routing, load balancing and data distribution behind the API server to deal with horizontal scaling and reduce overheads.

If you want to touch the token from client side js, then it cannot be in the http-only cookie session as in the default. I’d suggest to put it in the localStorage, with potential XSS implication applied.

Once you have your hand on the token you can put it in the Authorization: Bearer header in your fetch call, it is straight forward to retrieve it and look up server side data from it.