我已经为移动应用程序开发了一个后端 REST API，我现在正在为其实现基于令牌的身份验证，以避免在每次运行应用程序时都提示用户登录。
我想到的是用户使用基于 SSL 的基本身份验证发送其凭据的初始请求。一旦服务器对凭据进行身份验证，它就会创建一个安全令牌并将其发送回用户，以便他们可以在后续请求中使用它，直到令牌过期或被撤销。
我正在寻找一些关于如何生成不受 MoM/Replay 攻击等事物影响的令牌的建议，以及确保无法提取存储在令牌中的数据。
我将使用以下方法来生成我认为会阻止从中提取任何数据的令牌。但是，我仍然需要确保它不会受到其他攻击的影响。
API 只能通过 SSL 访问，但我不确定从安全角度来看我是否可以完全依赖它。
“身份验证令牌”通过服务器如何记住它来工作。
通用标记是一个随机字符串；服务器在其数据库中保存从发出的令牌到经过身份验证的用户名的映射。可以自动删除旧令牌，以防止服务器的数据库无限增长。只要攻击者不能以不可忽略的概率创建有效令牌，这样的令牌就足够安全了，“有效令牌”是“已发出令牌数据库中的令牌”。令牌值的长度至少为 16 个字节并使用加密强 PRNG 生成就足够/dev/urandom了（例如， ... CryptGenRandom()，java.security.SecureRandom取决于您的平台）。
可以卸载客户端本身的存储需求。在上面的段落中，服务器应该对令牌有什么“记忆”？即用户名和令牌的生产日期。所以，像这样创建你的令牌：
由于他对K的了解，服务器可以验证用户发回的给定令牌是否属于自己；但攻击者无法伪造此类令牌。
您链接到的答案看起来有点像，除了它谈论的是加密而不是 MAC，那就是：
因为加密不是MAC。
简而言之，您应该使用加密强度一次性随机令牌，并在数据库中对其进行哈希处理。
令牌
用户使用令牌登录后，该令牌无效，应创建新令牌并提供给用户。在令牌过期的情况下，必须让用户使用他们的真实凭据再次登录。
可以在基于表单的网站身份验证的权威指南的第 2 部分中找到对这些规则的更明确和冗长的描述：
持久登录 Cookie（“记住我”功能）是一个危险区域；一方面，当用户了解如何处理它们时，它们完全与传统登录一样安全；另一方面，它们对大多数用户来说是一个巨大的安全风险，他们在公共计算机上使用它们，忘记注销，不知道 cookie 是什么或如何删除它们等等。
[...]
关注Charles Miller 的“最佳实践”文章。不要试图遵循他文章末尾链接的“改进的”最佳实践。可悲的是，该方案的“改进”很容易被挫败（攻击者在窃取“改进”cookie 时所要做的就是记住删除旧的。这将需要合法用户重新登录，创建一个新的系列标识符并保留被盗的有效）。
并且不要将持久登录 COOKIE（令牌）存储在您的数据库中，只存储它的哈希值！登录令牌是密码等效的，因此如果攻击者掌握了您的数据库，他可以使用这些令牌登录任何帐户，就像它们是明文登录密码组合一样。因此，在存储持久登录令牌时使用强加盐哈希（bcrypt / phpass）。
更新：对不起，我误解了这个问题。您链接的方法看起来很合理，但它不会保护您免受重放攻击或中间人攻击。您应该同时使用 SSL。
一个纯 RESTful API Web 服务应该使用底层协议标准特性：
对于 HTTP，RESTful API 应该包含并遵守现有的 HTTP 标准标头、状态代码和方法。添加新的 HTTP 标头违反了 REST 原则。
RESTful 服务必须是无状态的。任何技巧，例如尝试记住服务器上先前 REST 请求状态的基于令牌的身份验证，都违反了 REST 原则。
底线：出于身份验证/授权的目的，您应该使用 HTTP 授权标头。并且您应该在需要验证的每个后续请求中添加特定的 HTTP 授权方案标头。
我为 Cisco Prime Performance Manager 应用程序开发了一个 RESTful Web 服务。在 Google 中搜索我为该应用程序编写的 Cisco Prime Performance Manager REST API 文档，以获取有关 RESTFul API 合规性的更多详细信息 - 请参见下文。对于这个应用程序，我们选择使用 HTTP“基本”授权方案来验证和授权请求。显然，在使用 HTTP 授权时，我们正在使用 HTTP 对从客户端到服务器的所有数据进行加密。