Блог

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

1. Должен ли тип доступа keycloak-клиента быть общедоступным или конфиденциальным?
2. т.е. для чего используется клиентский секрет? (Шифрование)?
3. Поэтому является ли проблемой, если администраторы компаний теоретически могут прочитать секрет, декомпилировав jar клиентского приложения, которое я им даю?

Что касается допустимых URI перенаправления: в идеале я хотел бы использовать grant-type: password, чтобы пользователь компании вводил свои учетные данные во внешний интерфейс клиентского приложения, развернутого компанией, и он входил в keycloak. Потенциально клиентское приложение, развернутое в компании, может быть повторно использовано только из интрасети компании.

4. Каким может быть URI перенаправления для этого случая?

1. Должен ли тип доступа keycloak-клиента быть общедоступным или конфиденциальным?

Из спецификации RFC 6749 OAuth 2.0 можно прочитать:

конфиденциально

   Clients capable of maintaining the confidentiality of their
  credentials (e.g., client implemented on a secure server with
  restricted access to the client credentials), or capable of secure
  client authentication using other means.
 

общедоступный

   Clients incapable of maintaining the confidentiality of their
  credentials (e.g., clients executing on the device used by the
  resource owner, such as an installed native application or a web
  browser-based application), and incapable of secure client
 

Поскольку вы используете не простое приложение для веб-браузера или мобильного телефона, а веб-приложение с защищенным бэкэндом, вам следует использовать confidential client .

т.е. для чего используется клиентский секрет? (Шифрование)?

Из документации по Keycloak:

Конфиденциальные клиенты должны предоставлять секрет клиента при обмене временных кодов на токены. Публичные клиенты не обязаны предоставлять этот секрет клиента.

Следовательно, вам нужен client-secret , потому что вы выбрали confidential client . Используется client-secret для того, чтобы приложение, запрашивающее токен доступа у Keycloak, могло быть надлежащим образом аутентифицировано. В вашем случае серверы компаний (использующие ваше приложение) запрашивают токен доступа у Keycloak. Следовательно, Keycloak должен гарантировать, что сервер, отправляющий запрос, является законным.

Это цель client-secret . Это похоже на то, что когда вы идете в банкомат и запрашиваете деньги, банк знает, что вы являетесь владельцем этого ресурса (т.Е. Банковского счета), если вы ввели правильный код (т.Е. Аналогичный секрету клиента).).

Поэтому является ли проблемой, если администраторы компаний теоретически могут прочитать секрет, декомпилировав jar клиентского приложения, которое я им даю?

Это client_secret должно быть известно приложению, запрашивающему токен (т. Е. Компании) и серверу авторизации (т.Е. Keycloak). Итак, теоретически, если компании не возражают, чтобы их администраторы имели доступ к такой информации, вас это должно устраивать. В конце концов, client-secret это должно быть известно обеим сторонам в любом случае. Способ смягчения потенциальных проблем, связанных с утечкой клиентских секретов, заключается в том, чтобы время от времени изменять клиентские секреты и сообщать об этих изменениях заинтересованным сторонам.

Пока одна компания не может перепроектировать секрет клиента другой компании, все должно быть в порядке.

Каким может быть URI перенаправления для этого случая?

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

Однако имейте в виду, что:

Вам следует принять дополнительные меры предосторожности при регистрации допустимых шаблонов URI перенаправления. Если вы сделаете их слишком общими, вы станете уязвимы для атак. Дополнительные сведения см. в главе «Смягчение модели угроз».

(источник)