[oauth] Re: OAuth server
On Aug 11, 8:29 pm, Shunde Zhang dickie.ch...@gmail.com wrote: Hi, I am interested in OAuth and want to set up my own oauth env. From the website, all I found are oauth client libs. I would like to know whether there are open source oauth servers, or apache modules. What I want to set up is just like how google oauth works, I have an LDAP server, and want to set up something on top of that to let users authenticate against it with oauth protocol, then I set up another service provider so that users can attach the token when accessing it, and the service provider can validate the token with the oauth server. Is there anything like this yet? Cheers, Shunde There are sample oauth servers on code.google.com in PHP and Java (not sure about others). However these may need to be customized per your needs but act as a very good reference implementations. You can use any identity/auth server - OAuth does not rely on the authentication store, it delegates the authentication process to the identity provider. The end user will still login as if he were logging into the identity provider's site - OAuth is handed back the control after the auth is done at the identity provider. In other words, you'd need to have that login part on your site regardless of OAuth. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Verifying signed opensocial request
On Jul 24, 8:51 am, John Kristian jmkrist...@gmail.com wrote: This is specified byhttp://oauth.net/core/1.0a#signing_process(look for 'Verifying Signature' for each of the signature methods). Software that implements it in several languages is available. For HMAC signature methods, you'll need the consumer secret and token secret (in addition to the request parameters). I would guess the token secret is empty, but I'm not familiar with OpenSocial. Some fine points: don't include the oauth_signature in the signature base string. Decode the other parameters and re-encode them into the signature base string. Decode the oauth_signature and use the resulting binary value to verify the signature. On Jul 24, 7:55 am, jaap j...@q42.nl wrote: I'm creating an opensocial widget. The widget can make SIGNED requests to an arbitrary url. The signing is done by the opensocial container. The result is a request which is enriched with these attributes: * opensocial_owner_id * opensocial_viewer_id * opensocial_app_id * oauth_consumer_key * oauth_token (empty) * xoauth_signature_publickey * oauth_signature_method * oauth_nonce * oauth_timestamp * oauth_signature I want to verify that that the request is genuine. I this this should be possible with the oauth signature and the public key, but I don't know where I should begin! Can someone please explain how I should verify the signature against the request? It's probably somewhere in the oauth documentation but I couldn't find it between all the other use cases of oauth (i.e. requesting a token and using it). In addition to the spec, the Editor's cut of the spec has very good and detailed information about the signing process. I found it extremely useful while implementing my provider. http://oauth.googlecode.com/svn/spec/core/unofficial/1.0ec/drafts/1/spec.html -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Same Access Token on multiple requests
On Jul 18, 5:04 am, Monis monisiq...@gmail.com wrote: Twitter, MySpace return us same access token when using the one consumer with the same user, multiple times. Is this OK from oauth standards? as the specs state that a request token can only be exchanged once for an access token. I'd think that it should be fine as long as the token is not timing out, or is being explicitly revoked by the consumer/user. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: How should the be notified if a request for authorization is denied?
On Jul 13, 4:48 pm, Richard Wallace rwall...@thewallacepack.net wrote: The OAuth spec section 6.2.3 states that If the User denies access, the Consumer MAY be notified that the Request Token has been revoked. At first I was thinking that I would just flag the request token as being denied on the service provider and then when the consumer tries to swap tokens specify that the oauth_problem is permission_denied. But when the service provider redirects the user to the consumer callback URI, should I still pass the verifier parameter or not bother? Is this the right way to let the consumer know the request has been denied? Thanks, Rich Ideally the verifier should only be generated after the user has permitted/authorized the consumer. So, the callback will not carry a verifier if the user has declined the authorization. Another way is to not callback at all, and have the consumer try to convert the token to an access token, and return HTTP 401 indicating that the request token being attempted to be converted is not authorized. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Two questions
On Jul 9, 11:23 pm, Avi syndicatebk...@gmail.com wrote: Thanks guys I am able to read the java doc from the svn repo. Manish, where is this blog post you were referring to? Here you go: http://oauth.net/documentation/getting-started -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Two questions
On Jul 8, 3:47 am, Avi syndicatebk...@gmail.com wrote: Hi all, I have recently integrated Shindig into my application, I have a very layman's view of OAuth, so the questions may sound silly.I want to implement the Service Provider side of 3-legged OAuth. I have a couple of questions, 1) Being the Service Provider, what are the things I Must do at user registration, Consumer registration and user login using OAuth( i.e. request for an unauthorized Request Token )? , in terms opensociallD, request-token, consumer-key/secret etc. 2) Is there any documentation of the classes in oauth- core-20090315.jar? If not where can I find the individual classes with their javadocs? Thanks to everybody, Avishek Not sure if I can answer your first question - you might want to read EHL's blog to get more information about OAuth from a spec implementor's standpoint. What you're trying to ask is the protocol flow on the provider's side which is covered in the spec (except of course the registration, login and openSocial). As far as second question goes, why don't you check out http://oauth.googlecode.com/svn/code/java/core/ and run javadoc on it via Maven? Also I am not sure I understand what you mean by individual classes - explode the jar to get binaries, and check out the code from the svn repo for the source code.. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: POST parameters in the signature
On Jul 6, 8:59 am, Toby toby.o.h.wh...@googlemail.com wrote: From the OAuth spec, para: 9.1.1, on constructing the signature: The request parameters are collected, sorted and concatenated into a normalized string: * Parameters in the HTTP POST request body (with a content-type of application/x-www-form-urlencoded) [...] Can I take this to mean that POST parameters which are encoded as multipart/form-data should not be included in the signature? Toby I'd agree. You cannot do getParameter() on a Multipart Request anyway (in Java). -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Avoiding replay attacks through timestamp and nonce
On Jul 4, 3:10 pm, Monis monisiq...@gmail.com wrote: Any suggestions? As a provider implementor, I found the timestamp-nonce verification a little heavy on the database side (using multiple VMs with no sticky sessions, so in-memory caching is not an option). From a database standpoint, it would mean storing the TS+nonce for the +/- time window in the db, regular cleanup which gets more and more high-maintenance with heavy transactional volumes. I'd think setting up the window to +/- 3 minutes should help mitigate reply attacks, however this will most certainly guarantee protection. The only thing that can protect is persisting the ts-nonce tuple either in-memory on in-database. You'd have to consider if adding this extra baggage is worth it based on the application and its audience IMO. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth.net Java library release info
On Jun 23, 10:14 pm, John Kristian jmkrist...@gmail.com wrote: I recently committed a change to support the 1.0a spec, but it hasn't been released. I'll release it, if you like: +1 for releasing it.. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Should the signature generation include oauth_version?
On Jun 26, 6:40 am, Cosimo cosimo.strepp...@gmail.com wrote: I'm almost done implementing an OAuth provider, starting to test some real world application. Right now I'm using the javascript demo here: http://oauth.googlecode.com/svn/code/javascript/example/index.html in particular, the get request token part. I see that the provided examples work. When I try with my own provider, it doesn't work. My provider signature verification is based on Net::OAuth. The only difference is that I can see between the generated signature and the request one is that the base string is missing oauth_version. The javascript library in the example does *not* include oauth_version in the arguments, and it doesn't include it also in the base string, while Net::OAuth does by default, even if the request has no oauth_version, because optional. Reading the OAuth specs, it seems that oauth_version should *not* be included if it's not present in the request, but then I wonder why others using Net::OAuth don't have this problem. So, what is the correct behavior here? -- Cosimo The only 2 params I am aware of that need to be excluded are the realm (if present, and it is not technically an oauth parameter anyway) and the oauth_signature. The version is an optional param and if present, I'd think you have to include it to calculate the signature. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Should the signature generation include oauth_version?
On Jun 26, 10:12 am, Kelvin Kao null7...@gmail.com wrote: Can we assume if there is any oauth_ reserved parameters, the service provider has to take in as consideration as base string? thx Sincerely, Kelvin Kao Every request has a set of required oauth parameters - you should be rejecting the request as a provider if the request does not contain the required params. Again, this varies with the request type (getRT, getAT, authorizeToken, access resources). The base string should take into account all the parameters (oauth or not) to construct the normalized parameter string. I'd recommend you go through signature section of the Editor's Cut of the spec which goes over the signing process in great depth. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: What about consumer' callback URL?
On Jun 25, 5:54 am, Monis monisiq...@gmail.com wrote: Can anyone please respond to this? Thanks, Monis The spec does not provide details on the registration (and it should not). So what fields are needed by the consumer to register on an SP are driven by the SP and not by the spec. Yes, callback URL, or callback domain can be one of the fields but the spec cannot and should not assume that anyway. Should you choose, you may not want to register the URL with the consumer info, or you may store the URL and then verify if it is the same as the one provided during registration. The callback does not eliminate the session fixation attack per se - it does help to temper-proof the callback. In other words, a hacker cannot change the callback and hijack the session without knowing the signature (it is a signed request). Also, if the callback is oob, then the consumer needs to have the user enter a verifier code manually before proceeding to request an access token. This is where the flow changes between a real callback vs. an oob (out of band) callback. The session fixation attack can be fixed only when the consumer does not do early binding. You can search on this group as there have been a lot of discussion around early vs. late binding. It is beyond the provider's control IMO. Hope this helps! -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Access Token Secret
On Jun 24, 1:29 pm, Kelvin null7...@gmail.com wrote: Does Access Token Secret need to be replaced/changed after consumer obtains access token? (after end user accept his/her authorization) I am just wondering if we already have token secret at the 1st request, should access token secret need to be changed again? Not sure if it's required by the spec. thx. I don't think so. You'd use the same Access Token/Token Secret combo till the Access Token is revoked, or expired per the consumer/provider guidelines. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Help required for implementing OAuth..
On Jun 21, 10:46 pm, madilator madila...@gmail.com wrote: Hi All, I am a beginner in studying OAuth.. I read its details form OAuth Core1.0 and some other resources.. i am really confused in implementing OAuth in Java API.. Can any one guide me through the initials steps.. Any Tutorials about working and fetching data from Google(just for a start).. You plan to implement the server or the client? From your message it seems you're interested in writing a client to access OAuth protected Google services. Start by looking at the examples (http:// oauth.googlecode.com/svn/code/java/example/) and that should give you a good idea. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: To enable a provider to access consumer's resources
On Jun 5, 7:34 am, ritou ritou...@gmail.com wrote: I think that SP should be able to access a resource of Consumer. For example, it has some merit for both that SP displays contents of Consumer on own page. Why would an SP need the details of a consumer, other than the about/ registration information and what it is trying to do with the customer data (to be shown on the authorization page)? Can you elaborate with a use case? -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Quick questions on Signed Callbacks (1.0a)
On Jun 2, 1:39 pm, 24z ralf.rottm...@gmail.com wrote: Just two quick questions for clarity: 1.) Do I understand Signed Callback URLs correctly in that signed here has nothing to do with generating a signature as described in 1.0? oauth_signature becomes a part of the process while calculating the signature for the get_request_token endpoint, i.e. it is encoded/ sorted/re-encoded etc. just like any other oauth parameter to generate the signature. 2.) Does Signed Callback URLs in essence mean that the Service Provider returns a unique vetifier (= an arbitrary string) after authorization that is therefore only known to the honest consumer/user and must be send back to the provider when requesting the Access token? Right - signed callback URLs will ensure that no one can change the callback in the middle of the oauth-dance, as it is signed with the secret during the very first call (to get_request_token). The verifier is generated by the provider as a result of the authorize_token step and can be sent to the consumer via the callback parameter, or manually (if oauth_callback = oob). This verifier is then used as a part of the request to get_access_token, which BTW is signed too. Did I get all of this right? And: What's the current status of OAuth 1.0a. Is 1.0a an official version or is it still draft? I believe 1.0a is in its 3rd draft dubbed as implementer's draft and no further changes were expected. This may need confirmation from the editor(s) though. Hope this helps! -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Improved User Experience for Installed Applications using OAuth
On May 28, 3:42 pm, jr conlin jrcon...@gmail.com wrote: It may just be that there are certain environments that one can't do OAuth. I'd rather that folks use a different auth mechanism for those than further confuse the standard. Well said. I've been thinking along the same lines after I met a few folks at IIW and discussed the same. This impacts registration (as there is no registration if everyone uses the same key/secret), and also the database side of things at the provider if the provider is maintaining database tables cross-referencing a consumer_key against issued token(s). Installed apps may need to use a really modified OAuth flow to meet the same level of security as the web-app scenario, but that will end up changing the protocol so much that it may not resemble the original.. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Including the signature base string in signature_invalid errors
On May 26, 11:26 am, Leah Culver leah.cul...@gmail.com wrote: Hmm... that might be best to report directly to Orkut or the Orkut API folks. Sorry I can't be more helpful, Leah On Tue, May 26, 2009 at 11:24 AM, Chirag Shah chiragsh...@gmail.com wrote: Unfortunately, several service providers do not provide this information in their signature_invalid errors. I was thinking it would be adopted by more service providers if it was suggested in the specification. Example: http://sandbox.orkut.com/social/rest/people/EXAMPLE_GUID/@friends/?oa... (Congrats Leah on the 5000th post!) On May 26, 10:55 am, Leah Culver leah.cul...@gmail.com wrote: On Tue, May 26, 2009 at 10:52 AM, Chirag chiragsh...@gmail.com wrote: When consumers encounter the infamous signature_invalid error, it's often useful to compare the signature base string[1] generated by the service provider with what the consumer generated. When looking at the problem-reporting extension [2], the signature_invalid section should encourage service providers to include the signature base string used to calculate the signature in the error response. If the service provider does not provide this information, the consumer is often guessing where the issue lives. [1] -http://oauth.net/core/1.0/#anchor14 [2] -http://wiki.oauth.net/ProblemReporting Thanks, Chirag Shah The Python OAuth library already includes the expected base string in the error response. What API or library are you concerned about? Feel free to file tickets against libraries here: http://code.google.com/p/oauth/issues/list Thanks, Leah Do you folks think it is a good idea to include the base string/ normalized request parameters, etc. in the signature check failure error message? I am not debating that, but kind of wondering if this is going to help much, as the problem could be with the (re)encoding/ (re)decoding as well which is hard to decipher from the error message containing the expected signature components. May be something like xoauth_debug=true could trigger such a verbose output, as I totally understand the frustration with failed signature checks.. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
At the risk of being yelled at, I wanted to get something cleared up. So I am in the process of updating my provider and going through the draft-2. However, I fail to understand (still!) how it fixes the original problem in case of callbacks. Desktops and no callback situations, I get it perfectly. However, when it comes to web based consumers with callbacks, even with the oauth_verifier, the process ends up linking the good guy with the bad guy's request token at the provider. I am going to upgrade my impl to keep the tokens one time use only, callback_url signing and oauth_verifier fix. However, the protection does not add up, as the attacker is behind the consumer, and the consumer is the one who automatically gets an access token upon receiving the callback with the verifier attached to it. This in turn still ends up linking the wrong identities on the provider. I know the TTL for request token and one-time access kind of mitigate the problem, but somehow I fail to understand how this actually fixes it.. *runs for cover* -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
On May 8, 6:04 pm, Brian Eaton bea...@google.com wrote: On Fri, May 8, 2009 at 5:31 PM, Manish Pandit pandit.man...@gmail.com wrote: However, when it comes to web based consumers with callbacks, even with the oauth_verifier, the process ends up linking the good guy with the bad guy's request token at the provider. Sweet. Last time somebody said this it was late on a Friday, too, and look how well that turned out. =) I'm pretty sure OAuth 1.0a isn't vulnerable to what you're describing, but I can't explain why without a more detailed explanation of how your attack works. Can you break it down into a step-by-step evil user does X, good guy does Y flow? I swear I just posted a huge description..I'll wait a few minutes and see if it shows up before reposting. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
There you go again:
Assumptions:
1. The provider requires a callback_url with get_request_token, signed
per the 1.0a.
2. The provider returns an oauth_verifier along the blessed request
token on the callback (if not oob) to the consumer upon user consent.
3. The consumer has a database table (or any other mechanism) to store
a user identifier (user's identity at the consumer), request token and
access token
4. The provider has a database table (or any other mechanism) to store
the user identifier (user's identity at the provider), request token
and access token
5. The endpoints are one time use only - so authorize_token and
get_access_token can be called once and only once for a given token.
6. The victim consents to providing access to the consumer for his
protected data.
7. The access token lives long enough for these steps (usually a few
hours)
8. The request token lives long enough for steps 3 though 11.
Flow:
1. Evil user (identity = eviluser) logs in to the consumer webapp.
2. Clicks a link to access protected resources on the provider
3. Consumer gets a request token per 1.0a (token1), and redirects the
eviluser to provider's login page.
4. Consumer record says {userId=evilUser, requestToken=token1,
accessToken=null}
5. Provider record says {userId = null, requestToken=token1,
accessToken = null}
6. eviluser copy-pastes this link and sends it to the soon-to-be
victim via IM to get everything done in the request token TTL which
can be few minutes. Evil user does not even need to be online after
this step.
7. The soon-to-be victim get the IM, clicks on the link.
8. Everything checks out, the victim logs in to the provider with his
credentials (gooduser). The provider updates the record at their end.
9. Provider record now says {userId=gooduser, requestToken=token1,
accessToken=null}
10. Provider now generates an oauth_verifier (abcd). Appends it to
oauth_token=token1 and calls back the consumer on the callback
provider in step 3
11. The consumer gets the callback with the token and verifier. The
record still says {userId=eviluser, requestToken=token1,
accessToken=null}
12. The consumer tries to convert this token to access token, now that
it has received the callback with a verifier. It may or may not store
the oauth_verifier. (In my provider implementation, I am not storing
the verifier and relying completely on the signature verification)
13. The consumer per 12 creates a signed request (including the
verifier) to request access token against the blessed request token.
14. The provider gets the request, and converts the requestToken to
access token as everything seems to be alright. The provider record
now says {userId=gooduser, requestToken=token1, accessToken=token2)
15. The provider returns the accesstoken to the consumer. Consumer
record now says {userId=evilUser, requestToken=token1,
accessToken=token2).
16. Now eviluser logs in to consumer, accesses a protected endpoint
(getAddressBook.do). Since the consumer already has an access token
for evilUser (see the db record above), it sends the request to access
protected resources.
17. The provider looks up the user who has that access token
(gooduser, see db record above) and returns gooduser's addressbook to
the consumer.
18. The consumer passes along the gooduser's addressbook to the
eviluser.
There you have it - I really really hope I am missing something here.
Since the spec does not have any guidelines for the consumer (it
should never do anyway), we cannot assume that the consumer is or is
not linking identities and tokens in a particular fashion. Besides I
think the whole scenario can be replicated without the record at the
consumer too, but Friday 6:45P I am too fried to think further :(
-cheers,
Manish
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
OAuth group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
On May 8, 6:04 pm, Brian Eaton bea...@google.com wrote:
Sweet. Last time somebody said this it was late on a Friday, too, and
look how well that turned out. =)
I'm pretty sure OAuth 1.0a isn't vulnerable to what you're describing,
but I can't explain why without a more detailed explanation of how
your attack works. Can you break it down into a step-by-step evil
user does X, good guy does Y flow?
Assumptions:
1. The provider requires a callback_url with get_request_token, signed
per the 1.0a.
2. The provider returns an oauth_verifier along the blessed request
token on the callback (if not oob) to the consumer upon user consent.
3. The consumer has a database table (or any other mechanism) to store
a user identifier (user's identity at the consumer), request token and
access token
4. The provider has a database table (or any other mechanism) to store
the user identifier (user's identity at the provider), request token
and access token
5. The endpoints are one time use only - so authorize_token and
get_access_token can be called once and only once for a given token.
6. The victim consents to providing access to the consumer for his
protected data.
7. The access token lives long enough for these steps (usually a few
hours)
8. The request token lives long enough for steps 3 though 11.
Flow:
1. Evil user (identity = eviluser) logs in to the consumer webapp.
2. Clicks a link to access protected resources on the provider
3. Consumer gets a request token per 1.0a (token1), and redirects the
eviluser to provider's login page.
4. Consumer record says {userId=evilUser, requestToken=token1,
accessToken=null}
5. Provider record says {userId = null, requestToken=token1,
accessToken = null}
6. eviluser copy-pastes this link and sends it to the soon-to-be
victim via IM to get everything done in the request token TTL which
can be few minutes. Evil user does not even need to be online after
this step.
7. The soon-to-be victim get the IM, clicks on the link.
8. Everything checks out, the victim logs in to the provider with his
credentials (gooduser). The provider updates the record at their end.
9. Provider record now says {userId=gooduser, requestToken=token1,
accessToken=null}
10. Provider now generates an oauth_verifier (abcd). Appends it to
oauth_token=token1 and calls back the consumer on the callback
provider in step 3
11. The consumer gets the callback with the token and verifier. The
record still says {userId=eviluser, requestToken=token1,
accessToken=null}
12. The consumer tries to convert this token to access token, now that
it has received the callback with a verifier. It may or may not store
the oauth_verifier. (In my provider implementation, I am not storing
the verifier and relying completely on the signature verification)
13. The consumer per 12 creates a signed request (including the
verifier) to request access token against the blessed request token.
14. The provider gets the request, and converts the requestToken to
access token as everything seems to be alright. The provider record
now says {userId=gooduser, requestToken=token1, accessToken=token2)
15. The provider returns the accesstoken to the consumer. Consumer
record now says {userId=evilUser, requestToken=token1,
accessToken=token2).
16. Now eviluser logs in to consumer, accesses a protected endpoint
(getAddressBook.do). Since the consumer already has an access token
for evilUser (see the db record above), it sends the request to access
protected resources.
17. The provider looks up the user who has that access token
(gooduser, see db record above) and returns gooduser's addressbook to
the consumer.
18. The consumer passes along the gooduser's addressbook to the
eviluser.
There you have it - I really really hope I am missing something here.
Since the spec does not have any guidelines for the consumer (it
should never do anyway), we cannot assume that the consumer is or is
not linking identities and tokens in a particular fashion. Besides I
think the whole scenario can be replicated without the record at the
consumer too, but Friday 6:45P I am too fried to think further :(
-cheers,
Manish
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
OAuth group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
On May 8, 9:10 pm, Darren Bounds dar...@cliqset.com wrote: I think was a little unclear in my statement regarding the Consumers' duties. Allow me to rephrase: As a consumer you need to do one of two things: 1) Mixed Binding - Ensure the user who initiated the dance is the one who completed it and then associate the access token/secret with that user. 2) Late Binding - Only rely on the identity of the user who completed the dance and associated the access token/secret with that user. What you've described is 'Early Binding' and generally a bad idea for the very reason called out. Darren Thanks, Darren. I am a provider, so I'd have to trust the consumer to do the right thing in this case..I cannot think of anything else either :( -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Friend Connect Vs OAuth
On May 7, 9:58 am, Ganex gan...@gmail.com wrote: Hello friends i am confused with GFC and OAuth. In the former we can directly integrate the Login module but not the same in the later. Can any one please suggest me which to go. I am good in Java / JEE. Thanks in Advance Ganesh INDIA Per my understanding, GFC implements a cookie based auth scheme, while OAuth is a much more involved spec, including the pre-auth steps as well as including more than just a cookie to access protected resources. It is not so much about programming languages, but depends on your application and its interaction with OpenSocial and/or any other platform like NetFlix/Twitter. Chris has a blog post here : http://blog.oauth.net/2007/11/07/oauth-and-opensocial/ What application are you trying to design? -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Service Provider side
On May 5, 9:15 am, vikas kumar cybertechie.in...@gmail.com wrote: Hi owenm, I just wanna confirm what is the means of accessing protected resources? Does it only mean to fetch the data from service provider? Actually i just wanna ask can a consumer bce redirected to the member area pages in Serivice provider just with AccessToken. It depends on your design, but one way I could think of is front- ending your protected resources (by URL pattern) with a servlet filter, which will do OAuth assertions before letting the request hit the protected resources or member pages. This filter will use access token as per the spec to ensure that the request is valid if I understand your question correctly.. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Confirm callback when getting access token
On May 5, 9:08 pm, Brian Eaton bea...@google.com wrote: On Tue, May 5, 2009 at 7:15 PM, Josh Roesslein jroessl...@gmail.com wrote: We would either have to increment the wire version OR the SP would have to use different end points for the two flows. WTF? No. Just pass *one* extra bit of data in the request token step do you support callback tokens? and get back *one* extra bit of data in the request token response yes. I'd agree. If the consumer gets back a HTTP 401 with missing required field for callback_url on the get_request_token call, he *must* understand that the provider supports the updated spec *only*. I do not see why would anyone stick to supporting the old version at this point - plus, the old spec implementation has to be EOL'd sooner or later anyway. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Confirm callback when getting access token
I'd agree. If the consumer gets back a HTTP 401 with missing required field for callback_url on the get_request_token call, he *must* Oops I meant HTTP 400.. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Desktop Application Callback Value
On May 1, 1:43 am, Blaine Cook rom...@gmail.com wrote: We need to gain some consensus around the value (or lack thereof) that should be used for the oauth_callback parameter that is sent from the consumer to the service provider when obtaining the request token in the new flow. Our options: 1. None. Applications that cannot receive callbacks (or that have static callback endpoints) should be configured as such in an out-of-band flow, along with the service provider issues the consumer key and secret. 2. String literal none 3. String literal, other than none I have omitted oob explicitly since it seems as though there was a lot of confusion around it. However, there is the option for a different string literal. I'd also like to hear from library authors whose voices have not been present in the discussions over the past week. Please indicate your preferred option as soon as possible. b. 3 for all the reasons Breno mentioned. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Version Preference
On May 1, 1:25 am, Blaine Cook rom...@gmail.com wrote: 3. 1.1 Option 3, 1.1 -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
On Apr 28, 1:37 pm, Jonathan Sergent serg...@google.com wrote: I can't help but think that if our libraries were good enough, people wouldn't run into these problems in the first place. Maybe I'm too optimistic, but I would hope that most people using OAuth never have to implement the parameter encoding themselves. There were really specific reasons we did the parameter encoding the way we did... I'd say a complete stack of test cases with coverage should help folks gain more confidence in sections 5 and 9, which I think seem to be the hardest ones. I like http://oauth.pbworks.com/TestCases but it could be evolved more (I'd look into items that I can add there). Overall I found the beginner's guide and the editor's cut of the spec helping me a lot. Another factor is familiarity with something like OAuth (like experience with writing Flickr/Facebook apps using their non-OAuth API) also helps to hit the ground running, as the core concept is more or less the same albeit non-standard. From my experience I'd say that the spec is hard, OAuth as a concept is not, and if a broader range of test cases would accompany the documentation, that'd make the consumer +provider implementors' lives a lot easier. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Signature HMAC-SHA1 question
On Apr 27, 3:11 am, Lee Gibbons lee.gibb...@gmail.com wrote: Hi, I'm implementing encrypted signatures in an app which supports oAuth and I have a few Q's that I'm having trouble finding answers to. The OAuth spec stipulates that for HMAC-SHA1 signatures the key is the concatentation of Consumer Secret and Token Secret seperated by . Does this mean that for the initial incoming call i.e. requesting request token, HMAC-SHA1 cannot be used for signatures because at that point the token secret has not been supplied ? If so why does the incoming request contain the oauth_signature_method parameter, surely it has to be plain text ? Lee. Just to add more on what Dossy pointed out, do not forget to keep the in there. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: What's the back story on why the callback wasn't included in the signature?
On Apr 23, 11:57 pm, Eran Hammer-Lahav e...@hueniverse.com wrote: Do you mean why the callback itself isn't signed? Or the parameter? EHL I think he meant signing the request that includes callback as a parameter for authorizing the request token (6.2.1 from the Spec). I agree that it will handle the callback tempering by the attackers. But wont this still leave out non-webapp consumers? But then again the OAuth model for non-webapp consumers has bigger fish to fry with the shared secret sitting on every device in cleartext. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On Apr 24, 1:04 am, Josh Fraser joshf...@gmail.com wrote: Manish, I may be leading you astray regarding the importance of the callback. Forgive me as I struggle to wrap my head around all of this. Who isnt struggling to wrap their heads around this..its 1:30a and I cant sleep :) Don't requests for access tokens need to be signed with the consumer secret? This means that an attacker needs the victim to return to the consumer site to complete the handshake because the attacker doesn't have the secret to make that request himself. Right? Yep - thats right. However, the elements of the signature have to be the ones that both provider and consumer are aware of (except RSA-SHA1 where the private/pub keys replace the shared secret). None of the parameters can be used to sign a request that either parties are unaware of, as the provider has to reconstruct the signature to verify the incoming request. The attacker will need access to the shared secret (or the private key) and token secret (if applicable) to property sign the request - none of these are sent on the wire. Does this confirm your understanding? -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On Apr 24, 8:50 am, Zachary Voase disturb...@googlemail.com wrote: Isn't it better to spend the time and effort educating users on when to give access to third party applications and when to deny it? It is a much needed strategy, but again, not a solution. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: JMeter
On Apr 21, 7:32 pm, Zhihong zhih...@gmail.com wrote: I'd like to find out how many people are interested in using JMeter to test OAuth-based services. We developed a plugin and like to contribute it back to JMeter. If enough people are interested, we will push to make it part of JMeter distribution. Otherwise, it will stay as an add-on. It's really simple to install plugin to JMeter (just drop the jar in lib/ext directory). The plugin adds an OAuth sampler to JMeter, which is based on HTTPSampler2. With it, you can fabricate any OAuth request as you wish and the plugin takes care of the signature on the fly when message is sent. Following is a snapshot of the control panel, http://farm4.static.flickr.com/3544/3464614476_c72453e7f3_o_d.png Let me know if you would like to try it out. Zhihong Let the folks on the thread know how we can help. I guess you can email us from the emails on our profiles. However, I know everyone on this group is too busy with the security thread ;-) -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: San Francisco meetup this Tuesday 5pm
On Apr 24, 2:42 pm, Leah Culver leah.cul...@gmail.com wrote: Hi all, My eyes hurt from trying to read long email threads. There's quite a few good ideas for helping protect against the current security issue and it will be helpful to get together to discuss. Here's the details: OAuth Meetup Tuesday, Apr 28th at 5pm Six Apart 548 4th Street I'll try to get the conference call stuff working too - more about this later. Sorry for the short notice! I'll try to summarize the meeting and get the notes back in the mailing list or wiki. Leah Thanks Leah for taking the initiative. I was wondering if some of us could meet at RSA Conference at SF but since today was the last day, I did not bother posting it. It'd be great if a conference call could be worked out due to location logistics, or future meetings (non-rush ones) can be done on Fridays/ Saturdays.. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: POST and PUT with OAuth
On Apr 24, 6:02 pm, Scott Seely sse...@myspace-inc.com wrote: The OAuth spec is silent on how to handle section 5.2 when an HTTP PUT |POST might be used to send in OAuth parameters AND resource content. For example, an OpenSocial endpoint uses OAuth for authentication and may post an XML encoded version of a Person. In this case, does a compatible OAuth endpoint have to accept OAuth parameters in the POST body or can it choose to only look for parameters in the HTTP Authorization header and on the query string? Scott Seely architect email sse...@myspace.com I'd think that a provider should document where they expect the parameters, if they do not support all 3. If they do support all 3, then they need to provide an order of precedence, that is if they even allow putting oauth params at more than 1 method. If you look at the editor's cut (http://oauth.googlecode.com/svn/spec/ core/unofficial/1.0ec/drafts/1/spec.html), it sheds a little more light on this issue in section 3.4. A disclaimer here - the editor's cut is not an official version, but you can co-relate the information for reference and clarity. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Handling nonce and timestamp
On Apr 18, 9:02 am, Zhihong zhih...@gmail.com wrote: Monotonical-increasing timestamp is not even possible in almost perfect conditions. We were hitting our servers using JMeter running on 2 boxes in the same data center and all our machines are synced with NTP. Just flipping a few pages through the log and I saw a case where timestamps are out of order. Zhihong On Apr 16, 2:06 am, Manish Pandit pandit.man...@gmail.com wrote: On Apr 15, 10:54 pm, Mike Malone mjmal...@gmail.com wrote: Depending on your use case that may work, but in practice I think loosening up the constraint requiring timestamps to be monotonically increasing makes sense. Sometimes it is convenient to generate URIs for later use, and other requests may be executed between the time such URIs are created and the time a request is made to the URI. Also, if you have a consumer key that is used across many devices (e.g., a desktop or mobile app, or a web app with multiple servers) there could be any number of reasons why request A may arrive after request B despite being signed earlier (e.g., clock drift or shoddy internet connectivity). So I'd say that strictly enforcing the timestamp constraint will probably be a problem... and since the nonce optimization you described relies on enforcement of the timestamp constraint I think it may not work in practice. Mike Outch..totally forgot about the desktop/mobile clients where a lot of requests could come in with the same consumer key..thanks so much! -cheers, Manish Thanks for your responses! After giving it some thought, I guess here is what makes sense (till I run into db led-performance issues). Due to multiple VM/cluster situation, I am avoiding the in-memory maps. Have a table with consumer_key, oauth_timestamp (in seconds), nonce, oauth_token and server_timestamp (this field will help clean the db). The filter can kick out any request not in the 10 minute window before nonce check happens anyway. The check will comprise of a select SQL to select the record(s) with oauth_timestamp smaller than or equal to the incoming oauth_timestamp for the same consumer_key and token. The query can return zero records, means this is a fresh request, leading to an insert in this table for the new request. The query returning multiple records could mean 2 things - either the incoming ts is same, or ts is smaller than the last request in the database for the same consumer_key and oauth_token. Check every record returned for oauth_timestamp. If the oauth_timestamp is smaller, reject the new request as it has to be greater than the old request oauth_timestamp. If the oauth_timestamp is equal, check the nonces - if they are same, reject the request (repeat attack). If not, this is a new, valid request and insert this record. This does add a requirement of keeping the db cleaned up via a TimerTask or something, for all requests outside of the window periodically. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Handling nonce and timestamp
On Apr 15, 10:54 pm, Mike Malone mjmal...@gmail.com wrote: Depending on your use case that may work, but in practice I think loosening up the constraint requiring timestamps to be monotonically increasing makes sense. Sometimes it is convenient to generate URIs for later use, and other requests may be executed between the time such URIs are created and the time a request is made to the URI. Also, if you have a consumer key that is used across many devices (e.g., a desktop or mobile app, or a web app with multiple servers) there could be any number of reasons why request A may arrive after request B despite being signed earlier (e.g., clock drift or shoddy internet connectivity). So I'd say that strictly enforcing the timestamp constraint will probably be a problem... and since the nonce optimization you described relies on enforcement of the timestamp constraint I think it may not work in practice. Mike Outch..totally forgot about the desktop/mobile clients where a lot of requests could come in with the same consumer key..thanks so much! -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
