Ответ 1

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

Авторизация OAuth2

Из его звуков вы заинтересованы в использовании OAuth 2 для предоставления социальной авторизации входа в систему и хотели бы использовать аутентификацию в качестве альтернативы электронной почтой и паролем. Для социальных логинов вы в конечном итоге используете OAuth 2 Implicit flow для получения токена доступа, который является широко признанным шаблоном. Поскольку вы также хотите аутентифицировать пользователей по электронной почте и паролю, вы можете ознакомиться с OpenID Connect, который является расширением OAuth 2 и который явно поддерживает аутентификацию в дополнение к авторизации.

В любом случае, как только ваш пользователь либо отправил комьюнити электронной почты/пароля, либо предоставил разрешение через поставщиков социальных идентификаторов, вы получите в ответ токен доступа и (необязательно) идентификатор. Токены, вероятно, JWT (JSON Web Token, см. jwt.io) будут встречаться как закодированная в base64 строка, которую вы можете декодировать для проверки результатов JWT, который будет включать в себя такие вещи, как идентификатор пользователя и другие данные, такие как адрес электронной почты, имя и т.д.

Подробнее о различных типах потоков см. этот отличный обзор в Digital Ocean.

Использование токенов для аутентификации API

Теперь, когда у вас есть токен доступа, вы можете передать его вместе со всеми запросами вашего API, чтобы продемонстрировать, что вы правильно прошли аутентификацию. Вы сделаете это, пропустив токен доступа в своих HTTP-заголовках, в частности заголовок Authorization, предварительно поместив маркер доступа в base64 (то, что вы изначально получили в ответ на ваш запрос авторизации) с помощью Bearer. Итак, заголовок выглядит примерно так:

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJh...

На стороне API вы получите этот токен, декодируете его, а затем проверьте идентификатор и претензии в нем. Передано как часть токена в свойстве sub будет субъектом или идентификатором пользователя, делающего запрос. Вот как вы определяете доступ и начинаете делать что-то со своей стороны API с соответствующими правами пользователя, perms и т.д. Также важно, чтобы вы проверяли токен доступа после его получения на стороне вашего API, чтобы гарантировать, что он не был подделан или обработан вручную.

Как он выглядит в RN для неявных потоков

Вот как выглядит общий процесс в React Native для OAuth 2 Неявные потоки, которые вы будете использовать для поставщиков социальных идентификаторов:

• Пользователь удаляет одну из ваших социальных кнопок входа в пользовательский интерфейс React Native
• Ваш код, который реагирует на кнопки, будет создавать URL-адрес запроса для этих поставщиков, в зависимости от того, что каждый хочет (потому что он немного отличается).
• Используя API Linking в RN, вы откроете этот URL-адрес в браузере на устройстве, которое отправит пользователя к социальному провайдеру, чтобы они выполнили танец входа/авторизации.
• После завершения, социальный провайдер перенаправит пользователя на URL-адрес поставщика. На мобильном устройстве вы будете использовать свою собственную схему URL-адресов, чтобы переместить пользователя из веб-представления в ваше приложение. Эта схема - это то, что вы регистрируете как часть своего приложения, например my-awesome-app://, а URL-адрес перенаправления, который вы передаете социальному провайдеру, может выглядеть как my-awesome-app://auth_complete/. См. Документы Linking API для настройки этих схем URL и глубокой привязки.
• В обработчике этой новой схемы URL/глубокой ссылки вы получите маркеры, переданные как часть URL-адреса. Либо вручную, либо используя библиотеку, проанализируйте токены из URL-адреса и сохраните их в своем приложении. В этот момент вы можете начать проверку их как JWT и передать их в заголовках HTTP для доступа к API.

Как он выглядит в RN для потоков ресурсов владельца ресурса

У вас есть опция для вашей учетной записи электронной почты/пароля для ваших собственных учетных записей, либо придерживающихся неявного потока, либо перехода к потоку предоставления пароля владельца ресурса, если ваш API и приложение доверяются друг другу, что означает, что вы делаете как приложение, так и API. Я предпочитаю поток ROPG в мобильных приложениях, где это возможно, потому что UX намного приятнее - вам не нужно открывать отдельный веб-просмотр, вы просто вводите их свой адрес электронной почты и пароль в элементы интерфейса непосредственно в приложении. Так что, если сказать, вот как это выглядит:

• Пользователь удаляет кнопку входа в систему электронной почты/пароля, а RN отвечает пользовательским интерфейсом, который включает в себя TextInputs для электронной почты и пароля.
• Создайте запрос POST на ваш сервер авторизации (который может быть вашим API или может быть отдельным сервером), который включает в себя правильно созданный URL-адрес и данные тела, которые проходят по электронной почте и паролю. Прогоните этот запрос.
• Сервер авторизации будет отвечать соответствующими токенами в теле ответа. На этом этапе вы можете сделать то же самое, что было сделано ранее на шаге 5 выше, где вы храните токены для последующего использования в запросах API и проверяете их для соответствующей информации пользователя.

Как вы можете видеть, ROPG более прост, но его следует использовать только в сценариях с высокой степенью надежности.

В API

На стороне API вы проверяете токен в заголовке авторизации и, как упоминалось ранее, и, если он найден, вы предполагаете, что пользователь был аутентифицирован. До сих пор хорошая практика безопасности действительна и проверяет права доступа к токенам и пользователям. Если токен не отправлен с запросом, или если отправленный токен истек, то вы отклоняете запрос.

Надеюсь, что это поможет! Там определенно тонна, но это дает общий план.