#spring-boot #spring-security #openid-connect #spring-security-oauth2
#весенняя загрузка #spring-безопасность #OpenID-connect #spring-security-oauth2
Вопрос:
очевидно, я не очень хорошо разбираюсь в механике OpenID OAuth2 — просто знаю самые основы.
Я успешно использовал spring-boot-starter-oauth2-client для создания моего клиента OAuth2. Сервер, с которым я разговариваю, имеет хорошо известную конечную точку, которая описывает службу. Недавно они изменили эту реализацию конечной точки, чтобы включить в возвращаемый результат различную информацию, такую как поддерживаемые алгоритмы.
В случае некоторых конкретных полей, например, скажем, «id_token_signing_alg_values_supported», включен дополнительный алгоритм «none».
Когда я указываю конфигурацию oauth2 для поиска описания в новой .хорошо известной конечной точке с этими записями алгоритма «none», я получаю исключение синтаксического анализа из кода библиотеки oauth2-oidc-sdk:
Caused by: com.nimbusds.oauth2.sdk.ParseException: The none algorithm is not accepted
at com.nimbusds.oauth2.sdk.as.AuthorizationServerMetadata.parse(AuthorizationServerMetadata.java:1560) ~[oauth2-oidc-sdk-7.1.1.jar:7.1.1]
at com.nimbusds.openid.connect.sdk.op.OIDCProviderMetadata.parse(OIDCProviderMetadata.java:1190) ~[oauth2-oidc-sdk-7.1.1.jar:7.1.1]
...
Я понимаю, что, вероятно, клиентский код недоволен тем, что сервер принимает алгоритм «none» для некоторых записей. Я предполагаю, что сервер, с которым я разговариваю, не должен предоставлять клиентам способы отправки на него незашифрованных данных… но — если это так — я простой клиент — могу ли я не забыть об этом и игнорировать это разрешение, которое сервер дает мне для использования этого алгоритма «none»? Нет ли способа переопределить это поведение? Я просмотрел код oauth2-oidc-sdk и не могу найти никаких средств для этого.
Спасибо.
[редактировать:] В частности, oauth2-oidc-client не принимает значение алгоритма «none» в следующих хорошо известных записях конфигурации:
- поддерживается token_endpoint_auth_signing_alg_values_supported
- поддерживается introspection_endpoint_auth_signing_alg_values_supported
- revocation_endpoint_auth_signing_alg_values_поддерживается
Ответ №1:
Алгоритм none — очень плохая идея, потому что с помощью этого алгоритма любой может создавать свои собственные токены или изменять существующие токены, а получатель токена не может ему доверять. Также было много уязвимостей в системе безопасности, связанных с none.
Как этот:
Комментарии:
1. спасибо — я немного подожду, надеясь, что, возможно, кто-нибудь придумает решение для переопределения этого пустого отказа от части клиентской библиотеки для анализа этой конфигурации — в противном случае пометит это как ответ
2. Никаких проблем! Вы не можете отключить алгоритм none на сервере?
3. это сторонний сервер 🙂
4. просто сумасшедшая мысль, но не могли бы вы просто скопировать документ обнаружения со стороннего сервера и разместить его собственную версию. И удалить из него alg none? Конечно, если он изменится на srever, вы не заметите, но это быстрый способ начать движение.
5. спасибо за предложение. да, я пробовал это, вроде бы — но есть некоторый сбой — некоторые значения, похоже, из конфигурации, вычисляются на основе базового URL, который я указываю в качестве местоположения документа обнаружения — ну, точно, я указываю базовый URL-адрес эмитента предоставленных ресурсов (spring.security.oauth2.client.provider.some_xx_provider.issuer-uri) — и конфигурация автоматически обнаруживается на {base-url}/.well-known/OpenID-configuration — этот базовый URL, похоже, будет использован позже — поэтому, если он фиктивный, рабочий процесс oauth2 прерывается — и яне нашли способа смягчить это