开发JSON API时如何正确存储session？

但这有多正确呢？

根本没有其他方法。您需要以某种方式识别 API 的用户。通过任何间接迹象，您无法识别它 - 多个消费者可以坐在一个 IP 上，原则上没有用户代理，通常它只是一个欺骗性标头，仅此而已。

因此，您需要在每个请求中传递一些标识符，以帮助您找到用户。这里有一些微妙的地方：

• 不应该是用户ID本身（否则整个机制就突破了ID的劫持，被劫持的用户除了杀了他什么也做不了）
• 此标识符（或与之关联的机制）必须明确确认会话的正确性或仅通过安全通道 (HTTPS) 传输，否则它可能会以完全相同的方式被盗并显示为错误的用户。
• 标识符应被视为应用程序中的消耗品：它们可以始终是 bang，并且可以创建新的标识符，以便在检测到盗窃后可以立即重置任何被盗的标识符

常见的方法是在任意标头（github、google、amazon s3）中传递访问令牌。无论哪种方式，身份验证信息始终保留在标头中（它在查询参数中没有位置，而是直接在请求正文中），因此这里也没有太多选择。令牌存储在设备上，以防万一，用户删除令牌（使用相同的访问令牌）

最后一段是关于确认会话的正确性，通过不安全的通道传输。
如果担心令牌在传输过程中被拦截，则有必要以某种方式对传出请求进行签名。为此，您可以使用完整或轻量级的挑战-响应身份验证，其含义可以简化为服务器和客户端互相询问只有他们自己才能解决的谜语。在最简单的版本中，服务器可以发布一个由标识符和秘密部分（加密密钥）组成的令牌，在创建令牌时将其传输一次给客户端（客户端也可以发送一些秘密，但我们认为服务器始终可以信任）。之后，从客户端到服务器的所有消息要么使用接收到的密钥完全加密，要么在附加标头中包含基于密钥和请求主体生成的签名，攻击者无法伪造该签名，在不窃取密钥的情况下。然而，这本身并不能防止：

• 重播攻击（例如，如果用户发送请求“删除最后一个条目”，那么攻击者可以生成另外一百个这样的请求并完全清除用户的历史记录）。最简单的解决方案是兼顾时间戳（例如，不接受超过 5 秒的请求），但会在最轻微的时间问题上开枪。
• 从客户端物理撤回密钥。一般认为这是防不胜防的，这一点索性就忽略了。
• 在颁发令牌时拦截密钥（因此，毕竟还是获得 HTTPS 比较好）。对于开放流量，您可以使用 Diffie-Hellman 算法和类似物，但这比编写应用程序本身要花费更多时间。
• 使用不正确算法时的密钥计算（例如，如果没有密钥轮换并且如果攻击者知道始终使用 JSON，那么他知道最后一个字符始终是}or ]，可以通过比较不同长度的请求来计算密钥）。同样，采用 HTTPS 更容易，还有其他方法，但我不会告诉他们，以免无意中错过重要的一点。

更新。有一个标准的json web token，我自己还没有读过。

这是 API 开发的正确方法之一。在开发 REST API 时有这样一种情况，即无状态（STATEless）。

客户端的状态不以任何形式存储在服务器上，这完全由客户端自己完成

服务器与客户端接口及其状态无关。在服务器端，用户上下文不会在两个不同的请求之间保存。

每个请求都包含处理程序所需的所有信息，会话状态存储在客户端。

无状态提高了 Web 服务性能并简化了服务器端组件的设计和实现，因为服务器上的无状态消除了与外部应用程序同步会话数据的需要。