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

Question

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

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

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

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

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

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

有人可以帮我清除 OIDC/OAuth2 的模糊图片吗？即给我一些我自己的方式的缺点（实现我自己的流程）和使用 OIDC 代替我自己的流程的优势。

它可以避免我以后做什么（例如在客户端），什么不会。最特别的是，使用 OIDC 等标准流程开始每个项目是否好？将来会以某种方式使我受益吗？

Answer 1

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

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

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

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

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

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

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

好处是您可以实施 SSO，在您的设置中，这可能会更难，如果不是不可能的话。

所以您不必使用 IdentityServer，也不必使用 Oidc。您的设置可能没问题。但是，如果您要构建某些东西，请记住将关注点分开。