Архитектура аутентификации для собственного приложения Salesforce "connect app"

Question

Я хочу создать общедоступное реактивное приложение (загружаемое через App Store и Google Play) для моей некоммерческой организации, которое отображает цифровую карту участника на основе своей истории пожертвований, хранящейся в нашей базе данных Salesforce (с использованием NPSP).

Моя основная идея состоит в том, чтобы пользователь аутентифицировался с использованием некоторой схемы аутентификации без пароля (react-native-lock Есть ли что-нибудь еще для собственных мобильных приложений?) Затем используйте имя и адрес электронной почты этого аутентифицированного пользователя в качестве параметров запроса при вызове API Salesforce REST. Я думал о жестком кодировании ключа потребителя и секрета потребителя при создании / регистрации моего "подключенного приложения" Salesforce, или о жестком кодировании ключа потребителя, а затем обогащении вызова API секретом потребителя из приложения / сервера Heroku, который затем перешлите вызов API в Salesforce. Является ли избыточный прокси-сервер API избыточным без дополнительной безопасности?

Я думал, что создам пользователя Salesforce с правами только для чтения, чьи учетные данные, я полагаю, будут также жестко запрограммированы в приложении? И этот жестко закодированный аутентифицированный пользователь Salesforce, доступный только для чтения, может сделать вызов API с именем пользователя приложения и адресом электронной почты в качестве параметров запроса, чтобы получить информацию о пожертвовании для определения членства. Это звучит безумно для меня, но я не могу придумать другой способ сделать это.

Я обеспокоен тем, что, создавая это приложение, я буду подвергать нашу базу данных таким образом, чтобы ее было трудно защитить должным образом. Это ужасная идея для нативной архитектуры приложений? Как еще я могу достичь своей цели, предоставив участникам цифровую членскую карту в собственном приложении, используя реактивную аутентификацию без пароля и систему Salesforce? Я не думаю, что мы хотим создавать пользователей Salesforce для каждого нашего донора. Мне это тоже не кажется правильным.

Answer 1

Любой вид секрета и / или учетных данных, жестко закодированных в собственном мобильном приложении, приложении браузера или любом другом приложении, где код запускается на клиенте, больше не может считаться секретным.

Вы указали на то, что я также рекомендую, у вас должен быть какой-то серверный компонент, где хранение ключей API и / или жестко закодированных учетных данных можно считать безопасным.

Этот серверный компонент будет выполнять всю связь с чувствительными частями системы (Salesforce) после того, как он будет вызываться аутентифицированным пользователем, который в вашем случае является просто пользователем, который прошел этапы аутентификации без пароля и вызов сервера из мобильного приложения с токеном, который представляет его личность.

Еще одна вещь, которую нужно иметь в виду, это то, что в случае без пароля аутентификации в зависимости от используемого канала у вас может не быть электронной почты пользователя после первого входа в систему. Например, если пользователю разрешено получать одноразовый код с помощью SMS, а входными данными для вашего запроса Salesforce является электронное письмо, вам необходимо после аутентификации пользователя запросить у него дополнительную информацию, в данном случае его электронную почту. Также обратите внимание, что в этих случаях, если вы не убедитесь, что пользователь является владельцем предоставленной электронной почты, вы можете разрешить кому-либо запрашивать статус пожертвования кого-либо еще. Лучше всего поддерживать аутентификацию без пароля только по электронной почте.