我正在寻找一个与Keycloak集成在一起的API管理系统（Keycloak应该提供所有身份验证）。 Wicked.io（基于香港）看起来不错。
我曾尝试添加oAuth2作为auth方法，但是邪恶的却不断生成自己的客户端ID和机密。
有什么办法可以解决邪恶的人吗？
答案 0 :(得分：0)
wicked.haufe.io的维护者在这里。
将邪恶/孔与KeyCloak结合起来可能不是一个好主意。 Wicked解决了KeyCloak也要解决的许多问题，而且重叠部分很大，例如对OAuth2工作流程进行身份联盟（SAML，OAuth2）等等。
KeyCloak和邪恶/ Kong遵循不同的原则； KeyCloak发行令牌，这些令牌通过服务内部的KeyCloak库进行验证。它或多或少地取代了API网关-它是在服务内部基于KeyCloak库实现的。
相比之下，wicked / Kong的构建方式有所不同，其中最大的区别是wicked在Kong之上提供的API Portal，并且您有专用的API网关（Kong）。 Wicked为您提供了自己的客户端凭据，它还希望完成整个身份验证和授权工作。换来的是自助API门户；如果不需要的话，可能就不需要邪恶了。
您可以要做的是通过让KeyCloak充当SAML或OAuth2身份提供者，将KeyCloak OAuth2流联合为邪恶的。然后，您可以将您的KeyCloak授权服务器注册为具有邪恶身份的身份提供者（使用单个服务提供者（SAML）或客户端（OAuth2））。这里的“但是”是您仍然需要通过KeyCloak库提供不使用的服务入口。
wicked / Kong总是这样工作：消除了在服务内部实现身份验证/授权的需要；相反，您需要检查标题X-Authenticated-UserId和X-Authenticated-Scope。对于wicked，通常将包含sub=<some id>之类的内容，这还取决于您已配置为使用wicked的身份提供者的类型。但是这种方法通常替换 KeyCloak。好处是，您可以为服务（= Kong）提供一个单一入口点，并且您可以采用一种非常轻巧的方式来保护任意服务-不仅限于KeyCloak支持的语言编写的服务！ -在API网关后面，同时通过API门户提供自助服务访问（带有可配置的计划，文档等）。
所有这些事情显然都有些复杂； wicked的用法极为灵活，但并不是真正要与KeyCloak结合使用（同样如此。这全都归结为真正了解用例并找到可以最佳方式解决用例的解决方案体系结构。
如果您的用例涉及API门户和API文档（应该如此），则很可能出现邪恶//脚。如果不是这样，您可能会更乐于坚持使用KeyCloak（您可以将其视为具有所需分散式网关的无头API管理系统）。
免责声明：我对KeyCloak的了解已经过时；可能有一些更新也进入了API门户方向，但是我不知道。