Как мобильные приложения получают долговременный доступ к своим API?

Наша компания строит мобильное приложение (iOS), которому необходимо поговорить с нашим API, который защищен OpenIdConnect/OAuth2, используя IdentityServer.

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

Предполагая, что они обращаются к их API с помощью токенов OAuth2, как они это достигают?

OAuth поддерживает offline_access помощью offline_access "refresh", которые позволяют получать новые токены без повторного входа пользователя в систему. Однако у них также есть срок действия - поэтому, учитывая следующий сценарий:

  1. Пользователь создает учетную запись, получает токен доступа/токен доступа. Ток доступа истекает через 1 час, обновляет токен через 2 часа.
  2. Пользователь использует приложение, приложение получает новый токен доступа/обновления в фоновом режиме
  3. Пользователь закрывает приложение
  4. Пользователь возвращается на следующий день

На данный момент и токен доступа и обновления истек. Как они получают новый, не предлагая пользователю снова вводить учетные данные?

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

Итак, я могу только думать о двух способах применения приложений:

  1. У них есть фоновые службы, которые запускаются при закрытии приложения, которое продолжает получать новые токены доступа/обновления. Это возможно?
  2. При запуске приложения, если токены доступа/обновления истекли, но токен идентификации (сеанс) все еще активен, выполните тихую поездку на сервер auth (скрытый веб-просмотр?), Который автоматически получит новый набор токенов.

2 представляется возможным, но это будет работать только в потоках OAuth на основе браузера (неявный, авторизационный код), где задействованы SSO/cookies.

Для приложений, имеющих собственный логин (U/P в приложении), они, скорее всего, используют поток учетных данных "Владелец ресурса", который не поддерживает SSO (без браузера, без файлов cookie). Итак, как они будут получать новые токены, если они не хранят обратимое имя пользователя/пароль в самом клиентском приложении, а затем снова передают их на сервер Auth для получения новых токенов?

Что мне не хватает?

Заранее спасибо.

+1
источник поделиться
1 ответ

Обычно приложения используют долгоживущие токены обновления, которые не истекают через 30 минут, как вы предлагаете, но можете жить в течение многих недель/месяцев, пока пользователь не будет снова подключен. Создание срока действия токена обновления так же, как токен доступа, поражает цель, поскольку токен обновления должен быть токеном, который может быть использован для получения нового токена доступа, когда старый истекает. Обновить токены обычно ожидают сеанс аутентификации пользователя у поставщика.

+1
источник

Посмотрите другие вопросы по меткам или Задайте вопрос