Re: [oauth] OAuth simple example in .NET
Hi Mohammed, try the Xero documentation, we've done a few samples and some help around OAuth, and we use .net http://blog.xero.com/developer/api-overview/authentication/ this is based on OAuth 1 rather than OAuth 2.0 specs http://blog.xero.com/developer/api-overview/authentication/O On 12 October 2010 17:26, mohammed Nayeem nayeem4...@gmail.com wrote: Hi there, Can you please explain the usage of OAuth with just an simple example that's very understandable by the users very easily. preferable in .NET application :-) -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@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 are tokens saved on both the service provider and the consumer?
These are implementation questions and out of scope for a protocol specification, as long as you can meet the needs of the protocol (ie recall tokens and links between users and tokens) then the answer must be however suits. There really isn't a better answer without getting into specifics of your own system. Cheers Owen 2009/6/11 nyshaker7 lester.ble...@gmail.com How are tokens saved on the service provider? Is it just a database change? Also, how are they saved on the consumer side? Are they assigned to cookies? --~--~-~--~~~---~--~~ 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
This is down to good practice at the consumer end, The consumer shouldn't link a request token to a specific user until they receive the callback, at which point the request token should be looked up from the bucket of active request tokens based on the oauth_token value sent with the callback. The verification code then just ensures that the same person is requesting the access token as the person who requested the request token (as the callback is controlled during the request token step.) if the three steps are A: Request Token B: User Authorisation C: Access Token Swap. then the Callback links A:C and the verification code links B:C which means A:B:C are all linked suitably. there was no validation of this in the original spec which is why someone could hijack the process. Is that correct? O 2009/5/9 Brian Eaton bea...@google.com 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? --~--~-~--~~~---~--~~ 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
2009/5/8 Dirk Balfanz dirk.balf...@gmail.com You didn't like my the verification code matches the request token language? Dirk. IMHO that implies that the verification code value has some intrinsic link to the request token value, which is presumptuous about the implementation method. All we want to say is that the verification code matches the expected verification code at the SP. Without implying how the SP saves or comes about the expected verification code. O --~--~-~--~~~---~--~~ 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
I realise there's a link between the Token and the Verification code but not the Verification Code and Token VALUE which is how I would read the first one, i.e. the verification value has to be some kind of hash of the oauth_token value. Anyway, I'm playing devils advocate and it's not like I mind anyway the language all looks fine, it's just I'm explaining how I read it (and therefor some other laymen would/could read it). *The verification code is the same as the verification code sent by the stored procedure during the previous step?* O 2009/5/8 Dirk Balfanz dirk.balf...@gmail.com On Thu, May 7, 2009 at 12:45 PM, Owen Evans owenmcev...@gmail.com wrote: 2009/5/8 Dirk Balfanz dirk.balf...@gmail.com You didn't like my the verification code matches the request token language? Dirk. IMHO that implies that the verification code value has some intrinsic link to the request token value, which is presumptuous about the implementation method. I think that any implementation that doesn't have such an intrinsic link (be it as an explicit link in a database, as a signature, or perhaps as an implicit link through some other means) is broken, hence my proposed language. It might be the case that the verification code matches the user that approved the request token is good enough - it seems to prevent the session fixation attack we identified. But I thought that for good measure, we should actually require the verification code to be bound to a particular request token, not just a particular user (I don't know what can happen if we allow a user to approve two different request tokens, and then swap the verifiers he got for the two before returning to the Consumer). All we want to say is that the verification code matches the expected verification code at the SP. Without implying how the SP saves or comes about the expected verification code. That, again, assumes that there are two verification codes - the expected one, and the actual one. If the way I'm implementing this is have my verification code be the DSA signature of the request token, then there is no way for me to calculate the expected verification code (re-doing the signature on the request token will yield a different signature). All I can do is check that the actual one is kosher (b/c it matches the request token, not some expected verification code). Dirk. O --~--~-~--~~~---~--~~ 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
Doesn't really solve the problem: (malicious) User A gets the Authorisation URL from an application that has received a request token. User A replaces call-back parameter with malicious or spoof site instead of original call-back User A tricks User B (Innocent) into logging into SP with incorrect call-back parameter. User B is sent to malicious site which save the verification code. User A gets verification code from malicious site and uses it to redirect to original consumer application User A now has access to User B's resources. O 2009/5/6 Manger, James H james.h.man...@team.telstra.com I would like to suggest a slightly different solution for the OAuth session fixation bug. The Consumer App includes the Callback URI when obtaining an Access Token, instead of including the Callback URI when obtaining a Request Token. The Service Provider checks that the Callback URI in the request for an Access Token matches the Callback URI to which the authorizing user was redirected. The significant advantage of this approach is that the Consumer App knows the Request Token and Secret before they specify the Callback URI so they can encode state into the callback and operate in a stateless manner – which is important for scalability. An advantage of this approach for the Service Provider is that there is no extra state that has to be maintained between the Request Token and Authorization steps so the SP’s Request Token format should not need to change to maintain stateless operation. I believe Consumer Apps can operate in a stateless manner with OAuth Core 1.0 so it would be a significant disadvantage to break this ability in a security fix. My guess is that it would require very substantial changes to a Consumer App’s architecture if it had to switch from a stateless to a statefull mode to support a security fix. The Callback URI still appears in the authorization step, but changing it does not help an attacker since that would cause the subsequent request to obtain an Access Token to fail. 6.1.1. Consumer obtains a Request Token – UNCHANGED from 1.0 6.1.2. Service Provider issues an unauthorized Request Token – UNCHANGED from 1.0 6.2.1. Consumer directs the User to the Service Provider – UNCHANGED from 1.0 6.2.2. Service Provider authenticated the User and obtains consent – change warning text in some situations 6.2.3. Service Provider directs the user back to the Consumer – insert “verifier” into callback, or display “verifier” 6.3.1. Consumer requests an Access Token – CHANGED to include Callback URI 6.3.2. Service Provider grants an Access Token – UNCHANGED from 1.0 at the protocol layer, but the SP performs an extra check (that the Callback URI matches) before responding The OAuth wiki (http://wiki.oauth.net/OAuth-Session-Fixation-Advisory) compares proposed solutions with 10 questions. 9 answers for this proposal (callback with access token request) are the same as the “signed callback URLs” (callback with request token request) solution. The only difference is supporting a smooth upgrade path from 1.0 to the fixed protocol. This proposal can certainly support a smooth upgrade path, but it cannot use the presence of oauth_callback when obtaining a Request Token to indicate support for the new version. Any other indication would do. A different Request Token URI is one option. *James Manger* james.h.man...@team.telstra.com Identity and security team — Chief Technology Office — Telstra --~--~-~--~~~---~--~~ 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
true... must be in an after lunch stupor. O 2009/5/6 Manger, James H james.h.man...@team.telstra.com I think it does solve the problem, Owen. The SP redirects B to the malicious callback – and remembers that this malicious callback is associated with this request token verifier. When the consumer asks for an access token the consumer will include the original callback. The SP notices that the two callbacks are different and rejects the access token request. *James Manger* james.h.man...@team.telstra.com Identity and security team — Chief Technology Office — Telstra -- *From:* oauth@googlegroups.com [mailto:oa...@googlegroups.com] *On Behalf Of *Owen Evans *Sent:* Wednesday, 6 May 2009 11:09 AM *To:* oauth@googlegroups.com *Subject:* [oauth] Re: Confirm callback when getting access token Doesn't really solve the problem: (malicious) User A gets the Authorisation URL from an application that has received a request token. User A replaces call-back parameter with malicious or spoof site instead of original call-back User A tricks User B (Innocent) into logging into SP with incorrect call-back parameter. User B is sent to malicious site which save the verification code. User A gets verification code from malicious site and uses it to redirect to original consumer application User A now has access to User B's resources. O --~--~-~--~~~---~--~~ 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
Hi Simone, 1) Yes in my experience you should be storing, on the SP side the link between request token and consumer at the time when the request token is generated. 2) this is up to you, all you're generating is a key to give access to some resource how that key is secured, and if it gives only partial access to the system should be dependant on what makes sense in your application. A lot of services have a way of registering which resources the consumer will need when registering for a consumer token. Google OAuth has ways of specifying which Systems you want to have access to. 3) the SP needs to store as much information as is needed to create an access token that gives access to the correct user so either you pre-generate the access token and attach that to the user and the request token or you attach the user to the request token and generate an access token later (when the call to swap the request token for the access token is received). These implementation details are left to you as there's no way of telling you how your system could/should work. All you need to make sure is that when I, as a consumer, swap my request token for an access token I am given an access token that allows permission to get at the resources the user allowed me access to. Cheers Owen 2009/5/4 Simone simonx...@hotmail.com Hi, I'm new in this group. I'm studing the OAuth protocol and there are some questions that I would make you in order to verify if I've well understood. I've read yet many post of this group about that questions, but I want join all togheter. I know that the Core 1.0 leave at the Service Provider the freedom of implement its role in the protocol, infact in the next questions I try to understand what hypothetically should happen. 1) Service Provider side, what happens immediately after that the Consumer makes a request for an unauthorized Request Token? The Service Provider creates a local entry in its database where there is the bind between the Request Token and the Consumer? Because in the next step the Consumer redirects the User to login at the Service Provider and the Service Provider shows at the User that there is a specific Consumer that want access at the resources, but how knows what is this specific Consumer? Then I suppose that the previous local entry can be useful in this step, because the Service Provider can search in its database the entry for the Request Token and find the correspondent Consumer. It's correct or happens something else in this step? 2) By default, after the User is redirected by the Consumer to the Service Provider, if the User authorize the Consumer then the User grants the access at all its resources? By default in sense that, if I don't wrong, the Service Provider can also implements a way for grant a limited access, for example an only read access. 3) Service Provider side, what happens immediately after that the User grant access at the Consumer? The Service Provider creates a local entry in its database where there is the bind between the Request Token and the User, or between the User and the Consumer? Because when after the Consumer make a request for an Access Token, the Service Provider needs to knows what is the User involved, or not? Thanks to everybody :) --~--~-~--~~~---~--~~ 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
3 eom 2009/5/1 Blaine Cook rom...@gmail.com We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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: An OAuth attack on Consumer implementations
So can I ask, how do you not do early binding with desktop clients that don't receive the call-back? i.e. the only way of doing late binding is to identify via the call-back url which request token was authorised or denied so that that can be linked to the current user. If the application doesn't receive the call-back and relies on the user to tell the application that the step is complete there's no way of the application knowing which request token was authorised and must have a link between the user and request token prior to sending the user to the authorisation url? or am I missing something. Owen 2009/5/1 Mike Malone mjmal...@gmail.com On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein jroessl...@gmail.comwrote: Here is some pseudo python code of what I have in mind for a more higher level library: http://pastie.org/464241 This is not a final design, there are other details I have left out, but it demonstrates the flow for the consumer of authenticating with oauth. Yea, that's pretty much what I had envisioned. And I counter: http://dpaste.com/39773/ As long as the consumer is tasked with persisting the request token you're not going to be able to do much to prevent early binding. And I still don't think there's much risk here anyways. In all the time I've been talking to people about OAuth I've never heard of anyone trying to do this (has anyone else?). There's just no reason to do it, and (I'll reiterate) it's harder than doing the right thing. Also, your DataStore code is very similar to the way the Python OAuth library manages tokens for SPs, and that code is the most confusing / least understood bit of the library (just had a conversation with Leah about just that). So I'm wary of requiring consumer developers (who have less at stake and are often less experienced) to do something that's already confusing developers on the SP side. Mike --~--~-~--~~~---~--~~ 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: An OAuth attack on Consumer implementations
Ok but can I just confirm that the only way to do late binding is to have some parameter in the callback that identifies which Request Token was authorised/denied? Just want to make my understanding clear as there's nothing in the spec that says how this should be passed around (i.e. should it be oauth_token parameter sent on the query string of the callback, should this kind of thing be standardised? because really you want the SP to generate the callback parameters and not just take the oauth_callback verbatum as this could lead to a process just as easily worked around) O 2009/5/1 Josh Roesslein jroessl...@gmail.com Agree this security issue does not apply to desktop clients. On Thu, Apr 30, 2009 at 4:05 PM, Mike Malone mjmal...@gmail.com wrote: For a desktop app you're typically binding the app to an account vs. binding a user of the app to an account. In this case you just need to make sure that the user who authorized the request token is the same user who is clicking continue. This is what the oauth_verification PIN accomplishes. The situation is slightly different for web apps because a typical web app has more than one user, and can bind the access token to a different user than the one who returns after the authorization step. Early binding means the app is binding the request token to a particular user account before redirecting to the SP, then disregarding the user who returns after the authorization step and simply exchanging the request token for an access token bound to the same user account. Mike On Thu, Apr 30, 2009 at 1:48 PM, Owen Evans owenmcev...@gmail.comwrote: So can I ask, how do you not do early binding with desktop clients that don't receive the call-back? i.e. the only way of doing late binding is to identify via the call-back url which request token was authorised or denied so that that can be linked to the current user. If the application doesn't receive the call-back and relies on the user to tell the application that the step is complete there's no way of the application knowing which request token was authorised and must have a link between the user and request token prior to sending the user to the authorisation url? or am I missing something. Owen 2009/5/1 Mike Malone mjmal...@gmail.com On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein jroessl...@gmail.comwrote: Here is some pseudo python code of what I have in mind for a more higher level library: http://pastie.org/464241 This is not a final design, there are other details I have left out, but it demonstrates the flow for the consumer of authenticating with oauth. Yea, that's pretty much what I had envisioned. And I counter: http://dpaste.com/39773/ As long as the consumer is tasked with persisting the request token you're not going to be able to do much to prevent early binding. And I still don't think there's much risk here anyways. In all the time I've been talking to people about OAuth I've never heard of anyone trying to do this (has anyone else?). There's just no reason to do it, and (I'll reiterate) it's harder than doing the right thing. Also, your DataStore code is very similar to the way the Python OAuth library manages tokens for SPs, and that code is the most confusing / least understood bit of the library (just had a conversation with Leah about just that). So I'm wary of requiring consumer developers (who have less at stake and are often less experienced) to do something that's already confusing developers on the SP side. Mike --~--~-~--~~~---~--~~ 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: An OAuth attack on Consumer implementations
ha. must be blind... thanks (feeling slightly stupid) Owen 2009/5/1 Mike Malone mjmal...@gmail.com On Thu, Apr 30, 2009 at 2:14 PM, Owen Evans owenmcev...@gmail.com wrote: Ok but can I just confirm that the only way to do late binding is to have some parameter in the callback that identifies which Request Token was authorised/denied? Just want to make my understanding clear as there's nothing in the spec that says how this should be passed around (i.e. should it be oauth_token parameter sent on the query string of the callback, should this kind of thing be standardised? because really you want the SP to generate the callback parameters and not just take the oauth_callback verbatum as this could lead to a process just as easily worked around) Section 6.2.3 of the spec: After the User authenticates with the Service Provider and grants permission for Consumer access, the Consumer MUST be notified that the Request Token has been authorized and ready to be exchanged for an Access Token. If the User denies access, the Consumer MAY be notified that the Request Token has been revoked. If the Consumer provided a callback URL in oauth_callback (as described in Consumer Directs the User to the Service Provider (Consumer Directs the User to the Service Provider)http://oauth.net/core/1.0/#user_auth_redirected), the Service Provider constructs an HTTP GET request URL, and redirects the User’s web browser to that URL with the following parameters: oauth_token: The Request Token the User authorized or denied. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
