Google Data API - 两条腿的身份验证令牌重用
我正在为 Google Contact Data API 使用两条腿的 OAuth，并在每个请求上生成令牌。
是否可取或者我应该存储令牌以便下次重复使用吗？
另外，如何检测陈旧的令牌？
我正在使用Python。 （和 Gdata Python 客户端库）。
编辑：好的，我想，令牌是在客户端加密生成的，而不是从服务器端收集的，因此可以在每个请求上生成令牌。我说得对吗？这意味着，用户的令牌永远不会改变（除非我更改共享秘密），对吧？
I am using two legged OAuth for Google Contact Data API and generating token on each request.
Is it advisable or Should I store token to reuse it next time ?
Also, How to detect stale token ?
I am using python. ( and Gdata Python Client Library ).
Edit: Ok, I figure, the token is generated on client side with encrpytion and not collected from server side, so it is ok to generate token on each request. Am I correct ? and that means, the token never change for a user ( unless I change shared secret ) right ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为两条腿的oauth场景不涉及创建令牌。当用户参与交互（第三条腿）时需要令牌，因为用户需要授权该令牌。
用户没有直接参与 2-legged oauth，因此没有令牌授权，因此不需要存储和创建令牌。
基本上，2-legged oauth 意味着您作为消费者应该使用您的 CONSUMER 共享秘密（提供者也知道）签署您向提供者发出的请求，以便提供者知道哪个消费者正在发出请求 - 这是一个验证是否确实是您的应用程序需要数据的方法。但由于用户（第三条腿）不参与，提供商不会创建令牌来给您，因为您不需要令牌 - 如果提供商支持两条腿并且您的应用程序是，您只需直接访问数据即可允许使用该数据。
这是一篇很好的文章，可以更详细地解释两足和三足流程的流程。
http://hueniverse.com/2008/10/beginners-guide -to-oauth-part-iii-security-architecture/
只是添加一些内容作为结论：
2-legged oauth 只是一种身份验证方法 - 消费者通过使用他的密钥签署请求来验证自己（这验证了哪个消费者确实提出了请求）。
3-legged oauth 是身份验证和授权 - 消费者通过使用其密钥签署请求来进行身份验证，并获得未经授权的请求令牌，然后需要用户授权该令牌，以便消费者可以向提供者发出授权请求。
I think that the two legged oauth scenario does not involve creating tokens. Tokens are required when a user is participating in the interaction (the 3rd leg), because the user is required to authorize that token.
The user is not participating directly in the 2-legged oauth, so there's no token authorization and therefore no need to store and create tokens.
Basically 2-legged oauth means that you as a consumer should SIGN the request that you make to the provider with your CONSUMER shared secret (which the provider also knows about), so that the provider knows WHICH consumer is making the request - this is a way to validate that it's really your application that is requiring data. But since the user (3rd leg) does not participate, the provider does not create a token to give you, because you don't need one - you just get direct access to the data, if the Provider supports two legged and your application is allowed to use that data.
Here is a good article that can explain in more details the flow for two-legged and three legged process.
http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iii-security-architecture/
Just to add something as a conclusion:
2-legged oauth is just an authentication method - consumer authenticate himself via signing the request with his secret key (this verifies which consumer is really making the request).
3-legged oauth is authentication and authorization - consumer authenticate via signing the request with his secret key and he get unauthorized request token which then needs to be authorized by the user, so the consumer can make authorized requests to the provider.