Google Data API-两足式身份验证令牌重用 [英] Google Data API - Two Legged Auth Token Reuse

查看:118
本文介绍了Google Data API-两足式身份验证令牌重用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我对Google Contact Data API使用了两腿的OAuth,并在每次请求时都生成了令牌.

是明智的选择还是应该存储令牌以便下次再次使用?

此外,如何检测过时的令牌?

我正在使用python. (和Gdata Python客户端库).

好的,我想,令牌是通过加密在客户端生成的,而不是从服务器端收集的,因此可以在每个请求上生成令牌.我对么 ?这意味着令牌永远不会为用户更改(除非我更改共享密码),对吗?

解决方案

我认为两条腿的oauth场景不涉及创建令牌.用户参与交互(第三回合)时需要令牌,因为需要用户授权该令牌.

用户不是直接参与两足式oauth,因此没有令牌授权,因此不需要存储和创建令牌.

基本上是两足的oauth,这意味着作为消费者,您应该使用您的CONSUMER共享密钥(对提供商也知道)对您对提供者的请求进行签名,以便提供者知道哪个消费者正在发出请求-这是一种验证确实需要数据的应用程序的方法.但是由于用户(第3条腿)没有参与,所以提供程序不会创建令牌来提供给您,因为您不需要一个令牌-如果提供程序支持两条腿并且您的应用程序是允许使用这些数据.

这是一篇很好的文章,可以更详细地解释两足和三足流程的流程.

http://hueniverse.com/2008/10/初学者指南-oauth-part-iii-安全体系结构/

只需添加一些结论即可:

两足式oauth只是一种身份验证方法-消费者通过使用他的密钥对请求进行签名来验证自己(这可以验证哪个消费者确实在发出请求).

三足式oauth是身份验证和授权-消费者通过使用他的密钥对请求进行签名来进行身份验证,然后他将获得未经授权的请求令牌,该令牌需要由用户授权,因此消费者可以向提供者提出授权请求./p>

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 ?

解决方案

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.

这篇关于Google Data API-两足式身份验证令牌重用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆