LDAP JWT OAuth 方案解释
LDAP JWT OAuth scheme explanation
我正在尝试系统化我关于 oauth + jwt + LDAP 授权的知识。我已经阅读了多篇优秀文章（即 this），但对此仍有疑问：
我的理解：
- JWT 是允许单点登录 (SSO) 的令牌。它比简单的令牌身份验证更安全，因为它加密了所有用户特定信息（例如用户名、密码、clientAppId、IP 地址等）。此信息使用内部授权服务器密钥签名，攻击者无法更改。
- 来自 here，请查看下面的短语。据我了解，这意味着每个 HTTP 前端服务器都不需要查找会话数据。但它需要查找授权服务器。 有什么好处？那不是一样的单点故障吗？为什么 JWT 被认为是无状态的？ JWT 还需要把用户数据保存在授权服务器上吧？
The server side storage issues are gone.
- 如果您需要在有效期结束前使用 JWT 注销用户 - 您需要保留黑名单。 那么与没有 SSO 的简单令牌 uath 相比有什么好处呢？
- JWT是OpenID的实现吗（只认证）？
- 在没有 OAuth 的情况下，无法使用 JWT（令牌）自动登录 server-2-server。当您不想在没有用户参与的情况下代表用户授权来自某些服务的请求时，将使用 Oauth。 为什么不能使用令牌而使用 OAuth 可以？
- OAuth还用于配置灵活的访问策略，如角色、组等。但是为什么不能基于tokens/JWT自己实现呢？
- LDAP 服务器对于小型非互连数据片段（如用户凭据）的读取操作速度极快。 jwt-oauth 方案（或 OppenID Connect）中的 LDAP 在哪里？ LDAP是用于认证（JWT）还是授权（OAuth）？
我会在这里澄清一些概念：
Oauth 和 OpenID Connect (OIDC) 本身只是身份验证机制。 JWT 只是一种在双方之间传递经过身份验证的信息的方式。因此，您必须努力分离关注点。当对如何识别用户有疑问时，并确保它确实是 him/her，请检查凭据等等……去检查 OIDC 或 Oauth 标准。如果对如何在各方之间安全地传递用户相关信息有疑问，请查看 JWT RFC 和相关（JWS、JWK、JWE 和相关）。
话虽如此：
完全正确。你没看错。
这取决于实现，但存在一些有状态的方法，也有一些实现是无状态的。 JWT-consuming 服务器（Oauth 术语中的资源服务器）可能具有 IdMS（Oauth 术语中的授权服务器 (badly-named)） 缓存中的签名密钥，或 pre-provisioned 。这样，它可以验证来自 IdMS 的 JWT 访问令牌，而无需执行任何请求。 IdMS 可以在不影响系统的情况下关闭。对于某些在某些 VPN 后面具有 IdMS 而在其外部具有资源服务器的体系结构，情况恰恰如此。除此之外，可能还有一种更有状态的方法来根据 IdMS 的 内省端点 检查访问令牌。通过这种方式，对于资源服务器上所需的每个验证，将向 IdMS 发出请求以检查访问令牌是否仍然有效并提取相关声明。当访问令牌不是 JWT 因此不透明时，也会使用后一种机制。
黑名单可能是一种方法，但通常是通过刷新令牌机制来完成。您给访问令牌一个非常短的生命周期，例如 1 分钟，然后依靠刷新机制在会话被撤销的情况下失败。
从技术上讲，OpenID 和 OpenID Connect (OIDC) 是不同的野兽。简而言之，我们可以说 OpenID 是身份联合的旧实现，没有得到广泛采用。 OpenID Connect 是 Oauth 2.0 的 演变 ，它添加了 JWT、ID Token 和其他一些细节。但不，JWT 和 OIDC 绝不是排他性的实现。确实OIDC强行暗示了JWT的使用，但是JWT存在于OIDC之外
如果你想授权两个服务器之间的请求，在基本级别上，可以使用简单的令牌来完成（只需将它们保密，并使用 TLS）。但是有了 JWT，启用的是服务器可以信任中央 IdMS，而不必完全相互信任。在这种情况下使用 Oauth 你表示因为 Google 例如，信任他自己和用户，而不是你的服务器。因此，身份验证发生在 Google 之间，作为 IdMS 和用户，这会生成一个 JWT（不总是，所以你看到我之前的陈述的情况）你的服务器（信任外部 IdMS）可以使用与 Google.
交流
如前所述，groups/role管理独立于JWT/tokens使用。 JWT/plain令牌只是传递认证信息的方式。
Oauth/OIDC 上的 LDAP 处于身份验证阶段。当用户将其凭据发送到 IdMS 而不是检查本地数据库时，将根据 LDAP 检查凭据。一些高级 IdMS 也可以使用 LDAP 来检索策略、组或其他权限。但是当授权完成后，剩下的过程和以前一样。
参考文献：
我正在尝试系统化我关于 oauth + jwt + LDAP 授权的知识。我已经阅读了多篇优秀文章（即 this），但对此仍有疑问：
我的理解：
- JWT 是允许单点登录 (SSO) 的令牌。它比简单的令牌身份验证更安全，因为它加密了所有用户特定信息（例如用户名、密码、clientAppId、IP 地址等）。此信息使用内部授权服务器密钥签名，攻击者无法更改。
- 来自 here，请查看下面的短语。据我了解，这意味着每个 HTTP 前端服务器都不需要查找会话数据。但它需要查找授权服务器。 有什么好处？那不是一样的单点故障吗？为什么 JWT 被认为是无状态的？ JWT 还需要把用户数据保存在授权服务器上吧？
The server side storage issues are gone.
- 如果您需要在有效期结束前使用 JWT 注销用户 - 您需要保留黑名单。 那么与没有 SSO 的简单令牌 uath 相比有什么好处呢？
- JWT是OpenID的实现吗（只认证）？
- 在没有 OAuth 的情况下，无法使用 JWT（令牌）自动登录 server-2-server。当您不想在没有用户参与的情况下代表用户授权来自某些服务的请求时，将使用 Oauth。 为什么不能使用令牌而使用 OAuth 可以？
- OAuth还用于配置灵活的访问策略，如角色、组等。但是为什么不能基于tokens/JWT自己实现呢？
- LDAP 服务器对于小型非互连数据片段（如用户凭据）的读取操作速度极快。 jwt-oauth 方案（或 OppenID Connect）中的 LDAP 在哪里？ LDAP是用于认证（JWT）还是授权（OAuth）？
我会在这里澄清一些概念：
Oauth 和 OpenID Connect (OIDC) 本身只是身份验证机制。 JWT 只是一种在双方之间传递经过身份验证的信息的方式。因此，您必须努力分离关注点。当对如何识别用户有疑问时，并确保它确实是 him/her，请检查凭据等等……去检查 OIDC 或 Oauth 标准。如果对如何在各方之间安全地传递用户相关信息有疑问，请查看 JWT RFC 和相关（JWS、JWK、JWE 和相关）。
话虽如此：
完全正确。你没看错。
这取决于实现，但存在一些有状态的方法，也有一些实现是无状态的。 JWT-consuming 服务器（Oauth 术语中的资源服务器）可能具有 IdMS（Oauth 术语中的授权服务器 (badly-named)） 缓存中的签名密钥，或 pre-provisioned 。这样，它可以验证来自 IdMS 的 JWT 访问令牌，而无需执行任何请求。 IdMS 可以在不影响系统的情况下关闭。对于某些在某些 VPN 后面具有 IdMS 而在其外部具有资源服务器的体系结构，情况恰恰如此。除此之外，可能还有一种更有状态的方法来根据 IdMS 的 内省端点 检查访问令牌。通过这种方式，对于资源服务器上所需的每个验证，将向 IdMS 发出请求以检查访问令牌是否仍然有效并提取相关声明。当访问令牌不是 JWT 因此不透明时，也会使用后一种机制。
黑名单可能是一种方法，但通常是通过刷新令牌机制来完成。您给访问令牌一个非常短的生命周期，例如 1 分钟，然后依靠刷新机制在会话被撤销的情况下失败。
从技术上讲，OpenID 和 OpenID Connect (OIDC) 是不同的野兽。简而言之，我们可以说 OpenID 是身份联合的旧实现，没有得到广泛采用。 OpenID Connect 是 Oauth 2.0 的 演变 ，它添加了 JWT、ID Token 和其他一些细节。但不，JWT 和 OIDC 绝不是排他性的实现。确实OIDC强行暗示了JWT的使用，但是JWT存在于OIDC之外
如果你想授权两个服务器之间的请求，在基本级别上，可以使用简单的令牌来完成（只需将它们保密，并使用 TLS）。但是有了 JWT，启用的是服务器可以信任中央 IdMS，而不必完全相互信任。在这种情况下使用 Oauth 你表示因为 Google 例如，信任他自己和用户，而不是你的服务器。因此，身份验证发生在 Google 之间，作为 IdMS 和用户，这会生成一个 JWT（不总是，所以你看到我之前的陈述的情况）你的服务器（信任外部 IdMS）可以使用与 Google.
交流如前所述，groups/role管理独立于JWT/tokens使用。 JWT/plain令牌只是传递认证信息的方式。
Oauth/OIDC 上的 LDAP 处于身份验证阶段。当用户将其凭据发送到 IdMS 而不是检查本地数据库时，将根据 LDAP 检查凭据。一些高级 IdMS 也可以使用 LDAP 来检索策略、组或其他权限。但是当授权完成后，剩下的过程和以前一样。
参考文献：