使用来自 Keycloak 的 URL OIDC 参数重定向给出错误请求

Posted 2023-02-19

【中文标题】使用来自 Keycloak 的 URL OIDC 参数重定向给出错误请求

【英文标题】：Redirect with URL OIDC parameters from Keycloak gives Bad Request

【发布时间】：2017-05-14 15:43:38

【问题描述】：

我目前的设置如下：

运行 Active Directory 的 Windows Server。 在 WildFly 上运行的 Keycloak 服务器。 在 WildFly 上部署了访问受限的 Java 测试应用程序。

授权流程是来自 AD 的用户请求访问应用程序，该用户被授予 Kerberos 票证，并尝试使用该特定票证访问同一应用程序。

Kerberos、Keycloak、AD的所有配置都完成了，服务器和客户端之间的协议运行顺利，但是最后一个“GET”请求，用户已经被授予访问权限，这意味着对包含 OpenID-Connect 参数（state= 和 code=）的 Keycloak 重定向 URL 的请求返回“错误请求”。

我对使用 Keycloak 作为 SSO 提供程序的概念还很陌生，所以我可能错过了一些非常琐碎的事情。

[编辑] 如果我在 Fiddler 中对受限页面发出请求，它会给我一个“无状态 Cookie”，但是当我使用任何类型的浏览器时，它会显示“禁止”，并且我的日志显示 ERROR [org.keycloak.adapters. OAuthRequestAuthenticator]（默认任务 9）令牌验证失败：令牌颁发者无效。预期为 http://KEYCLOAK:9090/auth/realms/kerberos-realms/" 但预期为 "http://keycloak:8080/auth/realms/kerberos-realm"

【问题讨论】：

我对Keycloak不熟悉，所以我只是快速搜索了一下。读完之后，我的声明是，AD 已经提供了一个内置的、可扩展的、易于管理的、基于 Kerberos 的 SSO 解决方案。为什么还要用 Keycloak 愚弄，这会重复呢？

抱歉，这是业务需求，我没有影响。除了喊出各种坏话和负面的话，拼命想通过。

@T-Heron Keycloak 实现了 OpenID Connect 协议。在幕后，它依赖于身份提供者，可能是 AD，并且可以配置为使用 Kerberos。 OpenID Connect 和 Kerberos 非常不同，旨在满足不同的用例。

【参考方案1】：

我确实找到了解决方案：

我尝试使用浏览器更改 Fiddler 客户端，但我遇到了一个问题，它告诉我令牌的颁发者不是预期的，我在我的standalone.xml 中发现了身份验证端点用大写字母拼写，它需要一个小写字母。至于“No state cookie”，我猜是浏览器处理这种请求，和 Fiddler 处理的有点不同。