Google Data API - Two Legged Auth Token Reuse

Question

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 ?

Answer 1

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.