S.O.上有许多优秀的问题（和答案）。围绕REST和安全主题。许多人说“纯粹主义者不喜欢这样，但是等等等等......”然后其他人说“你不应该这样做，因为等等等等。”
但我还没有看到“纯粹主义者”建议用于以下场景的解决方案。所以我的问题是 - 以下场景中的“纯RESTful解决方案”是什么？
简单的情景......
想象一下，建立一个数据库/网站，让用户管理自己喜欢的食谱。该网站公开了一个RESTful API，以便用户可以从他们想要编写的自定义程序（使用此API）中查询和操作他们的列表。
因此，用户“A”有3个最喜欢的食谱，ID为“1”，“2”和“3”。
用户“B”有两个最喜欢的食谱，ID为“4”和“5”。
我们需要确保如果用户A向DELETE发送/Recipes/4命令，他将收到Forbidden (403)响应。
我通常会做什么......
我通常会做的是让他们先调用一种身份验证方法，并向他们发送某种有效期为30分钟左右的auth-token。通常，此令牌将通过cookie传递。
什么是纯粹的解决方案？
纯REST解决方案是否让它们作为查询字符串中的变量传递？ Are cookies the devil?令牌是否应该用作URL的一部分（而不是查询字符串参数）？还有其他东西可以清楚地回答这个问题吗？
答案 0 :(得分：4)
在授权标头中传递令牌。这就是它的设计目标。见http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-12.html
答案 1 :(得分：1)
将身份验证令牌视为资源。
您通过GETting一个身份验证令牌进行身份验证，参数为凭据（例如，基本身份验证通过https）。
通过删除登录时获得的身份验证令牌资源注销。
答案 2 :(得分：0)
简单的无状态和无cookie解决方案将为每个用户提供相同的令牌。
有一些方法可以生成这些令牌，使其足够稀疏以解决安全问题。
e.g。 https://www.grc.com/passwords.htm
假设您有用户A和用户B.您为用户A生成令牌X，为用户B生成令牌Y.
因此，用户A将使用类似/X/Recipes/1
用户B将使用/Y/Recipes/4
这是安全的，因为用户A是唯一知道他的令牌的人，正如我之前提到的，你生成令牌的方式可以确保其他人猜测这个令牌“不可能”。
因此，如果其他人（例如用户B在网址中使用了其他一些令牌，请说/Z/Recipes/1），您应该能够识别并返回相应的错误消息。
您可以让用户在url中传递令牌，就像我上面所示，或者将其作为Autherticantion消息嵌入到HTTP请求中。