繁体   English   中英

使用外部身份提供者 (IDP) 通过 KeyCloak 授予直接访问权限

[英]Direct Access Grant with KeyCloak using external Identity Provider (IDP)

我想使用“直接访问授权”对 KeyCloak 进行身份验证: https://www.keycloak.org/docs/latest/server_admin/index.html#resource-owner-password-credentials-grant-direct-access-grants

当 keycloak 自行管理用户和密码时,我的工作就像一个魅力。

但是,我的情况不同:

我希望 keycloak 充当一些外部 IDP 的代理。 KeyCloak 具有身份代理功能 - 但仅适用于“授权代码流” - 将用户重定向到外部 IDP 登录表单。 我有移动应用程序并且希望不使用“直接访问授权” - 这样应用程序与 keycloak 通信以验证用户 - 而 keycloak 作为代理在外部 IDP 中验证此用户(使用 openid-connect)

如何实现这种情况? 我知道开箱即用是不可能的 - 但也许有人可以建议如何为 keycloak 编写扩展才能使这种情况成为可能?

无论您试图通过这种方式实现什么,它都直接违背了 OAuth 和 OpenID Connect 的设计目的。 使用访问令牌的整个想法是允许某些依赖方(例如移动应用程序)代表用户与服务交互,而无需查看用户的凭据(例如密码)。

可以这样想。 假设您的手机上有一些应用程序。 它可以使用谷歌的某些服务。 为此,它会让您使用 Google 登录并授予该应用程序访问权限。 现在,您想通过将您的 Google email 和密码直接输入应用程序来实现吗? 当然不是。 这可以让它完全控制你的谷歌账户、其他使用你谷歌身份的应用程序和网站,可能还有允许你通过谷歌钱包支付的服务……简单地把你的谷歌登录名交给一些手机应用程序是很疯狂的。

因此,使用 OAuth2 或 OpenID Connect,您可以使用授权代码流或隐式流将用户重定向到身份提供者(在我们的示例中为 Google),他们将在其中完成登录过程,然后身份提供者重定向回应用程序或具有授权代码的站点,可以交换令牌,或者对于隐式流,令牌本身。

现在,当它是您自己的应用程序和您自己的身份提供者(如 Keycloak)在您的控制之下时,这并不重要。 您可以使用直接授权让用户将他们的用户名和密码输入到应用程序中,因为您知道它不会试图窃取用户凭据来恶意使用您的服务。 他们都在你的控制之下。 在那种情况下,OAuth 或 OIDC 有点矫枉过正,但您可以为直接授权(您自己的应用程序)和授权代码流(使用您的服务的第三方应用程序)提供单独的客户端。 但是,当您想使用 Keycloak 身份代理时,外部身份提供商(如 Google 或 Facebook)不会提供直接授权并邀请应用程序窃取其用户的凭据。 所以你将无法以这种方式与他们互动。

根据您要实现的目标,您可能会在令牌交换过程中找到一些用处。 但是,如果您的想法是您希望您的用户在您的应用程序中使用他们的外部身份提供者凭据登录,而无需重定向......不要。

您是否坚持使用 Direct Access Grant 作为移动应用程序中的用户身份验证方法? 在我看来,当 IDP 是第三方服务时,您需要使用授权代码流,因为它不会提供 API 来验证用户身份,即使使用您自己的(第一方)IDP,最好使用授权OAuth 2.0 安全最佳当前实践第 2.4 节中所述的代码流。

要在移动应用程序中实施授权代码流,您需要使用应用程序内浏览器选项卡来显示 IDP 提供的登录屏幕。 有关详细信息,请参阅RFC 8252:OAuth 2.0 for Mobile and Native Apps

这是一个真实的用例,不幸的是 Keycloak 没有直接的方法来解决这个问题。 AWS 的“服务帐户的 IAM 角色”功能基于令牌交换和使用外部 IDP 的直接访问授权。 我发现了这个关于如何解决 Keycloak 缺乏支持的讨论,但不确定它是否解决了所有用例 - https://lists.jboss.org/pipermail/keycloak-user/2017-January/009272.html

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM