以正确的方式为本地移动构建OpenID连接流

寻找有关如何为本地移动应用程序实现OpenID Connect的准确指导方针是一段艰难的旅程。大多数可用的资源没有遵循最佳实践，而其他资源则留下了一些重要的问题没有得到回答。

这里的目标不是重新发明轮子，而是呈现一个简单而完整的移动OpenID Connect流的健壮实现。它基于验证码流程，遵循最新的官方指南RCF 8252和IETF OAuth 2.0安全最佳实践，完全兼容OpenID Connect Foundation Android SDK和OpenID Connect Foundation iOS SDK。

考虑到隐式授予流的漏洞，从现在开始应该使用授权码授予流。

考虑到移动设备上的身份验证流，使用本机实现是相当直观的。但是，将身份验证部分保留在浏览器中可帮助您实现重要目标：

安全性：通过浏览器并使用授权服务器的Web身份验证表单，您可以立即受益于它们可能已经实现的安全机制(例如：沙箱、证书验证、…)。。

用户信任：您可能认为本机实现总是更高效。但是，从用户的角度来看，必须在您的应用程序中直接提供他的第三方凭据似乎是一个潜在的安全问题。他怎么知道你不会一路上偷他的证件呢？

可维护性：当身份验证通过浏览器时，身份验证流被委托给授权服务器。那么，如果授权服务器想要实施新的机制(即：双因素身份验证、用户同意、…)，该怎么办呢？？你这边什么都没有。它对您的应用程序将是完全透明的。

任何与移动应用程序捆绑在一起的秘密都不应该被认为是秘密。AppAuth和RCF 8252-SECTION-5.3.3强调了这一点，并声明要确保CLIENT_SECRET应该保存在服务器端。太好了，让我们把它保存在服务器端，但是把这个秘密存储在一个代理中！但是一旦这样做了，您就会意识到，如果您的客户端应用程序和服务器之间没有强身份验证，您的client_secret将是保密的，但是任何人都可以通过您的代理来模拟您的应用程序。因此，任何捕获OAuth身份验证代码的攻击者都可以通过您的代理模拟您的应用程序，并从中获取用户Access_Token。

此身份验证过程应使用已注册的浏览器或“应用内浏览器选项卡”来处理，而不是使用“Web视图”(参见RFC 8252)。

您应该使用Android应用程序链接和iOS通用链接，因此只有您的应用程序才能通过redirect_uri获取授权回调。

您可能想要限制允许哪个浏览器执行此过程，AppAuth提供了一种机制来控制使用哪个浏览器进行授权。

如果您的身份验证服务器不支持PKCE，则不支持CODE_CHANGLISH和CODE_CHANGLE_METHOD参数。在这种情况下，至少使用STATE参数来防止csrf攻击(请参阅https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.7.1).。

我们现在将检查一下我们的应用程序服务器。为此，我们在服务器上定义了POST/open_id_connect端点。此端点将与Access_Token和来自授权服务器的声明交换给定的代码(和code_verizer)。

对授权服务器在用户身份验证成功时返回给redirect_uri的代码进行编码。

CODE_VERIFIER PKCE CODE_VERIFIER，与身份验证过程中发送到授权服务器的CODE_CHANGLISH匹配。

在我们的实现中，我们还添加了一个Account属性，该属性将提供有关平台上现有用户帐户(如果有)的信息。

现在您就知道了来自授权服务器的最终用户身份(access_Token和Claims)，以及该用户是否已经在您的服务器(帐户)上注册。因此，您可以决定最终用户是否需要注册或登录，并使用收集的信息来支持这些流程。

如果您遵循正确的指导方针，在移动设备上构建简单&；Secure OpenID Connect身份验证流程非常简单；-)很高兴回答您的任何建议！