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

Question

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

在初始身份验证之后,他们应该会收到一个ID /访问令牌,然后他们可以在其应用会话的剩余时间内用于服务通信.获取此ID令牌非常重要,因为它包含后端所需的信息.

作为实现此场景的Identity Provide,我想使用KeyCloak.但是,我不确定要实现的最佳身份验证流程.我读这个和这个计算器的职位,但我仍然不能确定,如果我需要的解决方案是有效的/安全/可以接受的.

从我读到的有关openID Connect的内容来看,推荐的openID Connect auth流程是"3条腿授权代码流程 ",其中包括:

1. 将用户重定向到Identity Provider的登录页面(在我的案例中为KeyCloak)进行身份验证(例如登录表单).
2. 在成功验证之后,IP然后将用户重定向回应用程序以及作为请求参数传递的验证码.
3. 然后,应用程序可以通过将此身份验证代码传递给"标准化"令牌端点来从IP获取id/acccess令牌.

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

因此,根据我们的要求,我发现了这篇博客文章,该文章使用了一个两条腿的 资源所有者凭据流程方法,该方法允许应用程序进行身份验证并在一个请求中收集令牌,而无需导航到keycloak登录页面.

我测试了这个,这个解决方案似乎提供了我们需要的功能.此外,在我们的案例中,app和KeyCloak(=自发布的OpenID提供商)仅在内部使用,属于同一法人实体.

在我们的使用案例中,是否允许使用双腿方法,如果没有,为什么不呢？这种方法是否会带来一些安全风险？

我真的希望听到你们的意见!

更新16-10-2018:哇伙计们,我从Nate Barbettini 找到了一个非常有趣的教程演示文稿(https://www.youtube.com/watch?v=996OiexHze0),其中包括oauth,openid connect和认证流程的类型在非常明确的条件下,但也非常深入.我建议所有人在使用ouath/openid connect进行复杂的授权/身份验证之前进一步冒险.

问候,

金荷兰

Answer 1

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

\n\n

这篇博文讨论了各种问题。我并不完全同意该帖子中提到的所有观点，但我引用了一些相关的观点：

\n\n

\n
• 与 OAuth 最佳实践指南 (RFC8252) 背道而驰
\n
• 公共客户端应用程序无法保守秘密，因此无法验证自己的身份
\n
• 显着增加用户凭据的攻击面（如果客户端受到威胁，用户的整个帐户也会受到威胁）
\n

\n\n

另外，这里摘录自 O\'Reilly所著 Ruan Boyd 的《OAuth 2.0 入门》一书：

\n\n

\n

何时应使用资源所有者密码流？\n 由于资源所有者\xe2\x80\x99s 密码已向应用程序公开，因此应谨慎使用此流程\n。建议仅用于 API 提供商发布的第一方 \n \n \xe2\x80\x9cofficial\xe2\x80\x9d 应用程序，而不向\n 更广泛的第三方开发者社区开放。

\n\n

如果用户被要求在 \xe2\x80\x9cofficial\xe2\x80\x9d\n 应用程序中输入密码，他们可能会习惯这样做，并容易受到其他应用程序的网络钓鱼尝试。为了减轻\n 这种担忧，开发人员和 IT 管理员应明确教育\n 用户如何确定哪些应用程序是 \xe2\x80\x9cofficial\xe2\x80\x9d，\n 哪些应用程序不是。

\n

\n