Auth0: конкретные вопросы о хранении токенов и потоке для мобильного приложения - PullRequest
Новая
       15

Auth0: конкретные вопросы о хранении токенов и потоке для мобильного приложения

0 голосов
/ 27 марта 2019

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

Вот поток, как японять это (без обработки ошибок, только happy-path ради краткости):

  • Пользователь входит в приложение впервые или еще не вошел в систему
  • Они регистрируютсяпри использовании Auth0 web-login-thingy
  • я получаю токен
  • Я могу использовать токен для аутентификации с помощью моего API

Вопросы:

  • Хранить ли этот токен?Я не хочу, чтобы мои пользователи входили в систему каждый раз, когда они используют приложение.Если я храню токен, где его хранить?

  • Если я не храню его, что мне делать?Пингую ли я конечную точку аутентификации / авторизации с Auth0 каждый раз, когда они открывают приложение и получают новый токен?

  • Скажем, я храню токены, если использую токен идентификатора дляпользовательские данные, я должен регулярно посещать API, чтобы держать это в курсе?Только когда пользователь снова откроет приложение?Только до тех пор, пока они не вызовут изменение в приложении?

  • Вместо того, чтобы использовать токен идентификатора для пользовательских данных, должен ли я просто использовать его для получения идентификатора пользователя и проверки связи с моей базой данных для пользовательских данных?

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

Спасибо !!

Ответы [ 2 ]

1 голос
/ 27 марта 2019

AsyncStorage - это простое, незашифрованное , асинхронное, постоянное, система хранения ключ-значение, которая является глобальной для приложения. [1]

Вы можете сохранить его в AsyncStorage, но это не обязательно само защищенное местоположение (например, не зашифрованное, доступное на корневых устройствах ...). Обычно клиенты выдают токены доступа, которые длятся от нескольких часов до пары дней, и они предоставляют владельцу доступ к вашим API-ресурсам. Если за экраном входа в систему находятся конфиденциальные данные, вам, вероятно, лучше просто заново выполнить поток авторизации и аннулировать старые маркеры доступа при входе в систему.

1 голос
/ 27 марта 2019

Вот краткий ответ на ваши вопросы при использовании Auth0:

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

2 & 3.См. Выше, но чтобы добавить больше информации, вы можете настроить свои токены на срок действия.теоретически вы могли бы преобразовать это «время истечения от начала» в объект даты, и можете сделать одну из двух вещей;Вы можете запросить новый токен, используя Refresh Token (который поставляется с оригиналом), как только истечет срок его действия, или заставить пользователя повторно войти в систему и выпустить новый токен в это время (я предпочитаю последний, запрещает людямпросто обновлять свои токены навсегда, пока они остаются в системе)

Используйте токен авторизации для запроса информации о пользователе после входа в систему, она может храниться в состоянии приложения / глобальных переменных / где угодно.Затем вы захотите использовать токен аутентификации в заголовке авторизации для каждого вызова API вместе с любыми данными, которые вы отправляете.это гарантирует, что даже когда кто-то находится ВНУТРИ приложения, у него должен быть действительный токен, чтобы фактически делать что-либо с данными (представьте, что кто-то заходит в ваше приложение и пропускает авторизацию, или использует что-то вроде почтальона, чтобы просто забить ваш API мусором).).это будет работать примерно так: GET userData {Header: токен auth} -> GET userProfile (отправив идентификатор пользователя, возвращенный из GET userData) PLUS {Header: токен auth}

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

Редактировать: Ресурсы об использовании безопасного хранения для ключей

Документ о том, когда использовать хранилище в памяти и постоянное хранилище.TL; DR используется в памяти, если ожидается, что срок действия ключа истекает раньше стандартной продолжительности сеанса, и является постоянным для хранения ключа между сеансами https://hackernoon.com/mobile-api-security-techniques-682a5da4fe10

ссылка на Службы цепочки ключей doc https://developer.apple.com/documentation/security/keychain_services#//apple_ref/doc/uid/TP30000897-CH203-TP1

ссылка на SharedPreferences doc https://developer.android.com/reference/android/content/SharedPreferences.html

...