oidc认证webapp REST

Question

因此，我查看了以下客户端库，实现了OpenID连接规范：https://github.com/IdentityModel/oidc-client-js按预期工作，现在我可以允许用户使用Google登录，非常好。这个库特别假设一个“纯”web客户端应用程序，即一个没有后端的应用程序。

现在，我的webapp (和许多其他应用程序一样)希望连接到我拥有的后端REST资源(或代理)。添加额外的身份验证是没有意义的(毕竟用户现在已经登录到谷歌，为什么(S)想再次登录)。因此，简单地说，用户想要在客户机中使用Google进行身份验证(因为there不需要强迫用户为我自己的平台()专门创建另一个登录帐户)，那么用户就想访问我自己管理的REST端点。

我的问题是:允许我自己的服务器REST端点允许oidc授权的访问令牌的通用方法是什么？

我提出了以下考虑：

1 :对每个请求(例如使用passport.js)在服务器上调用，以验证服务器端的访问令牌。

这看起来几乎肯定是过头了，但它是最简单的实现，并使我的服务器保持无状态状态，这正是您希望从REST中得到的。从哲学上讲，让您自己的后端负责身份验证是没有意义的，因为这将使委托用户身份验证给oidc协议的整个使用无效。

虽然这似乎是可以/应该这样做的(海事组织)，但实际上没有人建议采取这种办法。为什么会这样呢？

在客户端从oidc提供程序获得访问令牌后，在 2 /register和/或 /login <#>endpoint中生成您自己的jwt，并为您的个人资源实现您自己的流量。

我个人鄙视这种方法，因为您基本上是在复制身份验证、刷新令牌的系统等等.您想要的只是基于您已经拥有的访问令牌对您的资源进行授权。你最终会得到一个复杂的系统，试图匹配oidc和你自己的帐户系统，我觉得这很糟糕(如果我错了，请纠正我)。

<#>3.将访问令牌存储在服务器端会话/数据库中，以避免在每次请求时在服务器端重复对oidc提供程序的调用。

从整体上看，这个系统似乎已经崩溃了。首先，您将回到服务器端会话，这是您不想要的。我希望人们把它称为“权衡”，但它完全使‘无状态方法’无效，我可以回到服务器身份验证(我认为这是不需要的)。您不仅会在服务器上存储访问令牌(您真的想/需要这样做吗？(？))，还需要服务器和客户端之间来回通信的整个流程，因为存储的访问令牌将过期，客户机需要刷新/重新初始化流，返回等等。这一切对我来说都没有什么意义。

经过长时间的在线研究后，似乎并没有一个既定的推荐方案(可能是今天最常见的)，这让我感到困惑。

有没有一个共同的方法，你可以推荐，解决前面提到的问题，并解释‘为什么’是没有疑问的，没有回避的实际问题，只是清楚？关于数字1为什么不是一个有效的选项，是否有明确的论据？我真的不明白为什么我要花这么多时间在这个简单/常见的场景上，但我喜欢从这里继续前进，而不是跑圈。

Answer 1

有一个明显的部分我错过了(不知道我是怎么做的)，这解决了我所有的问题。也就是说，可以在服务器上检查oidc令牌，而不需要向后端的oidc提供程序发出http请求。这种方式在oidc服务器上维护状态，客户端将执行繁重的工作，以便通过提供程序刷新令牌，并且服务器将以这种方式保持无状态状态。