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

Question

[Данил Чекалин]

Пишу мобильное приложение на react-native (только android) и стоит задача реализовать регистрацию пользователя на основе номера телефона, а также в последующем иметь условно говоря постоянную сессию. Подобные механики реализованный например в telegram. Но я не понимаю на базе чего (session, jwt, api token или еще что-то) реализовать автоматическую авторизацию при последующих запусках приложений, собственно я и сам flow не очень понимаю.

Comments

[Никита]

Не знаю как react-native, но Android SDK содержит системный механизм (Account Manager)для хранения учёных данных и позволяет произвести идентификацию. Если ещё и подтверждение по номеру телефона, посмотрите в сторону Firebase. Думаю Гугл даст примеров

Answer 1

[azShoo]

Если максимально упрощенно:
1) Проверяем уникальность телефона
2) Подтверждаем владение телефоном
3) Выписываем Auth-Token сохраняемый в приложении и в любом хранилище.
4) Следим за актуальностью Auth-Token: при разлогине удаляем из хранилища, при окончании срока жизни - тоже.
5) При старте приложения и последующих коммуникациях сервер-клиент-сервер шлем и валидируем AuthToken.

Comments

[Данил Чекалин]

на какой срок стоит устанавливаться жизнь токена?

[azShoo]

Данил Чекалин, это сильно зависит от приложения и его специфики.
Как вы понимаете, интернет-банк не должен держать сессию живой максимально долго, а условный Spotify - должен.
В случае с телеграмом это очевидный security reason, гарантирующий что логинящийся имеет доступ к телефону, к которому привязан аккаунт. Но сессия, AFAIK, у них живет бесконечно, пока её не оборвут разлогином\обрывом сессии с другого аккаунта.
В случае с условной онлайн игрой - это будет явный оверхед и боль пользователей.

Answer 2

[Владимир Дубровин]

Чаще всего делается схема 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 (на доступ к кокретной ручке или сервису)