Build our own external login provider

[SimonBackx]

Instead of relying on third party login providers, it migh be a good idea to create one ourselves.

Why?

End-to-end encryption is super important in Stamhoofd. The web doesn't really offer good alternatives for persistently saving keys withoout risking losing them. You also have other difficulties: multiple browsers on same device, browser updates, clearing of storage, devicelost/stolen...

The only alternative for now is using passwords and deriving the keys from the password. This is a good solution, but it also has tradeoffs:

• Choosing a password while members will only need to use it at max 4 times in a year. Which will cause a lot of users to forget their passwords. Once you forget your password, you also loose access to all the encrypted data. Luckily, we take that into account and we try to make it as easy as possible to recover from this. But you still need to enter ALL data again.
• It is not that secure if people decide to use bad passwords

Solution

A generic app that users need to install in order to sign-in. This could be the same app as organizations will use to manage their organization, but it should be very easy to understand.

In the app the user only need to enter their email and the key is generated and stored inside the app. We could also store the keys far more safely and on some devices we could use the HSM. In case of devive loss or theft we default back to the same recovery as 'password forgot', but this should happen far less.

The app could be used as an OpenID-like authentication mechanism, with the only difference that it will create an unique encryption key for every client and saves them securely. This also enables self-hosted websites to use this system and automatically enables a kind of SSO for organizations. External services for organizations could build on top of this system (even when they don't need E2EE).

Desktop flow

Instead of showing a login + password form, we show a QR-code that is generated and ask the users to scan the QR-code with the app. When scanned, the app opens and asks to confirm to give permission to client X. After that the user will automatically sign in on the desktop computer (no possibility for a redirect flow since we are using two different devices).

Below the QR-code we also add a "help" button with more instructions and a possibility to sign in with password/email.

Mobile flow

Instead of showing a QR-code we show a "sign in with X" button which will open the app or redirect to a page that explains how to install the app (if not installed).

Advantages

• Less 'forgot password' events
• Less duplicate sign ups from users who forgot that they already have an account and create an account with a different email address
• Less overhead for organizations to help with account recovery
• Much faster sign in
• No generation time needed to derive the keys (which can take a while on slow devices). This also helps with older devices where the key derivation doesn't work somehow (memory / CPU limits?).
• Increased security
  • No bruteforce attack possible
  • High entropy keys
• Same login for multiple organizations, even when they are hosted on different servers or when they run different software
• This will be easy to explain to members and/or parents as they are already used to scan QR-codes. E.g. for mobile payments and ordering in a bar.
• We could extend E2EE and also encrypt email addresses (and remove all personal information from accounts) for organizations where that is sensitive information (unions, LGBT+ organizations, political party...)
• Could be optional
• (idea) We could also use phone numbers instead of email addresses since we only need to verify the phone numer once for every app install. SMS is expensive in Europe (10 cent in Belgium). And since most users only have one phone number, this will make it easier to link new users to imported users (we could match phone number to auto assign access - without keys).

Downsides

• Slower sign-up
• The need to install an app (we should keep that very small). We could keep the password based login as a secundary login method.
• Dependency on vendor of the app. It should be open-source and as open as possible.
• We need one app for multiple organizations. So there is a no whitelabeling possibility here (or at least only for big organizations).

Feel free to leave your remarks below :)

[SimonBackx]

Related to #57

[WardToulet]

This sounds great but a lot of additional work and maybe a bit out of the scope of stamhoofds core functionality, are you planning on doing this as a speparate but related project to stamhoofd or are your planning of adding it entierly into the existing codebase?

[SimonBackx]

Yes, this probably is a bit of extra work. But I'm already planning to release an app, so we could build it into that app.

But I'm not certain this would be a good solution. Having this system will also have downsides. I think a better solution for now would be to have a PWA on Android, and ask for an app install when the registration is complete. So the chance is higher those users will keep signed in (because we can ask for permanent storage when a PWA is installed on Android). We could do the same for iOS, but I really hope Apple introduces better PWA support (and installation) in the future. Currently it is a bit awkward, but if we explain it with some steps I think most users will follow the instructions. Having an app for every organization is certainly the way to go, but not possible with App Stores.