Реализует ли Keycloak и его различные адаптеры спецификацию выхода из системы Openid Connect Backchannel

Keycloak поддерживает выход из системы по обратному каналу, но соответствует ли он спецификации выхода из системы по обратному каналу Openid Connect? https://openid.net/specs/openid-connect-backchannel-1_0.html

2 ответа

Решение

Выход из системы OpenID Connect по обратному каналу был реализован в Keycloak 12.0, выпущенном в декабре 2020 года .

В более ранних версиях реализован только альтернативный частный механизм.

Это проблема Jira от Keycloak по этой теме. Иди и проголосуй за это!

После ознакомления со спецификацией и реализацией Keycloaks я должен сказать, что она НЕ соответствует спецификации. Например, это разница в требуемом формате токена выхода, который должен быть отправлен из OP в RP:

2.4. Токен выхода

OP отправляют JWT, аналогичный идентификатору токена, RP, называемый токеном выхода, чтобы запросить выход из системы. Идентификационные токены определены в Разделе 2 [OpenID.Core].

В токене выхода из системы используются следующие утверждения:

iss
    REQUIRED. Issuer Identifier, as specified in Section 2 of [OpenID.Core]. 
sub
    OPTIONAL. Subject Identifier, as specified in Section 2 of [OpenID.Core]. 
aud
    REQUIRED. Audience(s), as specified in Section 2 of [OpenID.Core]. 
iat
    REQUIRED. Issued at time, as specified in Section 2 of [OpenID.Core]. 
jti
    REQUIRED. Unique identifier for the token, as specified in Section 9 of [OpenID.Core]. 
events
    REQUIRED. Claim whose value is a JSON object containing the member name http://schemas.openid.net/event/backchannel-logout. This declares that the JWT is a Logout Token. The corresponding member value MUST be a JSON object and SHOULD be the empty JSON object {}. 
sid
    OPTIONAL. Session ID - String identifier for a Session. This represents a Session of a User Agent or device for a logged-in End-User at an RP. Different sid values are used to identify distinct sessions at an OP. The sid value need only be unique in the context of a particular issuer. Its contents are opaque to the RP. Its syntax is the same as an OAuth 2.0 Client Identifier. 

Токен выхода из системы ДОЛЖЕН содержать либо sub, либо sid, и МОЖЕТ содержать оба. Если Заявление sid отсутствует, намерение состоит в том, чтобы завершить все сеансы в RP для Конечного пользователя, идентифицированного с помощью утверждений iss и sub.

И вот что Keycloak отправляет в своей текущей версии (8.0.1):

{
  "id": "3536c4c4-fa51-4691-bc09-d229df83f774-1579360301277",
  "expiration": 1579360331,
  "resource": "resource-server-1",
  "action": "LOGOUT",
  "adapterSessionIds": [
    "6569208C4937FD9C6E138C9DD9CF7C6F"
  ],
  "notBefore": 0,
  "keycloakSessionIds": [
    "ca8060fd-48e9-4d26-b2d6-d6edb095f4b7"
  ]
}
Другие вопросы по тегам