Auth

[louis993546]

1. Figure out how to do authentication
2. Figure out how to do authorization

[louis993546]

From #10: It's gonna be a bit weird with GraphQL

• Each each resolver is agnostic/independent, if you do it in the application layer, you might do auth check a lot of times
• for non user-dependent stuff, middleware is probably a better choice

For more info, read this page from gqlgen

[louis993546]

Current idea:

• "username" = userId
• "password" = TOTP

And they can be transmit in with basic auth. Still not sure what the database needs to store, and how to secure it.

[louis993546]

Slightly polished version:

sign up

• user id generated by backend
• totp secrets generated by backend
• passphrase generated by client (uuid)

1. user sign up with it's passphrase
2. backend returns user id & totp secrets
3. backend stores a hasded + salt version of passphrase
4. client store totp secrets + passphrase locally + securely

session renewal endpoint

1. user generate totp password
2. user sends user id + totp password + passphrase
3. backend find user by id
4. backend check if the passphrase hash with salt matches
5. backend check if the totp password is valid
6. if everything matches, returns a session token (JWT or something)

any api call

1. send request along with session token + totp
2. if backend said token expired, renew it
3. if backend said totp is invalid, client should retry it once or twice, but there's a rate limit (#17)

scenario	user id	totp	passphrase	session token	Why
db compromise	gone	gone	safe	gone	db only store salted hash passphrase, so hacker "won't be able" to use the renew endpoint to generate a new session token.
MITM attack	gone	safe	ok	ok	totp changes very often, session token changes quite often + revoke-able, and passphrase also only sent quite often. Feel like this is good enough for a "talk to your roommate" app
device compromise	gone	ok	ok	gone	it's true for most services: if device is compromised, expire that session token. And even though passphrase is on device, it can be store in hard to retrieve space to avoid eavesdropping. Feel like this is good enough for a "talk to your roommate" app

There is (at least) 1 scenario that I am missing: MITM but next to the server. If the hacker sees all network traffic of the API, does it make it easier for them to crack anything?

[louis993546]

• Android Keystore
• iOS Keychain

Not exactly the same thing: iOS is more geared towards user, which can & will screw things up. Also need to think about users that don't set password on their device, in which keychain might not be available in certain configurations.

TL;DR: from the API's point of view, the plan above is do-able.