我有一个使用IdentityServer4和ASP.NET Identity构建的OpenID Connect提供程序，它在login.example.com上运行。
我有一个运行在spa.example.com上的SPA应用程序，该应用程序已经使用我的OpenID Connect提供程序通过login.example.com对用户进行身份验证并授权他们访问SPA。
我有一个移动应用（在两个平台上均为本机），目前正在使用自定义身份验证系统。
我认为摆脱自定义身份验证系统会很好，而是允许我的用户通过使用我的OpenID提供程序使用在SPA上使用的相同帐户登录。
因此，我首先查看了OpenID Connect网站，还重新阅读了RFC6749，在进行了几次Google搜索之后，我意识到这是一个常见问题，并且发现了RFC8252（针对本地客户端的OAuth2 ），客户端动态注册（RFC7591）和PKCE（RFC7636）。
我为无法再在客户端/第三方（本机应用程序）上存储任何类型的“秘密”这一事实而scratch之以鼻。
我与一些同事讨论了这个话题，我们提出了以下设置：
app.example.com与我的移动应用程序关联起来。redirect_uri 我在两个应用程序上都使用了AppAuth库，并且现在在 test 上一切正常，但是我想知道：
答案 0 :(得分：2)
我认为摆脱自定义身份验证系统会很好，而是允许我的用户通过使用我的OpenID提供程序使用在SPA上使用的相同帐户登录。
这是OAuth 2.0和OpenID Connect为您提供的。在不同服务之间使用单个用户身份的能力。所以这是正确的方法。
由于可能会遭到破坏，因此不再可能在客户端/第三方（本机应用）上存储任何类型的“秘密”
正确。从OAuth 2.0规范的角度来看，它们称为 public clients 。建议不要将它们与客户机密关联。而是使用授权代码，应用程序ID和重定向URL来验证身份提供者中的令牌请求。这使授权代码成为宝贵的秘密。
通过使用Apple Universal Links和Android App Links将域名（例如app.example.com）与我的移动应用程序关联。
不是移动专家。但是可以，自定义URL域是处理OAuth和OpenID Connect重定向的方式。
使用PKCE也是正确的方法。因此，重定向在浏览器（用户代理）中发生，可能会有恶意方可以获取授权代码。 PKCE通过引入不会暴露给用户代理（浏览器）的机密来避免这种情况。秘密仅用于令牌请求（直接HTTP通信），因此是安全的。
第一季度
通过PKCE使用授权代码流是OAuth规范建议的标准最佳实践。这对OpenID Connect也有效（因此它是基于OAuth 2.0构建的）
需要注意的一件事是，如果您认为PKCE秘密可以被利用，那么从字面上看这意味着设备受到了威胁。考虑从操作系统内存中提取秘密。这意味着系统受到了破坏（病毒/键盘记录程序或我们所谓的系统）。在这种情况下，最终用户和您的应用程序还有更多需要担心的事情。
此外，我相信这是针对业务应用程序的。如果是这种情况，您的客户肯定会为他们的设备提供安全性最佳实践指南。例如病毒防护的安装和应用程序安装的限制。为了防止上述攻击，我们将不得不依靠这种安全机构。仅OAuth 2.0是不安全的。这就是为什么有最佳实践指南（RFC68129）和政策的原因。
第二季度
对此尚不清楚。同意页面显示在身份提供商处。因此，它将是该系统的配置。
第三季度
那么，身份提供者可以在浏览器中维护SSO会话。该浏览器上显示登录页面。因此，在大多数情况下，如果应用使用相同的浏览器，则用户无需登录即可使用SPA。
答案 1 :(得分：1)
这里的威胁来自某人实际上在其设备上安装了可能冒充您的应用程序的恶意应用程序。 PKCE可以防止其他应用截获从您的应用发起的合法登录请求，因此标准方法将使您尽可能地安全。强迫用户每次登录/同意应该有所帮助，以使他们注意到正在发生的事情。
从UX PoV来看，我认为减少使用基于浏览器的登录流程的机会很有意义。我会利用该平台的安全功能（例如iOS上的安全飞地），并在用户进行交互式登录后将刷新令牌保留在其中，然后他们可以使用PIN，指纹或面部等进行登录。