Settings

• Client ID

  Уникальный идентификатор клиента

• Name

  Отображаемое имя (например, в окне согласия (Consent))

• Description

  Описание

• Enabled

  Вкл/Выкл

• Always Display in Console

  Всегда показываться клиента в списках приложений пользователя в Account Management Console

  

• Consent Required

  Выводить окно согласия предоставления пользовательских данных клиенту

  

• Login Theme

  Тема оформления для клиента. Переопределяет тему, заданную в настройках реалма

• Client Protocol

  Протокол, используемый для аутентификации (oidc, saml)

• Access Type

  По сути определяет тип клиента. Браузерное фронтовое приложение (Public) | Бэкенд, который модет получать токен и обращаться к другим бэкендам (Confidential) | Бэкенд, который только проверяет другие токены и нам нужно, чтоб keycloak знал о нём, чтобы правильно добавлять поля в токен, типа aud (Bearer-only)

• Standart Flow Enabled

  Authorization Code Flow в терминах oidc

  

  Источник изображения: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow

• Implicit Flow Enabled

  

  Источник изображения: https://auth0.com/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post

• Direct Access Grants Enabled

  Resource Owner Password Credentials Grant в терминах oidc Разрешает напрямую передавать клиенту имя пользователя и пароль, чтобы клиент мог самостоятельно получить пользовательских токен

• Service Accounts Enabled

  Access Type: confidential Client Credential Grant в терминах oidc Позволяет клиенту иметь некие учётные данные (client_id+secret, signed jwt, etc…), с помощью которых он может получать токены

• OAuth 2.0 Device Authorization Grant Enabled

  Относится к OAuth 2.0 Device Authorization Grant

• OIDC CIBA Grant Enabled

  Access Type: confidential Относится к OIDC Client-Initiated Backchannel Authentication

• Authorization Enabled

  Включить настройку правил авторизации (появляется отдельный там Authorization)

• Front Channel Logout

  Если включено, используется Front Channel Logout, когда логаут запросы отправляются клиентам из браузера, иначе Back Channel Logout, когда keycloak сам отправляет запросы клиентам Front Channel Logout

  

  Источник изображения: https://www.youtube.com/watch?v=ObWSeNYkh8s Back Channel Logout

  

  Источник изображения: https://piraveenaparalogarajah.medium.com/configuring-openid-connect-back-channel-logout-using-wso2-identity-server-8c758310525f

• Front-Channel Logout URL

  Front Channel Logout: true Куда редиректить после логаута

• Root URL

  Если в параметрах, типа Valid Redirect URIs, Base URL и др. используются относительные пути, то здесь можно задать рутовый, который будет к ним добавлен. Т.е. параметр чисто для удобства. Root URL: https://example.com, Valid Redirect URIs: /somepath в результате Valid Redirect URIs по факту будет https://example.com/somepath

• Valid Redirect URIs

  Standard Flow Enabled: true URL’ы, на которые разрешено перенаправлять после логина в keycloak при использовании Standart Flow. По сути, это то, куда можно передавать Authorization Code, сгенерированный keycloak’ом, для дальнейшего получения токена

• Base URL

  URL, по которому keycloak может общаться с клиентским API

• Admin URL

  URL, по которому через API keycloak может отправлять клиенту различную административную информацию, типа политик или backchannel logout. Поддержка обработки таких запросов должна быть реализована в API клиента. Если не задано, используется Base URL

• Logo URL

  URL логотипа клиента. Например, для отображения на странице согласия (Consent)

• Policy URL

  URL на политику обработки данных (Privacy Policy)

• Terms of service URL

  URL на Условия пользования (TOS)

• Web Origins

  Standard Flow Enabled: true Значение хидера Access-Control-Allow-Origin, который будет отдавать keycloak в ответе, когда к нему через ajax будут приходить запросы от веб-приложения, открытого в браузере. Защита от XSS, CSRF атак. Защиту реализует сам браузер, читая значение хидера и запрещая использовать ответ сервера, если в заголовке нет текущего открытого URL

• Backchannel Logout URL

  URL, на который должен быть отправлен запрос для логаута из реалма при логауте пользователя через Backchannel. Если не задано, используется Admin URL

• Backchannel Logout Session Required

  Включать или нет session_id (sid) в logout токен при использовании Backchannel Logout URL

• Backchannel Logout Revoke Offline Sessions

  Добавлять в logout токен revoke_offline_access, который означает, что клиенту также необходимо удалить сессии offline токенов при использовании Backchannel Logout

Credentials

Здесь можно задать учётные данные для аутентификации клиента, в случае если в клиент настроен с Access Type: confidential и Service Accounts Enabled: true

Keys

Если в Credentials используется Signed JWT как учётные данные клиента, то в этом разделе можно настроить то, как проверять подпись JWT-токена

Roles

Роли, специфичные для клиента. Роль может быть назначена обычным и service-account пользователям. В токене роли будут перечислены в scope resource_access.<client>.roles, если у клиента <client>, в настройках Scope разрешено добавление этой роли в токен

Client Scopes

Переопределяет реалмовые Client Scopes, которые были применены при создании клиента

Mappers

Маппинги, которые в том числе позволяют прокидывать/изменять параметры в scope, добавляемые в токен

Scope

Позволяет ограничить то, какие роли добавляются в scope токена. Например, пользователь аутентифицируется в веб-приложении, которое использует клиента Client1 для работы с keycloak, при этом у пользователя добавлена роль RoleClient2 клиента Client2. Мы не хотим, чтобы в токене, получаемом для Client1 были указаны роли для клиента Client2. В таком случае мы отключаем Full Scope Allowed и настраиваем, какие конкретно роли разрешено добавлять в токен.

Authorization

Authorization Enabled: true

Revocation

Позволяет отозвать/пометить невалидными все сессии и токены, полученные ДО указананной даты. Кнопкной Set to now будет установлено Not Before на текущую дату, а затем через Push нужно отправить эту политику всем клиентам на настроенные для них Admin URL. На клиенте должен быть реализован API и функции, которые применяют эти политики, чтобы по факту начать отбрасывать невалидные токены и сессии.

Sessions

Позволяет смотреть текущии активные сессии для данного клиента

Offline Access

Позволяет посмотреть, кто и когда получил offline токены

Installation

Здесь просто можно сгенерировать конфиги для подключения приложений к keycloak

Service Account Roles

Позволяет задать роли для service-account пользователя текущего клиента, если Access Type: confidential и Service Accounts Enabled: true