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

【问题标题】：OpenID Connect Authentication Flow (using KeyCloak) in a Mobile App + REST Backend移动应用程序 + REST 后端中的 OpenID Connect 身份验证流程（使用 KeyCloak）
【发布时间】：2017-11-25 09:48:13
【问题描述】：

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

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

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

根据我对 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 呃...，你的意思是什么很棒的博文？

标签： rest authentication mobile oauth openid-connect

【解决方案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'

【讨论】：