3. User authentication

The user authentication starts very simply with an sms. The key reason behind this choice was: it was the simplest way to get started, everybody in El Salvador is used to it. there is no issue with forgotten password, so less customer support for forgotten password and account recovery.

The downside of this approach is that this has fairly low security, as this is subject to a sim-swap. While most users would only have a few dollars in their wallet, it's likely in the future that some people will have larger balance in their wallet, and so protecting their account is paramount.

Here is a non-exhaustive list of things that should be improved:

• Adding an alternative way of login that would not rely on phone number. this would typically be an email.
• Adding 2fa options. Google authenticator is the most obvious solution, but we could have email when using sms, or sms when using email.
• Sending an email when a new login occurs. We may want to refrain on doing that with sms because the cost per sms is high.
• Token on the mobile app should be rotated. Also tokens should be placed in secured storage.
• Each user should have a list of token associated with his account, such that a particular token could be deactivated if needed. Currently we consider the token as a bearer assets and we have no way to deactivate a particular token. the only possibility is to deactivate the while account.
• We need to have a way from the galoy-admin panel to be able to reset a 2fa, and reset a password. we need to think about what the procedure for this should typically be.
• There is a level 1/ level 2 in the app with some restriction for level 1 in term of how many sats can be sent/day. We should have a way to send an ID number to be able to upgrade from level 1 to level 2.
• We should have, for merchant adoption, a way to delegate an account. Such that the delegee can receive a payment, see a list of last transactions, but not send a payment, neither see the whole balance. Think about it as a POS terminal. it doesn't give the person using the POS the ability to spend from the bank account associate with the POS, neither to see the full balance of the account. We want to eventually be able to do the same thing.

There are different personas to think about in regards to authentication:

• Retail end user. This user will use their account through the mobile application. Once authenticated, this user is today using a bearer token.
• Merchant user. This user will use their account similarly as a retail end user, but may have the way to delegate account access for receiving a payment. and verifying the last payments.
• Support staff. There is currently only one level, but there should eventually have several level of authorization to be able to scale the support. The lowest entry should be able to see basic account information, mostly with read access, or write access on items that have limited security/privacy risk (ie: see account information, when the account was last used, add information related the map for business, etc). "Managers" would be provided more access like reseting password, see the full balance and list of transactions, etc.
• Cluster owner. The owner will upgrade the software for the Galoy software, and provider debug assistance for things that require digging in the logs.

Currently the first 3 categories use a JWT auth. The last one relies on kubernetes/gcp auth.

Some FAQ:

• Why we want to build that in an open source fashion and try to not depend on third party library? Because we want anyone to deploy their solution and it should fully relies on FOSS at least to have all the basic functionality. Note that we currently don't respect this rules currently as we have a dependency on twilio for sending the text.

• Do we need access token + refresh token? I don't think this is needed. This dual token architecture seems very useful for when there is an authentication server that is independent from other resources, and when we don't want the round trip to the auth server for every request. like in the cloud for instance. on our end, we pull the user data for every request this user is making, so having a refresh seems superfluous.