[oauth] 400/401 Questions
Hey all, we're implementing OAuth and we have a differing of opinions on what the expected behavior is in a couple of instances. What is the proper HTTP status code to return for the following cases? 1) When a client uses the PLAINTEXT signature method over HTTP 2) When a client sends a value for the oauth_version parameter that is not 1.0 Thanks much! ~MIke -- 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] Javascript OAuth Wrap
Hello Ive recently started developing a desktop client for a new web application. Their API is based upon OAuth-WRAP. Does anyone one have any libraries or code relating to javascript development for this? -- 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.
Re: [oauth] Finer-grained access control in OAuth?
Hi Gerald, Your question is a good one — and gets at some of the challenges inherent in user authorization models. Specifically: when a user grants authorization, how do you effectively scope access and communicate that to the user? Should you or the user need to later change the scope of authorization, how do you do so? However, the way that you've described the problem is actually accurate. In fact, OAuth says nothing about how much (or how little) access a user MUST grant on a per instance basis. The amount of access authorized is dependent on the policies of the service provider and the user's relationship with the service provider. Therefore, a single OAuth token could access as little as your full name, say, or as much as all of your account details. OAuth says nothing about the scope of a given authorization instance. So technically, there's nothing to stop OAuth from behaving as you've described. The problem has much more to do with providing a user experience that is 1) comprehensible and 2) not annoying. While many people have said that they would love to have granular access and control over who has access to their data, in practice we find that people tend to click through authorization screens without really reading them. Getting people to take more care in authorizing third party access to their data would be a great thing, but is, for better or worse, outside the scope of OAuth. Chris On Sat, Mar 20, 2010 at 10:58 AM, Gerald jen...@gmail.com wrote: Hi, all I have been following OAuth work for some time. Also I have developed some apps using OAuth. One problem I encountered often is granularity of access. In current spec, after a user accepts the access request from a third-party app, the app can access all of user's data in arbitrary way. It is helpful to allow users control 1) which portion of his/her data will be exposed to third-party apps 2) what operations are allowed (read? write? update? etc). I believe OAuth community must have considered this problem before. But it's not included in the spec. I wonder whether there has been serious discussions on this problem. Anyone can point me to some related resources/pages/threads? Thanks Gerald -- 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. -- Chris Messina Open Web Advocate, Google Personal: http://factoryjoe.com Follow me on Buzz: http://buzz.google.com/chrismessina ...or Twitter: http://twitter.com/chrismessina This email is: [ ] shareable[X] ask first [ ] private -- 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.
Re: [oauth] Finer-grained access control in OAuth?
Thanks for your explanation. Yes, I totally agree with you from the perspective of technology. Technically, service providers can come up with whatever policies about scope of authorization, allowed operations, etc. However, one drawback is that users may get confused when they access different services protected by OAuth because these service providers may use different UIs, different terms (I mean wording), etc. So sometimes the user may not get the context of the displayed OAuth authorization page. They need to spend some time (maybe not trivial) to figure out what the sentences on the page mean exactly (e.g. who can access his/her data, which portion data is accessed, what operations are allowed). I have used some OAuth services. Most of the time, the description on the OAuth authorization page is really simple so that I cannot exactly know what will happen after I click the grant access button. From the page I can only tell some app wants to access my data. Nothing more. I guess this may be a reason why users tend to click through the whole process without careful reading. What I described matches your idea perfectly - The problem has much more to do with providing a user experience that is 1) comprehensible and 2) not annoying. My question is whether there is any effort trying to come up with some kind of standardized terms/UIs/process flows to improve use experience of OAuth authorization process. Another questions is in protocol level (not UI level) whether OAuth community plans to come up with 1) basic standard data operations (read, write, etc. of course, service providers can extend this) 2) how to specify scope of data exposure (also needs to be extensible). I know there are many technical and non-technical difficulties to do it. I am curious because service provider-specific ways to do it make apps hard to interoperate :-( Gerald On Sat, Mar 20, 2010 at 3:48 PM, Chris Messina chris.mess...@gmail.com wrote: Hi Gerald, Your question is a good one — and gets at some of the challenges inherent in user authorization models. Specifically: when a user grants authorization, how do you effectively scope access and communicate that to the user? Should you or the user need to later change the scope of authorization, how do you do so? However, the way that you've described the problem is actually accurate. In fact, OAuth says nothing about how much (or how little) access a user MUST grant on a per instance basis. The amount of access authorized is dependent on the policies of the service provider and the user's relationship with the service provider. Therefore, a single OAuth token could access as little as your full name, say, or as much as all of your account details. OAuth says nothing about the scope of a given authorization instance. So technically, there's nothing to stop OAuth from behaving as you've described. The problem has much more to do with providing a user experience that is 1) comprehensible and 2) not annoying. While many people have said that they would love to have granular access and control over who has access to their data, in practice we find that people tend to click through authorization screens without really reading them. Getting people to take more care in authorizing third party access to their data would be a great thing, but is, for better or worse, outside the scope of OAuth. Chris On Sat, Mar 20, 2010 at 10:58 AM, Gerald jen...@gmail.com wrote: Hi, all I have been following OAuth work for some time. Also I have developed some apps using OAuth. One problem I encountered often is granularity of access. In current spec, after a user accepts the access request from a third-party app, the app can access all of user's data in arbitrary way. It is helpful to allow users control 1) which portion of his/her data will be exposed to third-party apps 2) what operations are allowed (read? write? update? etc). I believe OAuth community must have considered this problem before. But it's not included in the spec. I wonder whether there has been serious discussions on this problem. Anyone can point me to some related resources/pages/threads? Thanks Gerald -- 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. -- Chris Messina Open Web Advocate, Google Personal: http://factoryjoe.com Follow me on Buzz: http://buzz.google.com/chrismessina ...or Twitter: http://twitter.com/chrismessina This email is: [ ] shareable [X] ask first [ ] private -- 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
Re: [oauth] Finer-grained access control in OAuth?
For what it's worth, the current UMA draft protocol (layered on WRAP for the moment) does propose a way for a client to express to the authorization server its desired scope of access, using a JSON format and presuming that the API has been documented in a resource-oriented way (resource loc-plus-method). This is all at a layer above WRAP/OAuth 2.0 at the moment, but if it has wider interest, that would be very good to know as we refine the details. More info is here: http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol (see step 2; the actual scope granted affects what may happen in step 3 as well, if the UMA host offloads token validation to the UMA authz manager) This was discussed on the OAuth IETF mailing list a bit, as well. Eve On 20 Mar 2010, at 1:13 PM, Zhenhua Guo wrote: Thanks for your explanation. Yes, I totally agree with you from the perspective of technology. Technically, service providers can come up with whatever policies about scope of authorization, allowed operations, etc. However, one drawback is that users may get confused when they access different services protected by OAuth because these service providers may use different UIs, different terms (I mean wording), etc. So sometimes the user may not get the context of the displayed OAuth authorization page. They need to spend some time (maybe not trivial) to figure out what the sentences on the page mean exactly (e.g. who can access his/her data, which portion data is accessed, what operations are allowed). I have used some OAuth services. Most of the time, the description on the OAuth authorization page is really simple so that I cannot exactly know what will happen after I click the grant access button. From the page I can only tell some app wants to access my data. Nothing more. I guess this may be a reason why users tend to click through the whole process without careful reading. What I described matches your idea perfectly - The problem has much more to do with providing a user experience that is 1) comprehensible and 2) not annoying. My question is whether there is any effort trying to come up with some kind of standardized terms/UIs/process flows to improve use experience of OAuth authorization process. Another questions is in protocol level (not UI level) whether OAuth community plans to come up with 1) basic standard data operations (read, write, etc. of course, service providers can extend this) 2) how to specify scope of data exposure (also needs to be extensible). I know there are many technical and non-technical difficulties to do it. I am curious because service provider-specific ways to do it make apps hard to interoperate :-( Gerald On Sat, Mar 20, 2010 at 3:48 PM, Chris Messina chris.mess...@gmail.com wrote: Hi Gerald, Your question is a good one — and gets at some of the challenges inherent in user authorization models. Specifically: when a user grants authorization, how do you effectively scope access and communicate that to the user? Should you or the user need to later change the scope of authorization, how do you do so? However, the way that you've described the problem is actually accurate. In fact, OAuth says nothing about how much (or how little) access a user MUST grant on a per instance basis. The amount of access authorized is dependent on the policies of the service provider and the user's relationship with the service provider. Therefore, a single OAuth token could access as little as your full name, say, or as much as all of your account details. OAuth says nothing about the scope of a given authorization instance. So technically, there's nothing to stop OAuth from behaving as you've described. The problem has much more to do with providing a user experience that is 1) comprehensible and 2) not annoying. While many people have said that they would love to have granular access and control over who has access to their data, in practice we find that people tend to click through authorization screens without really reading them. Getting people to take more care in authorizing third party access to their data would be a great thing, but is, for better or worse, outside the scope of OAuth. Chris On Sat, Mar 20, 2010 at 10:58 AM, Gerald jen...@gmail.com wrote: Hi, all I have been following OAuth work for some time. Also I have developed some apps using OAuth. One problem I encountered often is granularity of access. In current spec, after a user accepts the access request from a third-party app, the app can access all of user's data in arbitrary way. It is helpful to allow users control 1) which portion of his/her data will be exposed to third-party apps 2) what operations are allowed (read? write? update? etc). I believe OAuth community must have considered this problem before. But it's not included in the spec. I wonder whether there has been serious discussions on this problem.
