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
-~----------~----~----~----~------~----~------~--~---
