how to think about authentication in fpm apps

[amitu]

FPM has support for auth, which can be used to decide which ftd documents are public or visible only to authenticated user satisfying some condition (eg they have starred ftd-lang/fpm repo on github).

This is different from auth support to fpm apps.

Apps Should Know As Less About Auth As Possible

This is our main goal.

Single User App

Let's start with a simple use case: If an app is single user app, eg a hacker news or twitter client, a person todo, diary, photo gallery app etc. In all such cases, a person has installed an app, and they have full access to the app, and no one else has any permission.

In such cases, we only have single question, if the request to any URL corresponding to the app should be allowed or rejected. We handle that by using readers.

-- fpm.user-group: only-amitu
github-username: amitu

-- fpm.app: Person TODOs
url: /todo/
readers: only-amitu
package: fifthtry.github.io/todos

Here, we have used only-amitu as readers. So any request to /todo/* will be allowed only if the request has a cookie which has valid github token for amitu.

In such case the app lets you do any action. App does not know anything about auth at all, and blindly trusts fpm to ensure the contract that only amitu is accessing the app.

Single Writer, Multiple Reader

Say the user have public todos, only the owner of the site can create/edit todos, but they want anyone to be able to view the todos.

-- fpm.user-group: only-amitu
github-username: amitu

-- fpm.app: Person TODOs
url: /todo/
readers: everyone
writers: only-amitu
package: fifthtry.github.io/todos

Here we have said reader is everyone and only amitu is the writer. In this case the app must be written with header, X-FPM-IS-WRITER as the contract.

The app will allow edit operations, only for any request that contains X-FPM-IS-WRITER=true as header. If the header is not present, but request still comes to you, then it means a reader is viewing the app, and just show the public view of the todos.

Again app does not have to know who the reader or writer is. If the app is visible to the world, or only to a subset of people. If the readers or writers are authenticated using Github or Facebook. App knows nothing, only know if X-FPM-IS-WRITER=true or not.

Multiple Non Discriminate Writers

In this situation, we have multiple writers, but we do not care who actually did an edit, we just want writers to do edits, and readers to not be able to do edits. Non discriminate means we do not care who did an edit. If this was the requirement, we again a build our application (wasm or endpoint apps) using the X-FPM-IS-WRITER=true header.

Multiple Writer, and We Need To Know How Edited

This is the case where just a boolean flag that this person is a writer is not enough. We want to now store who wrote it. Say only the person who created a todo can edit or close the todo. Or we want to know the name of the person who created the todo etc. In such cases we need some sort of user id.

Again, our principle is to know as little as possible. User ID must be unique, but beyond that we do not care if the user logged in via github or email etc, as we are not going to call github api or send emails to user, we just need to know who created the todo, we need to store some sort of user id in our todos table and so on.

For this to work identity: <some identity> has to be used by the site owner.

-- fpm.app: Person TODOs
url: /todo/
identity: github-username
package: fifthtry.github.io/todos

The site owner has decided that for their site people should use github to authenticate, and the github username should be used to generate the user id. Note that fpm does not pass the actual github-username, but a hashed value to the app, using the header: X-FPM-USER-ID. The value of this header would be hash(<id or url> + <github-username>) or some such, it would be a value like 12def4 or something.

Now the app can check the user-id. And the is-writer header to decide if the current user should be have write permission or not.

Note that since we have not passed any username etc, each unique user-id the app sees, the app should prompt the user to set name if the app wants to show the name of the person.

App Sending Email

App so far does not have access to email, so how can the app send email?

At some point fpm will get email support, the way we have auth support today. The individual apps would not need to know the exact email provider. The site owner will have to first allow the app email sending access.

When implementing email support in fpm we will also solve email template, attachments etc, and there would be just a single way to send email with attachment available to all apps.

The app may be given permission to send email support in background, or maybe app will just trigger a url, /-/fpm/send-email/?template=<> and fpm would show a email preview to the user and user will have to click to send the email.

This Is The General Approach: Each Capability, fpm will support and app will request

Tomorrow we will have capability to deduct payment, or to send alerts, or to get latlong etc. For each capability, the main code would be in fpm (or a wasm package), and site owner will decide what app gets what capability. We will give minimal access to the app to avail the capability (like we showed in email, we can give email sending support to apps without giving the apps the actual email address).