If I understand you correctly, there is really no stopping a determined and authorized user from using the web API in unexpected way. Cookie can be reused, headers can be sniffed, you really can’t trust that the API calls are from your own applications, be it JAMStack or native.

On a related note, I just did something like that. I need to read some textbook I purchased through McGraw Hill, however the shitty website insist me to read the book through their online reader. So I hit F12, save the cookie, wrote a simple script and scraped the whole book down completely. I consider this fair use.

Had McGraw Hill wised up and used LiveView to stream the book content through web socket to their javascript reader it will be a lot harder though.

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.

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.