Можно ли настроить Keycloak для хранения токена доступа / JWT как токен на предъявителя, а не как cookie?

Question

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

Можно ли настроить Keycloak, чтобы вместо этого хранить токен доступа непосредственно как токен на предъявителя, а не в cookie?

Когда я хочу использовать Keycloak для защиты веб-приложенияОднако большинство ресурсов, которые я читал по Аутентификации, обычно говорят о токенах доступа, которые хранятся как токены носителя, а не как куки.

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

Answer 1

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.

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

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