What are authentication options for Phoenix/Absinthe

APIs are very hard to properly secure(I work in a company specialized in tackling the issue), therefore unless you have a strong use case for exposing an API, don’t do it.

Instead just write your code were business logic is totally separated from the web app logic, thus if in the future you need to add a mobile app then it’s very easy to build an API for it.

I strongly advise you to build your web app in the traditional way, aka without using APIs, and by preference with the LiveView approach, that creates more strong ties between the backend and the client side.

Just build an Authentication server that works through the powerful message passing mechanism that Elixir provides, and then use it as a path dependency to any of your projects in order to use it as a BEAM node in your application, but not exposing it as an API to the Internet. This is my 2 cents high level view, and I don’t have production experience yet with Elixir, but this how I am gonna build it for all the web apps I am planning to put online.

This sounds like good advice. honestly, the reason we were talking about using an API was solely for proof of concept. I will probably be asking more questions about authentication in the future.

We discussed our options this morning, and we’re beginning work on this solution today.

Thanks!

I worked previously in an agency as a backend developer for mobile APIs to support mobile apps of big retailers and I was a huge advocate of building one good API with OpenAPI specs, and then use it all over the place for web apps ans mobile apps, but when I changed to work in mobile API security I totally changed my opinion, and now I just advocate for building an API when you really need it, and more often then not you don’t need one for a web app, and in the Elixir world this is even more true

strictly because

?

Aren’t there non-negligible pros like JAMstack where SPAs on CDNs scale much easier than LiveView?

I will not discuss scalability, because what I was discussing is security.

In my opinion security should be a first class citizen in any software project, but unfortunately in 2021 is still an afterthought, and this all come down how to developers not being properly educated from the begin of their career at treating security as an opt-out, instead of the current approach of opt-in.

The business side of the company doesn’t help too in this process, because they only take security seriously when they are hacked, when they need to be compliant with some standards to be able to do business or when some law specifically requires some measures, but even here they just do enough to tick the compliance or law boxes, and daily hackers prove that that attitude is not enough.

So, I work in API security daily and my newsletter subscriptions are full of data-breaches, exploits, OWASP failures, and etc, etc, and the majority of developers don’t have 10% idea of how bad things are, as I wasn’t until I got to work in this space.

It’s important for a developer to understand the difference between who and what is accessing an APIi in order to be able to change it’s security posture about software developement. Read more in this article I wrote:

https://blog.approov.io/why-does-your-mobile-app-need-an-api-key

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

Now we need a way to identify what is calling your API server, and here things become more tricky than most developers may think. The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

By the way being OWASP compliant is not enough to secure your APIs and if you want I can give you reading on it.

JAMstack technology only makes the easily scalable part even easier to scale. It is a benefit for sure, but not as big as people would like to believe.

Fully agree with you. I occasionally see people are still using password storage-wise insecure hashing algorithms, such as SHA-2 and even SHA-1. Really frustrating we software developers couldn’t constitute a good foundation in time, for such simple problems.

I think this emanates from companies having nearly zero obligations on storing customer data, the penalties are yet fractions of the amounts that the companies will be unwilling to pay.

Just my two cents here, I would also consider using authentication gateways for APIs, such as Ambassador (particularly when using Kubernetes) and Kong (mild hybrid solution). They are pretty straightforward to get up and running, integrations with social media and OAuth systems are simple as a breath. Definitely good value there.

Please share the reading material for learning thanks.

SPA’s are also a bad idea then I suppose ? Similar to mobile they work with APIs

Good point, but playing devil’s advocate here, wouldn’t tightly coupling your front+backend (e.g. LiveView monolith as is suggested) propagate backend scalability challenges to your view layer?

• you still can offload static asset serving to a CDN with liveview
• you can scale out the old fashion way, just throw more hardware at it
• thinking about scalability too early is counter-productive.