自己发行 JWT 令牌与使用 IdentityServer4(OIDC) 进行 Web API

Question

https://identityserver4.readthedocs.io/en/release/intro/support.html

我目前在我的 Web api 中使用 JwtSecurityToken 自己发布令牌，并使用标准 ASP.NET Core 中间件调用 AddJwtBearer 来验证令牌。它工作正常。

与上述方法相比，使用 OpenID Connect（通过 IdentityServer4）会给我带来什么优势？如何回答自己的问题“我需要 OpenID Connect 吗？”

根据我对 OpenID Connect 的基本了解，它用于允许第三方访问您的 API。但我为自己而不是为第三方制作 API，我不知道为什么我应该偏爱 IdentityServer/OpenIddict 而不是我的简单方法。

我读到如果我想要单点登录，我应该使用它，但是 JWT 本身并不绑定到任何特定域，我可以只使用纯 JWT 的单点登录（它们是自包含的）

我知道它实现了某种发行令牌的标准。 （协议）。如果我希望向第三方公开一些 API，那可能会很好。但是对于内部 API？值得用吗？

这是我当前的身份验证流程（来自https://jonhilton.net/2017/10/11/secure-your-asp.net-core-2.0-api-part-1---issuing-a-jwt/）

我真正想要实施以保护我的 Web API：

• 登录
• 注销（使令牌无效？）
• 没有同意屏幕（只想为我自己提供 API），身份验证发生在我的本机桌面、移动、Web 应用程序的后台（无重定向）
• 记住我功能（刷新令牌？）

谁能帮我清除一下 OIDC/OAuth2 的模糊画面？即给我一些我自己的方式的缺点（实现我自己的流程）和使用 OIDC 代替我自己的流程的优势。

它将使我以后免于做什么（例如在客户端），什么不会。尤其是，使用 OIDC 等标准流程开始每个项目是否合适？将来它会以某种方式使我受益吗？

Answer 1

无论如何，您都将实施 OAuth2。将 Oidc 视为 OAuth2 的扩展。要记住的最重要的事情是关注点分离。

忘记 Oidc，Identity Server 4 就是关于身份验证的：“谁是用户”？考虑谷歌登录。当用户第一次登录时，应用程序不认识该用户，它只知道 Google 认识。

授权发生在不同的级别上，并不是 IdentityServer 真正关心的问题。为此，您可以查看PolicyServer。

因此，您需要将用户数据库与应用程序数据库分开。这并不意味着您需要另一个数据库，只是不要混合上下文。如果您与“业务环境”有关系，例如“身份上下文”中的用户表，那么您最终会遇到问题。

在您的设置中，您的 web api 既是 资源 又是 身份提供者。这意味着您创建的每个新 Web api 都必须作为资源和身份提供者来实现。为了可维护性，您可以创建一个单独的 web api 作为身份提供者，而 web api 只是一个资源。只要所有应用程序都可以读取令牌，您就可以实现类似的东西。

前面也一样。为什么前面要和用户有关系？它需要做的就是传递令牌以获得用户授权。在 IdentityServer 的情况下，应用程序会联系它以验证用户并接收令牌。它对凭据一无所知。这更安全。客户端应用程序可能会受到损害。凭据可以被截取。

拥有具有特定关注点的单个应用程序使事情更易于维护。在使用 IdentityServer 时，无需编写代码即可轻松添加新资源。只需添加配置。它还允许您在将来添加目前不需要的其他流。另外，同意屏幕是可选的。

好处是您可以实施 SSO，在您的设置中，即使不是不可能，也可能更难。

因此您不必使用 IdentityServer，也不必使用 Oidc。您的设置可能很好。但是，如果您构建某些东西，请记住分离关注点。