Krishna, whereas SAML defines the token format, OAuth doesn't, so this is an intended side-effect: the possible perfect forward security of tokens, if the issuer so desires. It is kinda sorta elegant, but it adds some complexity.
On Sun, Feb 1, 2009 at 10:39 AM, Krishna Sankar (ksankar) <[email protected]> wrote: > > John, > Good point and thanks for the details. I think we are talking about > the same thing, but possibly in a slightly different context. Let me > elaborate my understanding. > > a) In steps #c and #d of the flow diagram, the oauth_token is > optional. So, in cases, where it is not used, the unauthorized & authorized > requestTokens would be the same > > b) Yep, the act of Step 2, will change the state of the SP. But > that does not necessarily mean that the state would be persisted at the SP > side. > > c) In 6.2.1, the SP can require the oauth_token (the unauthorized > requestToken, in this case) be present for step #c. And it can require a > callback URL be present. > > d) In which case, in step #d an oauth_token (the authorized > requestToken, in this case) would be sent back - section 6.2.3 > > e) The spec does not say clearly if the token sent back in 6.2.3 > is the same as the one in 6.2.1 > > f) Couple of scenarios I was looking at have the (possibility of > the) OAuth engine separate and loosely coupled with the services. For example > OAuth engine in a firewall or a separate OAuth service for a collection of UC > services. In all these cases, embedding the state in the token is attractive. > Having said that, thanks for this discussion, I doubt now, if one can really > afford not to go back to the OAuth engine to check the state. While it might > be choreographically possible, it might not be wise from a security > perspective. > > g) In any case, I would like to get the insight on the inclusion > of the tokens in 6.2.1 and 6.2.3. If they are the same, why exchange them ? > Is it for the optimization at the consumer side ? Were there any other > scenarios ? And why call them by two names - authorized and unauthorized > tokens - if they are the same ? Thoughts ? > > Cheers > <k/> > > |-----Original Message----- > |From: [email protected] [mailto:[email protected]] On Behalf > |Of John Kristian > |Sent: Saturday, January 31, 2009 6:56 PM > |To: OAuth > |Subject: [oauth] Re: Problem accessing OAuthAccessToken > | > | > |We're not communicating clearly, I fear. Let's use the terms from the > |OAuth Core 1.0 specification section 6 > |http://oauth.net/core/1.0/#anchor9 > | > |There are two tokens: a request token and an access token. The > |service provider chooses the tokens. They may be different. The > |service provider may pack data into the tokens, but this isn't > |specified by OAuth. > | > |There are three steps: > | > |1. The Consumer obtains an unauthorized Request Token. > |2. The User authorizes the Request Token. > |3. The Consumer exchanges the Request Token for an Access Token. > | > |Step 2 doesn't produce a new token. It changes state in the service > |provider, so the service provider associates authority (permission) > |with the request token. > | > |On Jan 31, 3:07 pm, "Krishna Sankar (ksankar)" <[email protected]> > |wrote: > |> I thought they *need not* be the same - because a service > |> provider could conceivably encode some opaque values in the > |> tokens and those might be different in the unauthorized & > |> authorized requestTokens. I am actually planning on these > |> two being different. Does the spec specify that these two > |> tokens should be the same ? > | > | > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
