微服务身份验证最佳实践和安全性（OAuth 2.0和OpenIdConnect）
在微服务中构建身份验证有几种方法。然而，使用JWT令牌和OAuth协议以及OpenID连接标识层是非常流行的。
在本教程解释如何实现这一目标时,有一个提示：
另一方面，我看到Ping标识也使用按引用传递的方法。你能帮我理解背后的道理吗？
共有1个答案
它们都是有效的选项，并且一如既往，您希望应用它们的确切场景将决定最合适的选项。通常情况下，每个选项都有其利弊，你已经提到了一些，所以我将尽力在讨论中添加一些新的内容。
主要的区别在于内容，by-value将包含实际值，而引用只是一个随机的位序列。如果希望在令牌中表示敏感信息，这可能会使标尺倾斜到有利于引用令牌的位置。
诚然，如果您使用JWT，您可以对它们进行加密以确保机密性，但这会增加一个相当大的复杂性，而且鉴于加密没有类似的广泛用途，可用库中对JWT加密的支持很可能不如对签名的支持好。
关于大小，我不认为这应该是一个决定因素。是的，如果使用按值令牌，则需要将它们保持得足够小，以免在通道上造成显著的开销，但您不应该仅仅因为这种限制而选择其中一个。
您没有提到的一件事，但我认为很重要的是，引用令牌似乎更适合授权服务器和资源服务器属于同一实体的情况。确实，已经有一个标准来覆盖令牌内省，以便外部资源服务器可以以可互操作的方式查询有关引用令牌的信息。然而，当两个参与者都在相同的html" target="_blank">安全边界内时，引用令牌应该更易于扩展和实现，这一点仍然是正确的。
这篇文章中的建议也很有趣，您可以减少外部网络的开销，并且没有信息泄露的问题，然后在一个中心位置升级到按值令牌，这意味着它背后的所有其他服务仍然可以从令牌本身中已经包含所需信息的简单性中获益。
总而言之,如果信息泄露对您来说是一个问题,您可能会使用参考令牌,以避免JWT加密的代价；否则，你还不如让生活对你来说简单一些，用价值代币去吧。
-
假设我有一个Web应用程序，我在其中实现了刷新令牌 < li >用户使用发送到< code>/login REST APIendpoint的正文中的用户名和密码登录。 endpoint创建一个到期时间为1个月的刷新令牌，并将散列后的刷新令牌存储在对应于用户ID的Db中。 endpoint创建到期时间为15分钟的JWT访问令牌，该令牌使用服务器密钥签名并对用户ID进行编码。 endpoint使用刷新
-
我正在开发REST webService，我的一些客户机将使用我的webservices，所以为了识别真正的客户机，我决定给每个真正的客户机一个唯一的应用程序令牌。客户机将对这个令牌进行编码，他们将把这个令牌放在请求头中，我已经在我的REST webservices中配置了一个REST过滤器来验证令牌。我不想使用https。我的问题是，任何人都可以从我的客户端站点获取该令牌，并可以使用我的REST
-
这可能涉及到会话cookie、服务器端会话存储以及一些会话APIendpoint，通过身份验证的web UI可以访问这些endpoint来获取当前用户信息，以帮助个性化或甚至确定客户端的角色/能力。服务器仍将强制执行保护对数据访问的规则当然，UI将仅仅使用这些信息来定制体验。 将其视为使用公共API的任何第三方客户端，并使用类似于OAuth的某种令牌系统进行身份验证。客户端UI将使用此令牌机制来验
-
在REST spring Boot中对用户进行授权和身份验证的最佳实践是什么？ 我正在构建一个带有标准页面+REST API的移动应用程序。我看了很多关于Spring Security性的文章，基本上大多数都采用了某种fitler方法，允许或阻止REST调用。然而，在我的例子中，我有一些基于用户是谁的身份验证逻辑。例如，有一个API可以更新用户信息，用户可以更新自己，但不能更新其他人。最初我想使用