在移动应用和REST后端中使用KeyCloak的OpenID Connect身份验证流程

Question

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

进行初始身份验证后，他们应该收到一个 ID/access token，然后可以在其应用程序会话的其余时间内用于服务通信。获取此 ID token 非常重要，因为其中包含后端所需的信息。

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

根据我阅读关于 OpenID Connect 的资料，建议使用“3-legged 授权码流程”进行 OpenID Connect 认证流程，包括：

1. 将用户重定向到身份提供程序（在我的情况下是 KeyCloak）的登录页面进行身份验证（例如登录表单）。
2. 验证成功后，IP 将带有作为请求参数传递的 auth code 的用户重定向回应用程序。
3. 然后，应用程序可以通过将此身份验证代码传递给“标准化”令牌终结点来从 IP 获取 ID/access token。

所有这些对于基于浏览器的 Web 应用程序听起来都很好，但在我们的应用程序中，我们想避免外部登录页面，而是拥有一个“本地”的应用内登录页面，以不太影响用户体验。同时，我们的应用程序具有一个保持“已登录状态”的功能。在这种情况下，用户只需登录一次，所有令牌都会在应用程序启动时由应用程序在后台获取。

根据我们的需求，我找到了这篇博客文章（链接）。它使用了基于2-legged资源所有者凭证流程的方法，可以让应用程序在不需要导航到KeyCloak登录页面的情况下完成自身认证并收集令牌。

我测试过了，这个解决方案似乎正好提供了我们需要的功能。而且，在我们的情况下，应用程序和KeyCloak（自行发布的OpenID提供者）仅在同一法律实体内部使用。

在我们的使用情况下，是否允许使用2-legged方法？如果不允许，为什么？这种方法是否会带来某些安全风险，而3-legged方法则没有呢？

希望能得到你们的回复！

更新于16-10-2018：哇，伙计们，我发现了一个非常有趣的教程演示文稿 (链接)，由Nate Barbettini制作，非常清晰地介绍了oauth、openid connect和各种身份验证流程，推荐大家在深入学习授权/身份验证的复杂领域之前先查看这个演示文稿。

祝好， Kim 来自荷兰

- Kim Zeevaarders

---

你成功了吗？ - vic-3

你能提供示例项目的新链接吗？ https://github.com/stianst/keycloak-blog-gs 找不到了。 - valijon

@kim 我也遇到了同样的情况，需要在移动应用程序中使用Keycloak实现此流程。如果您成功实现了，请告诉我一声好吗？先谢谢了...... - NullPointer

@NullPointer：是的，我按照我帖子中提到的博客做法成功了。然而，我只是通过这种方式保护了我的REST服务，并在CURL上进行了测试。要从您的移动应用程序中获取令牌，您需要为您的平台查找一个Keycloak客户端库（例如，对于cordova：https://github.com/keycloak/keycloak/tree/master/examples/cordova）。 - Kim Zeevaarders

@kim 用于设备管理，Keycloak 在哪里存储设备 ID 和设备型号？它是否支持 Keycloak？ - Panup Pong

@Wecherowski 呃...，你指的是哪篇很棒的博客文章？ - musicformellons

Answer 1

我认为，除非确实需要且客户端应用程序和环境完全受您控制，否则应避免使用“资源所有者凭据”流。您可能对应用程序拥有完全控制权，但无法控制手机操作系统（安全更新等）。

这篇博客文章介绍了各种问题。我不完全同意该文章中提到的所有观点，但引用了一些相关观点：

• 与OAuth最佳实践指南（RFC8252）相悖
• 公共客户端应用程序无法保密，因此无法进行身份验证
• 显著增加了用户凭据的攻击面（如果客户端受到攻击，则用户的整个帐户也会受到攻击）

此外，这是来自O'Reilly书籍Getting Started with OAuth 2.0 by Ruan Boyd的摘录：

什么时候应该使用资源所有者密码流程？ 由于资源所有者的密码会暴露给应用程序，因此应该谨慎使用此流程。建议仅供API提供者发布的第一方“官方”应用程序使用，而不向更广泛的第三方开发人员社区开放。 如果要求用户在“官方”应用程序中键入其密码，则他们可能习惯这样做，并容易成为其他应用程序进行网络钓鱼攻击的目标。为了缓解这种担忧，开发人员和IT管理员应清楚地教育用户如何确定哪些应用程序是“官方”的，哪些不是。

- kaptan

Answer 2

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

在我看来，最重要的是

填写客户端表单中的所有必填字段。特别注意直接授权流（如图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'

- Dariel Pratama