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

Question

我正在努力寻找一个清晰简洁的例子,说明如何使用令牌实现基于服务的身份验证方案.据我所知,基本步骤如下:

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

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

Answer 1

我假设在这种情况下,"令牌"只需要是客户端可以解密的加密字符串,或者某个随机字符串存储在某个地方(即数据库),然后客户端可以验证,但我不确定然后客户端应该使用令牌或者为什么你甚至需要一个令牌 - 简单的用户ID也不能满足要求吗？

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

从服务的角度来看,此令牌必须:

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

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

编辑2013年6月

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

基本上他们只做这里描述的内容.

如果你想要一个很好的示例实现,你可以看看Apigee的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服务器设置的生存时间.