OpenId Connect обновляет access_token в SPA

Попытка реализовать OpenId Connect в веб-приложении, состоящем из следующих компонентов

  • Провайдер идентификации
  • Сервер ресурсов
  • Одностраничное приложение, выступающее в роли клиента.

Поставщик удостоверений и сервер ресурсов - это одно и то же приложение.

SPA использует поток паролей для получения access_token и сохранения в cookie. Сохранение access_token в cookie имеет потоки безопасности, но это другая история.

Проблема

Срок действия access_token, выданного IdP, истекает через 30 минут, и SPA необходимо обновить токен без повторного запроса учетных данных у пользователей.

Решение

IdP возвращает refresh_token вместе с access_token. Когда SPA получает 401 от сервера ресурсов, он отправляет refresh_token IdP и возвращает новый access_token.

Проблема

Отправка refresh_token в SPA является плохой практикой.

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

Предлагаемое решение

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

Я думаю, что Тихая аутентификация не применима к потоку паролей, когда IdP и сервер ресурсов такое же приложение. access_token, выданный IdP, - это только часть информации, которая может использоваться для авторизации на сервере ресурсов / IdP после истечения срока ее действия. Как клиент может убедить IdP выпустить новый access_token? (без отправки refresh_token)

Обнаружена библиотека angular-oauth2-oidc, которая использует refresh_token для обновления access_token.

Каков наилучший метод / решение в этом случае продлить access_token?

технические подробности

  • Поставщик удостоверений - библиотека ASP.NET Core + Openiddict.
  • SPA - приложение AngularJs.

asp.net-core oauth-2.0 openid-connect openiddict
person tchelidze    schedule 29.05.2018    source источник
comment
Есть ли причина, по которой вы избегаете неявного потока?   -  person Kavindu Dodanduwa    schedule 30.05.2018

Ответы (3)


arrow_upward
2
arrow_downward

Одностраничные приложения не должны получать токены обновления. Это было установлено правилами в OAuth 2.0 и OpenID Connect.

Я вижу здесь один хороший вариант - использовать неявный поток. Это установит сеанс переднего канала от вашего браузера к поставщику удостоверений. С типом предоставления пароля вы выполняете вызов обратного канала (POST), поэтому вы не получаете такой сеанс.

Обычно это файл cookie, который указывает на информацию о предыдущем состоянии входа в систему (это особенности поставщика удостоверений). По завершении потока SPA получит access token. Как вы уже догадались, срок его действия истечет. Но как только это произойдет, SPA может запустить другой неявный поток, но на этот раз с параметром запроса prompt.

подсказка

Разделенный пробелами, чувствительный к регистру список строковых значений ASCII, который указывает, запрашивает ли сервер авторизации конечного пользователя для повторной аутентификации и согласия. Определенные значения: нет, логин, согласие и select_account.

Если ваш провайдер идентификации поддерживает длительный сеанс (например, несколько часов или дней) или сохраняет куки-файл «запомнить меня», SPA может использовать prompt=none, чтобы пропустить шаг входа в систему от провайдера идентификации. По сути, с этим вы получаете поведение SSO на основе браузера.

person Kavindu Dodanduwa    schedule 30.05.2018
comment
Спасибо. Ваше предложение выглядит хорошо. Интересно, можно ли / безопасно встроить страницу входа IdP в страницу клиента через iframe? - person tchelidze; 01.06.2018
comment
@tchelidze Я бы сказал, чтобы избежать этого и использовать браузер и перенаправить для завершения потока. Некоторые провайдеры могут не загружать страницу входа в iframe (путем установки соответствующих заголовков). - person Kavindu Dodanduwa; 01.06.2018
comment
Внешний IdP обычно не хочет, чтобы его сайт загружался в ненадежной среде. Но в моем случае IdP, RP и RS - мои. Что думаешь ? - person tchelidze; 01.06.2018
comment
@tchelidze Вы можете продолжить такой подход. Но в будущем вы, возможно, захотите поддержать других поставщиков удостоверений. Так что помните и о таких потребностях - person Kavindu Dodanduwa; 02.06.2018

arrow_upward
2
arrow_downward

Использование потока учетных данных пароля владельца ресурса побеждает аргумент хранилища токена обновления: вместо того, чтобы хранить токен обновления в безопасном месте, SPA теперь должен будет хранить учетные данные владельца ресурса в безопасном месте (при условии, что вы хотите избежать часто запрашивать имя пользователя / пароль у пользователя). Неявный грант был разработан для использования с SPA, поэтому лучше его придерживаться.

person Hans Z.    schedule 30.05.2018

arrow_upward
1
arrow_downward

В дополнение к предыдущим ответам, последнее руководство рабочей группы OAuth для SPA больше не рекомендует использовать неявный поток.

Если у вас есть простое приложение с общим доменом (IdP, RS и клиент в одном домене), вам следует вообще отказаться от использования OAuth. Из документа:

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

Если вы используете OIDC / OAuth в SPA, они рекомендуют поток кода аутентификации с помощью PKCE .

person Nick Cox    schedule 24.09.2019