Authentication IdentityServer4无Cookie的外部身份验证

我很难理解ASP.NET核心身份验证是如何工作的

我想用刷新令牌实现JWT访问令牌身份验证。据我所知，这是验证客户端移动应用程序SPA Web应用程序的行业标准。出于安全目的，我不希望实现自己的授权逻辑，包括JWT生成和刷新令牌处理。由于ASP.Net本机不支持这一点，因此我自然会选择使用IdentityServer4，这是一个用于处理此类内容的大型开源库

然而，IdentityServer4在很大程度上是基于OAuth的，我不确定它如何与我信任的SPA应用程序和移动应用程序客户端协同工作。它要求客户端重定向到某个任意网页以输入其凭据，然后重定向回应用程序。总的我从未见过像Snapchat、Instagram等大型应用程序有这种身份验证流程，在登录流程中，您可以直接访问某些网页/浏览器。幸运的是，IdentityServer4有一个小功能来处理我的可信客户端的用户名/密码身份验证

太好了，这似乎适合我的需要。但是现在我想添加Facebook身份验证。IdentityServer4允许，但据我所知，它仍然是基于cookie的。这要求Android/iOS/SPA应用程序重定向到网页，然后重定向回该应用程序。同样，从用户的角度来看，这并不理想。Facebook提供本机移动SDK来处理这种类型的身份验证，这种身份验证返回一个访问令牌，因此不需要使用cookie重定向到网页

现在让我们假设我的iOS应用程序使用Facebook SDK为用户获取访问令牌并将其发送到后端。后端根据Facebook SDK验证令牌，然后在其自己的数据库中注册本地用户

现在，当同一个iOS用户尝试登录该应用程序时，该应用程序将从SDK为该用户生成一个facebook访问令牌，并将其发送到后端。但是，我不知道如何利用IdentityServer4为用户生成JWT，因为我需要用户的用户名和密码。这就是我被困的地方。我似乎在和图书馆斗争，这让我觉得我严重误解了什么

---

TLDR；IdentityServer4似乎严重依赖于cookies，当您从身份验证网页来回重定向时，cookies并不真正适合移动应用程序/SPA网页。我用错工具了吗？有哪些替代解决方案？

如果您需要OpenID Connect和OAuth2提供的功能，那么它绝对是适合这项工作的工具。听起来你可能需要说服力，也许你的用例并不需要提供的全部功能

如果您有多个客户机应用程序和API，那么我认为此时使用OpenID Connect和IdentityServer 4是正确的选择

关于本机应用程序，您曾经用word gross来描述使用用户的默认浏览器执行登录过程，这是可以理解的，为什么您一开始可能会这么想，但这并不像您想象的那么糟糕，并且有很多优点：

客户端应用程序与身份验证的实际执行方式完全分离，如联合、Facebook中的社交登录、多因素、视网膜扫描等。您的身份服务器处理所有这些复杂性，并且是一个单一的管理点和故障点，因此使其高度可用！ 单点登录是可能的-如果他们已经登录到您的IDP，那么他们可以直接进入，尽管您完全控制流量-希望他们每次都同意或确认登录请求-您可以这样做 如果用户在他们的浏览器中设置了密码管理器，那么也可以 iOS和安卓都提供了API来完成这些工作，并且工作得很好。如果您将本地UI和web UI的外观设计为相似，那么来自用户PoV的流一点也不刺耳

您仍然可以使用最终由平台保护的刷新令牌，因此您实际上不必经常进行交互流

下面是一些额外的阅读。业界对此进行了大量思考，因此绝对值得消化当前的最佳实践

IETF当前最佳实践：

不要让斯科特恨你；：

---

对于客户端SPA浏览器应用程序，OIDC提供隐式授权类型，并使用静默刷新和IDP会话监视机制来维护会话。查看实现这种方法的oidc客户端js库。

作为大型社交应用程序的说明：我认为这取决于谁保存密码。Facebook、Instagram、Snapchat和谷歌充当第三方的身份提供商。它们本身要求用户注册并指定它们保留的密码。因此，他们可以使用任何定制的方法来处理这些密码的验证 s但是，如果其中任何一家提供了使用另一家登录的权限，即Instagram允许使用Amazon凭据登录，那么他们将需要遵循OAuth这样的标准方式，并重定向到第三方进行登录。上一次我查看Instagram时，Facebook和Snapchat只提供注册，没有选择与第三方登录，这解释了为什么不需要重定向

现在，如果我们确定重定向是一种必要的罪恶，那么进行数据访问的方法就没有那么多了。也就是说，我们要么需要通过查询字符串传递数据，要么使用cookie。我还错过了其他人吗

两者都有局限性，但由于cookie是持久性的，并且浏览器会在每个请求中自动携带cookie，因此它们看起来确实是一个更好的作业选择，特别是当外部IdP需要多个重定向来跟踪身份验证请求的状态时。这里也提到了同样的原因：

---

你提到了，但它并不像你想象的那么糟糕，而且有很多优势。就个人而言，我并不介意浏览器流量，但当我看到instagram、snapchat、facebook等大型应用程序时，没有一个会首先重定向到浏览器。你说这是最佳实践，但没有一个主要的应用程序重定向到浏览器，所以这就是我不理解的。这些家伙是怎么做到的？我真的不能为大型社交应用说话，因为我是从一个商业应用程序的角度来看的，以及随之而来的所有需求。至于他们是如何做到这一点的——他们很可能使用平台功能来实现自我介绍——可能在引擎盖下使用类似于刷新令牌的东西。