Можно ли настроить Keycloak для хранения токена доступа / JWT в качестве токена-носителя вместо файла cookie?

Насколько я понимаю (что может быть неверным) Keycloak, как только пользователь вошел в систему и прошел аутентификацию, токен доступа / JWT затем сохраняется как файл cookie в браузере (под именем по умолчанию «kc-access»).

Можно ли настроить keycloak для хранения токена доступа напрямую как токена на предъявителя, а не в файле cookie?

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

В документации Keycloak я не вижу никаких упоминаний о вариантах хранения токена доступа в виде Cookie ИЛИ токена носителя - я неправильно понимаю, как Keycloak предназначен для использования для обеспечения аутентификации для веб-приложений?


keycloak jwt bearer-token
person DavidHomley    schedule 04.10.2019    source источник
comment
Не могли бы вы подтвердить, пожалуйста, - как только вы войдете в систему, вы получите файл cookie с именем «kc-access» с токеном в нем? Содержит ли он access_token или refresh_token? Вместо этого я получаю два файла cookie (под моим IP-адресом keycloak) с именами KC_RESTART и KEYCLOAK_IDENTITY, оба содержат несколько токенов, но ни у одного из них нет access_token и refresh_token.   -  person SwissNavy    schedule 06.12.2019

Ответы (1)


arrow_upward
1
arrow_downward

Keycloak используется в качестве поставщика единого входа (SSO). Таким образом, он предназначен для использования с несколькими компонентами. Он предназначен для сохранения сеанса в браузере пользователя с файлом cookie. Этот сеанс является частным для Keycloak. Затем поток аутентификации предоставляет вашему приложению токен, который аутентифицирует пользователя. Затем ваше приложение обычно устанавливает свой собственный файл cookie, чтобы установить сеанс для пользователя и избежать входа в систему на каждой странице.

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

Когда вы используете Keycloak для входа в другое приложение, такое как ваше веб-приложение, вы используете OpenID Connect (или SAML) в качестве протокола для аутентификации пользователя с помощью потока, подобного следующему:

  1. Браузер пользователя перенаправляется из вашего приложения в Keycloak,
  2. который проверяет, есть ли у пользователя уже сеанс, требует от них входа в систему (и создания сеанса), если они еще не вошли в систему с помощью keycloak
  3. Перенаправляет пользователя обратно в ваше веб-приложение с помощью короткоживущего кода
  4. Ваше приложение подключается к keycloak для обмена кода на токен.
  5. Ваше приложение считывает токен для идентификации пользователя и, возможно, сохраняет его, если ему необходимо получить доступ к сторонним ресурсам в качестве пользователя, использующего OAuth2.
  6. Ваше приложение создает файл cookie сеанса для аутентификации пользователя.

Большинство этих шагов должно выполняться библиотекой. Keycloak предоставляет множество адаптеров OpenID для популярных платформ и серверов, таких как Apache и Tomcat.

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

Вы можете найти документацию по протоколу OpenID здесь: https://openid.net/connect/faq/.

person Jonathan Villemaire-Krajden    schedule 04.10.2019