我在试图找到清晰简洁的示例，说明如何使用令牌实现基于服务的身份验证方案。据我所知，基本步骤如下：使用令牌进行基于服务的身份验证
第三步和第四步是我陷入困境。我假设在这种情况下，“令牌”必须是客户端可以解密的加密字符串或者存储在某处（即数据库）的随机字符串，然后客户端可以对其进行验证，但我并不确定客户端应该怎么处理令牌或为什么你甚至需要令牌 - 不能使用简单的用户ID也足够了？
我承担的“令牌”，在这种情况下，只是 ，必须为加密的字符串 客户端可以解密或获取存储 某处一些 随机字符串（如数据库）的 客户端可以然后验证反对，但 我不确定客户端是什么 然后应该与令牌或 为什么你甚至需要一个令牌 - 不能简单的用户ID也 足够吗？
否 - 令牌是“乘车券”。就像地铁标记一样。客户在请求服务时将其呈现给关守。在这种情况下，提供程序会执行自己的身份验证，因此客户端会将该令牌返回给提供程序。在某些情况下，提供商可能会委托认证 - 例如在the STS model中，在这种情况下，提供商可能会将令牌交给第三方进行认证甚至授权。
但从服务点，此令牌必须：
因此在第3步中，提供者需要检查用户名和密码。如果验证通过，则创建一个令牌（哈希），它指向Dictionary或Hashtable中的条目。 Hashtable中的对象是包含用户名，IP地址，可能是原始颁发时间，可能与用户名关联的角色以及您想要存储的任何其他对象的结构。服务提供者将这个令牌（散列，而不是结构）发送回客户端，通常作为Set-Cookie。当客户端在后续请求中发回令牌（作为Cookie）时，提供程序将检查字典以查看令牌是否可用，是否超时，是否匹配请求的IP地址，是否为所请求的资源授权等。一切都很好，尊重请求。
编辑2013六月
它已经好几年了，而这个答案仍然得到选票。 我建议人们查看OAuth 2.0框架和持票人令牌。
基本上他们只是做这里描述的。
如果你想有一个很好的例子实现，你可以看看Apigee's Usergrid.它的工作原理是这样的：
用户验证
POST https://api.usergrid.com/token -d '{"username":"Joe","password":"Sec4et!","grant_type" : "password"}'
用户接收响应的的access_token
用户使用标题后续呼叫Authorization: Bearer XXXXXXXXXX w这里XXXXX被替换为不记名令牌。该令牌具有由usergrid服务器设置的生存时间。
这看起来很像Kerberos的工作原理。
典型的令牌是存储在服务器端的随机哈希。客户端将请求传回给客户端。这让你得到的是你不必一直传递密码，这显然是一切都好，并且令牌可以随时无效而无需更改密码。
当我查看相同的问题时，我发现Amazon S3的这个文档很有用。
的一般原理是你不想被身边掠过你的用户名和密码对于每个连续的服务电话，因为这不会是安全的。
你提到过关于只是将用户名传回给服务，但是这不会很安全。
您可能会考虑使用会话状态来存储用户已通过身份验证的事实，但是这违背了REST的一般原则之一，因此一切都应该是无状态的。
更好的链接是： http：//docs.amazonwebservices .com/AmazonS3/latest/index.html？RESTAuthentication.html – 2009-06-02 17:25:46
带会话的Web服务......嗯，这不是它应该如何。 Web服务并不意味着保持状态。
我环顾网络，大多数例子和文章都谈论SSL/TLS +用户名/密码。这将是很好的用“API密钥”基础设施替换用户名/密码，但我不知道如何“建筑师”这样的事情...
这里的一个假设是，你假设任何带有令牌的人都是他们所说的人。有没有推荐的方法使它更安全？ – 2012-11-23 02:11:56