Authentication using Tokens w/o Database and --no-html

I feel like I’m both treading water and going around in circles …
My use case is to simply restrict access to a few domains. Hence a user can confirm who they are by clicking the emailed link. The domains are hardcoded in config.exs.
I have no front end. And no database. This is just a service providing data.
Here’s my mental map (at the mo’!) - thinking aloud.
User issues a get request containing their email as a parameter (no post requests since there is no front end).
After a simple check on email domain, the token for the domain (not the user) gets emailed as a clickable link.
The user’s cookie (which I’m assuming is on their browser but I could be wrong because Plug.Session talks about ETS too and then tutorials immediately start using Postgres or Redis) is updated with the token.
Now, when they come back at a later time their cookie is proof they’ve gone through the email authentication process.

This should really be a post. If you’re worried about no csrf – a get request is as unsafe, but without communicating that side effects might happen.

True, but it also means you have no way to invalidate this authentication. It stays valid until it expired by whatever static means of expiration you’re using.

Yes, I agree that it should be a post, that’s why I mentioned it. But w/o a front end I don’t think I have any other option. Logically the user is ‘getting an email’

Expiration. I could expire the token? By associating a new token with each domain all users would need to reconfirm.

What do you mean by “no frontend”? The user needs to somehow query your endpoint. If it’s through a browser use a form, if it’s through some other generic http library make them do a post request.

True, this is quite a sledgehammer though. Kinda like changing the session secret to invalidate all sessions.

Yeah, I suppose I could create a simple form and use html() to serve it. I just meant that I haven’t built Phoenix with html with all the in built helpers and such. Trying to keep things super simple - no chance!

In case anyone travels this path in the future this is what I did …

This tutorial was my jumping off point: Elixir and Phoenix basic passwordless and databaseless authentication (pt.2) · bigardone.dev I did find part 3 but that’s not so helpful since it covers building an Elm SPA.

My use case was restricting access to particular domains. So instead of a hard encoded list of users I have a manageable number of domains in config.exs. Even so, the number of domains might grow to be unmanageable here, and I’ll need to explore an alternative - Mnesia perhaps.

GenServer is used for state. In my case it’s an advantage that a GenServer is transient and to require users to re-register when the GenServer restarts. Maybe not so good for a public facing app, but I’m working on an in-house tool and it’s a feature

The state is a nested map %{domain: %{user_name: “token”}}. The user name is randomly generated using :crypto. I cannot cancel a known users registration because I don’t have any knowledge of a particular user on the server.

Authentication is done using an emailed token. I’m using SendGrid, which was relatively painless to set-up, although a couple of module names have changed which needed fixing.

When a user submits their email address the first thing that is checked is the domain. If it’s not supported then they fall at the first fence. The successful submission and verification of the emailed link (one that didn’t display localhost!) results in 3 cookies being saved to the users browser - their random name, their org and the encrypted token. All are set to expire at 2-weeks.

Handily (I didn’t know this beforehand) the browser automatically submits the cookies for each subsequent request. They have to be fetched to populate conn. I’ve built a small plug that requests are routed through. The plug checks the org (first check), then finds their user name against the org (second check), and then checks the now unencrypted token against the user name (third check). All by calling the GenServer.

I have another layer completing authorisation by comparing the org against metadata in the data that the user requests. Rather than trying to authorise against resources ahead of time. The owners of the data can decide who gets to see it.

Users have to go through registration frequently. I’ve set-up a monthly cleanse of the GenServer. Their cookies expire after 2-weeks. And it’ll reset each time I redeploy or the GenServer falls over. Given the registration is so lightweight I regard this as a feature for my use case.

That’s it! My first GenServer, my first plug, and the first time using Bamboo and SendGrid.