我想使用 OpenID Connect 保护我们的移动应用程序的 REST 后端.简而言之，应用程序的用户应该在通过 REST 后端(多个服务)获取敏感数据之前对自己进行身份验证(用户名/密码)。
在初始身份验证后，他们应该会收到一个 id/访问 token ，然后他们可以在他们的应用程序 session 的剩余部分中使用该 token 进行服务通信。获取此 ID token 非常重要，因为它包含后端所需的信息。
作为实现此方案的身份提供，我想使用 KeyCloak .但是，我不确定要实现的最佳身份验证流程。我读了this和 this stackoverflow 发布，但我仍然不确定我想要的解决方案是否有效/安全/可接受。
根据我对 openID Connect 的阅读，推荐的 openID Connect 身份验证流程是“3-legged 授权代码流程 ”，其中涉及:
这对于基于浏览器的 Web 应用程序来说听起来非常好，但在我们的应用程序中，我们希望避免使用外部登录页面，而是使用“本地”应用程序内登录页面，以免过多地破坏用户体验。此外，我们的应用程序具有让您“登录”的功能。在这种情况下，用户只登录一次，然后应用程序启动时会在后台获取所有 token 。
所以，根据我们的要求，我找到了 this使用两条腿的博客文章 资源所有者凭证流 允许应用程序进行自我身份验证并在一个请求中收集 token 的方法，而无需导航到 keycloak 登录页面。
我对此进行了测试，这个解决方案似乎提供了我们需要的功能。此外，在我们的案例中，应用程序和 KeyCloak(=Self-Issued OpenID Provider)仅在内部使用，属于同一法律实体。
在我们的用例中，是否允许使用 2-legged 方法，如果不允许，为什么不呢？这种方法是否会带来一些三足方法没有的安全风险？
我真的希望收到你们的来信!
2018 年 16 月 10 日更新:哇，伙计们，我从 Nate Barbettini 那里找到了一个非常有趣的教程演示文稿 (https://www.youtube.com/watch?v=996OiexHze0)，其中涵盖了 oauth、openid 连接和身份验证类型，非常清晰而且非常深入。我建议大家在使用 ouath/openid connect 进一步探索复杂的授权/身份验证世界之前查看此演示文稿。
问候，
金
荷兰人
最佳答案
我相信Resource Owner Credentials除非确实需要并且客户端应用程序和环境由您自己完全控制，否则应避免使用流程。您可以完全控制应用程序，但无法控制手机操作系统(安全更新，...)
这个blog post讨论了各种问题。我不完全同意那篇文章中提到的所有观点，但我引用了一些相关的观点:
这里还有一段摘自 O'Reilly 的书 Getting Started with OAuth 2.0 by Ruan Boyd :
When Should the Resource Owner Password Flow Be Used? Because the resource owner’s password is exposed to the application, this flow should be used sparingly. It is recommended only for first-party “official” applications released by the API provider, and not opened up to wider third-party developer communities.
If a user is asked to type their password into “official” applications, they may become accustomed to doing so and become vulnerable to phishing attempts by other apps. In order to mitigate this concern, developers and IT administrators should clearly educate their users how they should determine which apps are “official” and which are not.
关于rest - 移动应用程序 + REST 后端中的 OpenID Connect 身份验证流程(使用 KeyCloak)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44693899/