我正在为需要身份验证和授权的产品构建系统。我自然选择使用 OAuth 2.0，因为它是一种常用的协议，并且已被证明是有用的。
我正在考虑在没有存储的情况下实现令牌 - 如此处所述：http: //bshaffer.github.io/oauth2-server-php-docs/overview/crypto-tokens/
这将为我省去很多关于令牌存储的麻烦，当然这意味着我只需要在初始登录时访问数据库（当我发出令牌时）。
由于我没有看到这种常用方法 - 这种方法有什么实质性的缺点吗？这是一个重大的安全妥协吗？
我知道我不会有一些功能（比如注销删除令牌），但我觉得这在扩展应用程序时会有很大的好处。
使用加密的 OAuth 令牌是满足RFC-6749 第 10 节中的安全要求的好方法。加密的 OAuth 令牌很常见，Facebook 就是一个很好的例子。
OAuth 令牌根据expires_in参数过期。这意味着给定的令牌将在用户注销后的短时间内有效，这是大多数应用程序忽略的风险非常低的问题。一旦用户注销，即使 OAuth 令牌仍然有效，XSS 和 CSRF 等会话骑乘攻击也不应该发生。
只有当它们的寿命很短时，Auth 令牌才对我有意义。据我所知，这个方案并没有改变拦截的令牌可以重放的事实，这似乎是所有简单的基于令牌的方法的问题？（或者可能只是太晚了，我没有正确阅读：）
当然，我想确保每个客户都有一个独立的令牌，以便将风险限制在单个客户身上。
为了帮助减少令牌的曝光，如果可能，我会让客户端应用程序在到期时删除令牌并保持生命周期较短。
我自己对基于令牌的身份验证的实验使我意识到应该定期针对客户端来源（例如至少 IP 地址）验证令牌，以尝试防止拦截和重放。您可以将该信息保留在令牌中（因为它是加密的 - 显然不要尝试使用未加密的令牌），但问题可能是令牌变得相当大，这可能是通信的相当大的开销。
归根结底，您将不得不根据您准备承担的风险做出一些决定。就个人而言，对于相当安全的系统，我认为在大多数情况下我宁愿使用高性能、低开销的 NoSQL 数据存储。