Web 使用IdentityServer4登录应用程序

我必须开发一个SSO系统，我必须使用IdentityServer4来完成。我已经阅读了文档和示例，但是我有一些疑问。老实说，我不太明白，但我对Oauth2和OpenId Connect真的很陌生

我们将有一组客户端（web应用程序），每个客户端都有自己的web APi。我们必须有一个中央授权的登录应用程序。我认为javascript客户机的例子与我们想要实现的目标非常接近。此外，用户可能有权访问一个客户端（应用程序），但无权访问另一个客户端（应用程序），因此IdentityServer必须提供有关特定用户可以访问的客户端（应用程序）的信息

所以，这些是我不明白的事情：

1.-在我可以阅读的文档中有两个令牌，一个身份令牌和访问令牌。但在这些示例中，我看到的都是访问令牌。在我看来，访问令牌是包含所需所有de信息的令牌。我错了吗

2.-另外，我也读过关于德格兰特类型的书，我不太确定我们必须使用哪一种。起初我想使用ResourceOwner密码，因为它需要客户机、密码、用户和密码，我假设它可能是最终用户。我发现这个例子可以自定义验证用户和密码的类。我认为这可能是一种方法，但文档中说明了这种授权类型“…这就是所谓的“非交互式”身份验证，通常不推荐使用。”。javascript客户端示例使用隐式Grat类型，其中文档说明用于基于浏览器的应用程序（我们的客户端应用程序都将使用react基于浏览器）

3.-我的登录应用程序可以是Javascript（react）应用程序吗？示例Quickstart是在MVC.NET中制作的。此登录应用程序直接连接到de IS4服务器，无需请求访问令牌？（在本例中，应用程序被嵌入IS4中）

4.-我可以用IS4保护在.net framework（4.6.2）中开发而不是在.net Core中开发的WEB API吗？我没有找到任何例子

我跟踪的文件是官方的。还有一些例子（快速入门）。（我最多只能发布两个链接）

---

非常感谢您的阅读和帮助。

身份令牌和访问令牌 Identity token是包含用户身份的令牌，它将告诉客户端应用程序它是什么用户。成功登录后，用户将使用这些令牌重定向到客户端应用程序。响应还将包含声明，例如权限范围、名称、电子邮件。您还可以添加自定义声明

访问令牌用于访问受保护的web api资源。您必须在每个请求中发送访问令牌才能访问api

赠款类型 授权类型基本上是您希望客户端应用程序与身份验证服务器交互的方式

我的登录应用程序可以是Javascript（react）应用程序吗？您的客户端应用程序可以是Javascript应用程序，但您的身份验证服务器（即具有登录/注册页面（以及其他登录jazz）和帐户控制器的身份服务器）应该是您的MVC应用程序。既然已经使用MVC和实体框架完成了所有工作，那么为什么要重新完成所有工作呢

我能用IS4 a WEB API保护吗我不确定这一点，但我不明白你为什么不能这样做

是基本IdSrv流的一个很好的答案

更新据我所知，使用它的答案取决于您的客户申请要求。如果您想使用Javascript客户端，您可以使用隐式流，但您将无法使用刷新令牌，并且您的访问令牌在客户端可以访问时，浏览器没有100%的安全性

---

如果您想向公众开放您的web api，那么您可以使用客户端凭据流。如果您想更安全，应该使用混合流或混合客户端凭据流。（同样取决于要求）。这样，您将能够使用刷新令牌，这样您的访问令牌将更加安全。

非常感谢您的回复。对于第一点，我理解代币的区别。但我的困惑来自于我在示例中没有看到标识标记这一事实。关于补助金类型，我也了解他们的用途，但我不确定该用哪一种。第三，你是说我应该重新使用快速启动项目？？谢谢我建议您使用官方文档中的快速启动项目，启动并测试它。目的是熟悉Id4的流程。这是最好的办法来更好地了解它是如何工作的。我确实使用了quickstart项目，并且理解了基本知识和整个周期。但我无法解决这些问题。好吧，那么为什么你看不到任何关于身份令牌的例子呢？一旦用户通过身份验证，你就不会对身份令牌做任何事情。它将一直保存在cookie中，直到过期或应用程序结束（取决于cookie的生存期和持久性）。您唯一需要的是获取web api的访问令牌。这就是为什么所有示例都显示访问令牌。为什么要查看身份令牌？？其他问题请参见我的更新答案！谢谢你的澄清。我仍然在选择补助金类型方面有问题。在与架构师进行分析后，他喜欢授权代码授权，但IS4的文档说明了这种授权类型：“虽然这种授权类型本身受支持，但通常建议您将其与身份令牌相结合，从而将其转变为所谓的混合流。混合流为您提供了重要的额外功能，如签名协议响应。“因此，我正在尝试混合授权类型，看看它如何与javascript客户端一起工作。非常感谢