没有Cookie的IdentityServer4外部身份验证

Question

我无法理解ASP.NET Core身份验证的工作方式。

我想用刷新令牌实现JWT访问令牌认证。据我所知，这是用于验证客户端（移动应用程序，SPA Web应用程序）的行业标准。为了安全起见，我宁愿不实现自己的授权逻辑，包括JWT生成和刷新令牌处理。由于ASP.Net本身不支持此功能，因此我自然选择使用IdentityServer4，这是一个大型的开源库来处理此类内容。

但是IdentityServer4很大程度上基于OAuth，我不确定它如何与SPA应用程序和移动应用程序（我信任的客户端）一起使用。它要求客户端重定向到任意网页以输入其凭据，然后重定向回应用程序。毛。我从未见过像Snapchat，Instagram等主要应用程序具有这种身份验证流程，在登录流程中会将您定向到某些网页/浏览器。幸运的是，IdentityServer4有一个小功能，可以为我信任的客户端（http://docs.identityserver.io/en/latest/quickstarts/2_resource_owner_passwords.html）处理用户名/密码验证

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

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

现在，当同一iOS用户尝试登录该应用程序时，该应用程序将从SDK中为该用户生成一个Facebook访问令牌，并将其发送到后端。但是，我不确定如何利用IdentityServer4为用户生成JWT，因为我需要用户的用户名和密码。这就是我卡住的地方。我似乎正在与图书馆作斗争，这使我相信我对某些事情有严重的误解。

TLDR； IdentityServer4似乎很大程度上基于cookie，当您从身份验证网页来回重定向时，它实际上不太适合移动应用程序/ SPA网页。我使用的工具是否正确？有哪些替代解决方案？

Answer 1

如果您想要OpenID Connect和OAuth2给您的东西，它绝对是完成工作的正确工具。听起来您可能需要说服力，而且您的用例可能不需要所提供的全部功能。

如果您正在使用多个客户端应用程序和API，那么我认为此时使用OpenID Connect和IdentityServer4是正确的选择。

关于本机应用程序，您曾经用“粗略”一词来描述使用用户的默认浏览器来执行登录过程，这是可以理解的，为什么您起初会以为这样，但对UX的想象却不如您想象的那么糟糕。并具有很多优势：

1. 客户端应用程序与身份验证，身份验证，社交登录（在您的情况下为Facebook），多因素，视网膜扫描等身份验证的方式完全脱钩。身份服务器处理所有这些复杂性，并且只需一点管理（以及失败-使其高度可用！）
2. 可以单次登录-如果他们已经登录到您的IDP，则可以直接进入（尽管您完全控制流程-希望他们每次都同意或确认登录请求-您可以那个）
3. 如果用户在浏览器中设置了密码管理器，那么它也将起作用

iOS和Android都提供了用于完成此工作和正常工作的API。如果您将本机和Web UI设置为外观相似，那么来自用户PoV的流程将完全不会受到破坏。

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

下面还有一些其他读物。业界对此已经进行了很多思考，因此绝对值得消化当前的最佳实践。

https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

IETF当前的最佳做法：https://tools.ietf.org/html/rfc8252

不要让Scott讨厌您;）：https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications

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

Answer 2

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

现在，如果我们确定重定向是必不可少的罪恶，那么用于传递数据的手段并不多。即我们要么需要通过查询字符串传递数据，要么使用Cookie。我想念其他人吗？

两者都有局限性，但是由于cookie是持久性的，并且浏览器会在每次请求时自动携带它们，因此它们似乎是更好的选择，特别是如果外部IdP需要多次重定向以跟踪身份验证请求的状态时，尤其如此。这里提到了相同的原因：

http://docs.identityserver.io/en/latest/topics/signin_external_providers.html