Обновление токена в Oauth2 Implicit Grant Flow и сторонних куки

Question

Интересно, как поступить с обновлением токена в Oauth2? Поток неявных грантов в 2019 году, когда по умолчанию в основных браузерах отключены сторонние файлы cookie.

Некоторые детали:

Текущая настройка:

• Приложение UI SPA под ui.example.com

• Идентификационные данныеПоставщик (UAA от CloudFoundry) в uaa.api.example.com

Сценарий:

• , когда пользователь входит в систему, Identity Provider устанавливает cookie с данными пользователя для доменаuaa.api.example.com и возвращает JWT в заголовке Location перенаправления.

• JWT хранится в локальном хранилище (для ui.example.com), но оно действительно только в течение 1 часа, поэтому я бынравится обновлять его.

• возможно обновление с помощью prompt=none параметра запроса, отправленного конечной точке авторизации IDP (процесс хорошо описан в руководстве Auth0 (это не UAA, но поток являетсяТо же самое )

• в каждые 20 м скрытого iframe с src, установленным на uaa.api.exmaple.com/oauth/authorize?prompt=none, который создает процесс входа в систему, не требуя от пользователя предоставления своих учетных данных. Когда процесс завершается, новыйJWT, возвращенный в ответе, снова сохраняется в локальном хранилище.

Проблема:

• Когда разрешены сторонние куки, браузер добавляет куки IDP к запросу, сделанному iframe, поэтому поток работает, и я получаю новый токен в ответе.

• Когда сторонние файлы cookie отключены в настройках браузера, iframe не имеет доступа к своим собственным файлам cookie, поэтому вместо нового JWT возвращается ошибка login_required.Невозможность доступа к файлам cookie с помощью iframe делает невозможным использование обновления токена

Вопрос:

Есть ли какое-либо решение для моей проблемы с файлами cookie третьих сторон?

Если нет, есть ли какие-либо альтернативы для потока неявного предоставления и SPA, которые я мог бы использовать для входа и обновления токенов?

Answer 1

Наконец, мы решили пойти с другим решением.Когда время жизни JWT заканчивается, мы отображаем модальное сообщение о том, что время сеанса истекло, и две кнопки: одна для выхода из системы и одна для сохранения сеанса.Когда пользователь нажимает «сохранить сеанс», открывается новая вкладка / всплывающее окно, где пользователь повторно проходит аутентификацию в IDP, либо предоставляя свои учетные данные снова или автоматически, если сеанс IDP все еще активен.

Таким образом, поток:

JWT lifetime ends -> 'keep session' in modal chose -> open new tab/popup-window with IDP login form -> successfully authenticated -> redirect back to app -> store token in browser's storage -> close popup-window/tab with window.close()-> get new token from storage and use it in next calls

Поскольку мы используем новое всплывающее окно / вкладку для повторной аутентификации, проблем со сторонними файлами cookie не возникает.

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

Критерий успеха 2.2.5 Повторная проверка подлинности

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

Answer 2

Вопрос:

Есть ли какое-либо решение для моей проблемы с файлами cookie третьих сторон?

Если вы используете один и тот же домен верхнего уровня между вашим приложением и вашим IDPтогда у вас не должно быть проблем, когда сторонние куки отключены. Эта ссылка также подробно описывает использование междисциплинарных политик со смешанным успехом.

Если нет, есть ли альтернативы для потока неявного предоставления и SPA, которые я мог бы использовать для входа и обновлениятокены?

Раньше я не использовал CloudFoundry, но большинство крупных поставщиков OAuth2.0 предлагают функциональность общедоступного клиента, когда общедоступному клиенту (например, вашему SPA) не требуется секрет клиента для получения доступа /обновить токен.Это позволяет общедоступным клиентам использовать Предоставление кода авторизации , который позволяет обновлять токены с помощью токена обновления, избегая, таким образом, тихой аутентификации метода использования HTTP-перенаправлений и файлов cookie.

Answer 3

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

Я думаю, что причиной использования iframe является доступ к cookie-файлам через домены.Теперь, самый простой способ избежать использования iframe - это установить домен cookie как Domain=example.com, а пользовательский интерфейс и сервер авторизации - на example.com.Если по какой-либо причине вы не можете этого сделать, вам необходимо придерживаться следующего подхода:

---

Рекомендуемая опция

Неявный тип предоставления не защищен.Хотя этот вопрос не о плюсах и минусах типов грантов, для того, чтобы установить фон для опции, которую я собираюсь объяснить, позвольте мне кратко перечислить причины, по которым я говорю, что неявный поток не защищен:

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

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

Здесь(в типе предоставления кода авторизации) процесс выглядит следующим образом:

1. пользователь нажимает кнопку входа в систему на целевой странице SPA
2. пользователь перенаправляется на сервер авторизациистр.Идентификатор клиента указывается в параметре запроса URL

3. . Пользователь вводит свои учетные данные и нажимает кнопку входа в систему.Имя пользователя и пароль будут отправлены на сервер авторизации с использованием HTTP POST.Учетные данные следует отправлять в теле или заголовке запроса, а НЕ в URL (так как URL-адреса регистрируются в истории браузера и на сервере приложений).Кроме того, должны быть установлены правильные заголовки кэширования HTTP, чтобы учетные данные не кэшировались: Cache-Control: no-cache, no-store, Pragma: no-cache, Expires: 0

4. Сервер авторизации аутентифицирует пользователя по пользовательской базе данных (скажем, серверу LDAP), где имя пользователя и хеш пароля пользователя (алгоритмы хеширования, такие как Argon2, PBKDF2, Bcrypt или Scrypt) хранятся со случайной солью

5. При успешной аутентификации сервер авторизации извлекает из своей базы данных URL-адрес перенаправления по указанному идентификатору клиента в параметре запроса URL-адреса.URL-адрес перенаправления - это URL-адрес сервера ресурсов
6. . Затем пользователь будет перенаправлен на конечную точку сервера ресурсов с кодом авторизации в параметре запроса URL-адреса
7. . Затем сервер ресурсов выполнит запрос HTTP POST.к серверу авторизации для токена доступа.Код авторизации, идентификатор клиента, секрет клиента должны быть указаны в теле запроса.(Следует использовать соответствующие заголовки кэширования, как указано выше)
8. Сервер авторизации возвращает токен доступа и токен обновления в теле или заголовке ответа (с соответствующим заголовком кэширования, как упомянуто выше)
9. сервер ресурсов теперь перенаправляет пользователя (код ответа HTTP 302) на URL-адрес SPA, установив соответствующие файлы cookie с атрибутом домена как Domain=example.com (при условии, что оба сервера ресурсов и пользовательский интерфейс находятся в поддоменах example.com).Домен сервера авторизации не имеет значения, поскольку он не устанавливает файлы cookie.

Таким же образом, запрос на обновление токена доступа может быть отправлен на прокси-компонент, который будет считывать токены обновления и доступа из куки-файла и вызывать API-интерфейс авторизации с извлеченными таким образом токенами, идентификатором клиента иСекрет клиента.

Answer 4

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

Ответы на ваши вопросы:

Есть ли какие-либорешение моей проблемы с файлами cookie сторонних производителей?

Разместите ваше приложение и сервер идентификации в одном домене.В этом случае вы можете использовать поддомен.

Если нет, есть ли какие-либо альтернативы для потока неявного предоставления и SPA, которые я мог бы использовать для входа и обновления токенов?

Нет

Решение:

Я не знаком с CloudFoundry.Не уверен, что они поддерживают это или нет.Вы можете решить эту проблему, включив пользовательский домен на стороне провайдера идентификации.Таким образом, ваше приложение и провайдер идентификации будут находиться в одном домене, и файлы cookie будут рассматриваться в качестве первой стороны.Например, разместите ваше приложение по адресу https://acme.com и установите для настраиваемого домена вашего поставщика удостоверений значение https://login.acme.com