Authentication architecture for react-native Salesforce "connect app"

Question

I want to create a public-facing react-native app (downloaded via the App Store and Google Play) for my non-profit organization that displays a digital membership card based on their donation history stored in our Salesforce database (using NPSP).

My basic idea is to have the user authenticate using some type of passwordless authentication scheme (react-native-lock, is there anything else for native mobile apps?) then use that authenticated user's name and email as query parameters in an API call to Salesforce's REST API. I was thinking of either hard coding both the consumer key and consumer secret from the creation/registration of my Salesforce "connected app", or hardcoding the consumer key and then enriching the API call with the consumer secret from a Heroku app/server that would then forward on the API call to Salesforce. Is the enriching proxy API server overkill with no added security?

I was thinking that I would create a Salesforce user with read-only permissions, whose credentials I guess would be hardcoded into the app as well? And that hardcoded authenticated Salesforce read-only user could make the API call with the app user's name and email as query parameters to retrieve donation information to determine membership. That sounds crazy to me, but I can't think of another way to do this.

My concern is that by building this app I would be exposing our database in a way that would be difficult to secure properly. Is this a terrible idea for a native app architecture? How else could I achieve my goal of presenting members with a digital membership card in a native app using react-native, passwordless authentication and Salesforce? I don't think we want to create Salesforce users for each donor that we have. That doesn't seem correct to me either.

Answer 1

Any kind of secret and/or credential hardcoded in a native mobile application, browser application or any other application where the code is run on the client can no longer be considered secret.

You pointed to what I would also recommend, you should have some sort of server-side component where the storage of API keys and/or hardcoded credentials can be considered safe.

That server-side component will do all the communication with the sensitive parts of the system (Salesforce) after ensuring that it's being called by an authenticated user, which in your case, is just a user that has gone through the passwordless authentication steps and is calling the server from the mobile application with a token that represents its identity.

Another thing to have in mind is that with Passwordless Authentication depending on the channel being used you may not have a user email after the first login. For example, if the user is allowed to receive a one time code via SMS and the input to your Salesforce query is an email then you need after the user authenticate to ask him for additional information, in this case his email. Also note, that in these cases unless you verify that the user is the owner of the provided email you could be allowing anyone to query the donation status of anyone else. Might be best to only support passwordless authentication through emails.