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

Posted 2023-03-10

【中文标题】自己发行 JWT 令牌与使用 IdentityServer4(OIDC) 进行 Web API

【英文标题】：Issuing JWT token myself versus using IdentityServer4(OIDC) for Web API

【发布时间】：2018-09-21 17:28:14

【问题描述】：

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 等标准流程开始每个项目是否合适？将来它会以某种方式使我受益吗？

【问题讨论】：

你为什么首先使用令牌？存在 cookie 问题的移动应用程序，多个 api 端点查看令牌以进行权限检查而不是数据库（用于性能），还有什么？

是的，性能，原生应用，可以轻松跨域使用。我认为令牌现在更常用于 Web API。

【参考方案1】：

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

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

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

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

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

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

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

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

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

【讨论】：

如果我使用 ASP.NET Core Identity 来存储用户数据，是否意味着我应该在实体框架中有一个单独的上下文？

您有两种类型的信息：身份和业务。身份提供者有权访问身份模型和业务模型的资源（Web API）。如果你吐出这些，你将需要单独的上下文。如果您需要在报告中显示用户名，则必须在业务上下文中创建一个用户表，您可以在其中存储信息。然后它变成商业信息。这似乎是多余的，但事实并非如此。该信息具有不同的含义/目的。您可以使用 UserId（只是值，而不是数据库关系）将当前用户链接到业务用户。