使用令牌进行基于服务的身份验证

Question

我很难找到一个清晰简洁的例子，说明如何使用令牌实现基于服务的身份验证方案。据我所知，基本步骤如下：

1. 客户请求用户输入用户名/密码
2. 客户端将用户名/密码传递给身份提供商
3. 提供商检查用户名/密码，如果用户有效则发送回令牌
4. 客户使用令牌执行某些操作？

第三步和第四步是我陷入困境的地方。我假设在这种情况下，“令牌”只需要是客户端可以解密的加密字符串，或者某个随机字符串存储在某个地方（即数据库），然后客户端可以验证，但我不确定然后客户端应该使用令牌或者为什么你甚至需要一个令牌 - 一个简单的用户ID也不能满足要求吗？

Answer 1

  

在这种情况下，我假设“令牌”   必须是加密的字符串   客户端可以解密或一些   存储的随机字符串   某处（即数据库）的那个   然后客户端可以验证，但是   我不确定客户是什么   然后应该用令牌或   为什么你甚至需要一个令牌 -   也不是一个简单的用户ID   足够？

不 - 令牌是“乘车票”。就像地铁代币一样。客户端在请求服务时将其呈现给网守。在这种情况下，提供程序会执行自己的身份验证，因此客户端会将令牌提交给提供程序。在某些情况下，提供程序可能会委派身份验证 - 例如在the STS model中，在这种情况下，提供程序可能会将令牌交给第三方进行身份验证甚至授权。

从服务的角度来看，此令牌必须：

• 有“保质期”。否则，令牌将无限可重复使用。因此，在服务器端，您可以将令牌存储在基于会话的存储中，您将免费获得超时。或者您可以构建一个带有过期的简单哈希表。
• 仅与持有人相关联。在许多情况下，提供程序在此处使用近似值并声明该令牌只能从原始请求IP地址使用。

因此，在第3步中，提供商需要检查用户名和密码。如果验证，则创建一个令牌（哈希），它引用字典或哈希表中的条目。 Hashtable中的对象是包含用户名，IP地址，可能是原始发布时间的结构，可能是与用户名关联的角色，以及您要存储的任何其他内容。服务提供者将此令牌（散列而不是结构）发送回客户端，通常作为Set-Cookie。当客户端在后续请求中发回令牌（作为Cookie）时，提供程序会检查字典以查看令牌是否可用，未超时，是否与请求的IP地址匹配，是否已获得所请求资源的授权等。一切都好，尊重请求。

---

2013年6月编辑

现在已经好几年了，这个答案仍然得到了投票。 我建议人们查看OAuth 2.0 Framework和Bearer令牌。

基本上他们就是这里所描述的。

如果你想要一个很好的示例实现，你可以看一下Apigee's Usergrid.它的工作原理如下：

1. 用户身份验证

   POST https://api.usergrid.com/token -d '{"username":"Joe","password":"Sec4et!","grant_type" : "password"}'

2. 用户收到响应中的access_token

3. 用户使用标题Authorization: Bearer XXXXXXXXXX进行后续调用，其中XXXXX将替换为承载令牌。此令牌具有usergrid服务器设置的生存时间。

Answer 2

典型的令牌是存储在服务器端的随机哈希。客户端将其请求传回给它。这样做的原因是你不必一直传递密码，这显然都是好的，而且无需更改密码就可以随时使用令牌无效。

Answer 3

我在查看同样的问题时发现Amazon S3的这个文档非常有用。

Authenticating REST Requests

一般原则是您不希望为每个连续的服务调用传递您的用户名和密码，因为这不会那么安全。

您提到过只是将用户名传回服务，但这又不是很安全。

您可能正在考虑使用会话状态来存储用户已经过身份验证的事实，但是这违反了REST的一般原则，即所有内容都应该是无状态的。

Answer 4

这看起来很像Kerberos的工作方式。

Answer 5

带有会话的Web服务......嗯，这不是它应该如何。 Web服务并不意味着保持状态 我浏览了网络，大多数示例和文章都谈到了SSL / TLS +用户名/密码。用“API密钥”基础设施替换用户名/密码会很好，但我不知道如何“架构”这样的东西......