移动应用程序 + REST 后端中的 OpenID Connect 身份验证流程（使用 KeyCloak）

Posted 2023-03-08

【中文标题】移动应用程序 + REST 后端中的 OpenID Connect 身份验证流程（使用 KeyCloak）

【英文标题】：OpenID Connect Authentication Flow (using KeyCloak) in a Mobile App + REST Backend

【发布时间】：2017-11-25 09:48:13

【问题描述】：

我想使用OpenID Connect 保护我们移动应用的 REST 后端。简而言之，应用程序的用户应该在通过 REST 后端（多个服务）获取敏感数据之前对自己进行身份验证（用户名/密码）。

在初始身份验证后，他们应该会收到一个 id/访问令牌，然后他们可以使用该令牌在其应用会话的其余部分进行服务通信。获取此 ID 令牌非常重要，因为它包含后端所需的信息。

作为实现此场景的身份提供，我想使用KeyCloak。但是，我不确定要实施的最佳身份验证流程。我阅读了 this 和 this *** 帖子，但我仍然不确定我想要的解决方案是否有效/安全/可接受。

根据我对 openID Connect 的阅读，推荐的 openID Connect 身份验证流程是“3-legged authorization code flow”，其中涉及：

将用户重定向到身份提供者的登录页面（在我的情况下为 KeyCloak）以进行身份​​验证（例如登录表单）。 身份验证成功后，IP 将用户重定向回应用程序以及作为请求参数传递的身份验证代码。 然后应用程序可以通过将此身份验证代码传递给“标准化”令牌端点来从 IP 获取 id/访问令牌。

这对于基于浏览器的 Web 应用程序来说听起来非常好，但在我们的应用程序中，我们希望避免使用外部登录页面，而是使用“本地”应用程序内登录页面，以免过多破坏用户体验.此外，我们的应用程序具有让您“登录”的功能。在这种情况下，用户只登录一次，然后应用启动时会在后台获取所有令牌。

因此，根据我们的要求，我找到了 this 博客文章，该文章使用 2 条腿 资源所有者凭据流 方法，该方法允许应用程序对自身进行身份验证并在一个请求中收集令牌，无需导航到 keycloak 登录页面。

我对此进行了测试，该解决方案似乎提供了我们需要的功能。此外，在我们的案例中，应用程序和 KeyCloak（=自发行 OpenID 提供程序）仅在内部使用，属于同一法律实体。

在我们的用例中，是否允许使用 2-legged 方法，如果不允许，为什么不呢？这种方法是否会带来一些三足方法不会带来的安全风险？

我真的希望收到你们的来信！

2018 年 10 月 16 日更新： 哇，伙计们，我发现了 Nate Barbettini 的一个非常有趣的教程演示文稿 (https://www.youtube.com/watch?v=996OiexHze0)，其中涵盖了 oauth、openid 连接和身份验证类型非常术语清晰但也很深入。我建议大家在使用 ouath/openid connect 进一步探索复杂的授权/身份验证世界之前查看此演示文稿。

问候，

金 荷兰

【问题讨论】：

你让它工作了吗？

能否提供示例项目的新链接？ github.com/stianst/keycloak-blog-gs 未找到

@kim 我有同样的情况，我必须使用 keycloak 在移动应用程序中实现这个流程。请让我知道你是否让这个工作？在此先感谢.......

对于任何试图找到解决此问题的方法的人，这里有一篇很棒的博客文章，它合理地描述了您应该为移动应用程序使用的 OAuth 流程（以及为什么不使用资源所有者凭据）和整体身份验证流动的移动。这一切也适用于 OIDC。

@Wecherowski 呃...，你的意思是什么很棒的博文？

【参考方案1】：

我认为应该避免 Resource Owner Credentials 流，除非确实需要并且客户端应用程序和环境由您自己完全控制。您可以完全控制应用程序，但无法控制手机操作系统（安全更新等）

这个blog post 解决了各种问题。我不完全同意那篇文章中提到的所有观点，但我引用了一些相关的观点：

无视 OAuth 最佳实践指南 (RFC8252) 公共客户端应用程序无法保密，因此无法对自己进行身份验证 显着增加用户凭据的攻击面（如果客户端受到攻击，用户的整个帐户也会受到攻击）

这里还摘录了 O'Reilly 的书 Getting Started with OAuth 2.0 by Ruan Boyd：

何时应使用资源所有者密码流程？ 因为资源所有者的密码暴露给应用程序，所以这个流程 应谨慎使用。仅推荐给第一方 API 提供商发布的“官方”应用程序，未打开 到更广泛的第三方开发者社区。​​p>

如果要求用户将密码输入“官方” 应用程序，他们可能会习惯这样做并成为 容易受到其他应用程序的网络钓鱼尝试。为了减轻 这种担忧，开发人员和 IT 管理员应该清楚地教育 他们的用户应该如何确定哪些应用是“官方”的，以及 不是。

【参考方案2】：

以下链接为我节省了很多时间。 https://developers.redhat.com/blog/2020/01/29/api-login-and-jwt-token-generation-using-keycloak#set_up_a_client

我认为最重要的是

填写客户表格中的所有必填字段。注意， 尤其是 Direct Grant Flow（如图 6 所示）并设置其值 直接授予。另外，将访问类型更改为机密。

还有我们必须发送凭证以进行验证的 URL。

curl -L -X POST 'http://localhost:8080/auth/realms/whatever-realm/protocol/openid-connect/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=clientid-03' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'client_secret=ec78c6bb-8339-4bed-9b1b-e973d27107dc' \
--data-urlencode 'scope=openid' \
--data-urlencode 'username=emuhamma' \
--data-urlencode 'password=1'