Best practices: регистрация на основе номера телефона в мобильной разработке (как)?

Пишу мобильное приложение на react-native (только android) и стоит задача реализовать регистрацию пользователя на основе номера телефона, а также в последующем иметь условно говоря постоянную сессию. Подобные механики реализованный например в telegram. Но я не понимаю на базе чего (session, jwt, api token или еще что-то) реализовать автоматическую авторизацию при последующих запусках приложений, собственно я и сам flow не очень понимаю.
  • Вопрос задан
  • 753 просмотра
Решения вопроса 2
@azShoo
Если максимально упрощенно:
1) Проверяем уникальность телефона
2) Подтверждаем владение телефоном
3) Выписываем Auth-Token сохраняемый в приложении и в любом хранилище.
4) Следим за актуальностью Auth-Token: при разлогине удаляем из хранилища, при окончании срока жизни - тоже.
5) При старте приложения и последующих коммуникациях сервер-клиент-сервер шлем и валидируем AuthToken.
Ответ написан
Чаще всего делается схема refresh token + access token, т.к. она является легко масштабируемой.
1. Пользователь авторизуется на сервере авторизации по телефону, приложение получает refresh token (постоянно действующий), постоянно хранит этот токен безопасным способом.
2. При старте приложения и с некоторой регулярностью (например раз в 10 минут) или при необходимости обращения к определенному API фронт-сервера, приложением дергается API сервера авторизации с refresh token и получается access token, короткоживущий (например 15 минут). access token может быть некоторой информацией - id пользователя, timestamp, запрошенный тип сервиса и т.п. - подписанной (или зашифрованной) ключом сервера авторизации.
3. Приложение обращается к API front-серверов с access token, фронт-сервер валидирует токен
4. При разлогине (или смене пароля если он будет) инвалидируется refresh token. access token'ы "протухают" самоходом в течении интервала жизни.

Это дает:
1. совместимость с OAuth, можно использовать вход через сторонние сервисы и наоборот предоставлять им возможность что-то делать за пользователя.
2. централизованную авторизацию пользователя и управление сессиями (все токены раздаются сервером авторизации)
3. возможность завершения сессии на стороне сервера (сервер авторизации инвалидирует refresh token)
4. возможность централизовано давать или не давать доступ к отдельным концам API или серверам (через включения типа сервиса в сессионный токен, для каждого API или сервиса можно запрашивать разные токены, которые будут действительны только для них). Так же можно разделить зоны безопасности, например запрашивать отдельный токен для обращения к менее защищенным сервисам, который не даст доступа к более привилегированным сервисам.
5. фронт-серверам не требуется проверять каждый запрос на сервере авторизации, они самостоятельно могут проверить правильность таймстампа/подписи и соответсвтие типа токена запросу.

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

P.S.
иногда схема усложняется до refresh_token (постоянный) + session_token (временный) + access_token (на доступ к кокретной ручке или сервису)
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы