[oauth] Re: RFC3986 vs. RFC2396 URL encoding.
David, Back when I was writing the OAuth-PHP library I also bumped into this issue. At least the OAuth spec clearly defines how to encode, and there are test cases supplied. You can check: http://www.marcworrell.com/article-2943-en.html For a discussion about the implications of RFC3986 usage in different languages. Greetings, Marc On 5 mei 2009, at 02:41, Zachary Voase wrote: Hi David, I found this to be an issue actually; in a shameless plug of my own OAuth client library for Python, ZOAuth [1], I found that functions like urllib.urlencode() were turning out URLs with '+' instead of the (expected) '%20'. This is due to the presence of two functions: urllib.quote() and urllib.quote_plus(); most of the urllib functions use the latter, which was giving me hell because I was getting signature errors from service providers and I couldn't understand why. I basically solved it by copying the most frequently used urllib functions straight from the stdlib, and rewriting them to use RFC3986 encoding instead. Maybe you'd like to take a look at ZOAuth if this turns out to be an issue for you. /plug Regards, Zack [1]: http://github.com/disturbyte/zoauth/ On May 4, 2:57 am, David W d...@botanicus.net wrote: Hi there, I see that OAuth 1.0 specifies RFC3986 URL encoding for parameters, but upon looking at the Python reference library I see that RFC2396 (aka. urllib.quote) encoding is used. Is this in error? The set of reserved characters differs in these specifications. Thanks, David. --~--~-~--~~~---~--~~ 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] OAuth linking problems
Dear list, I wanted to ask if any of you have already experienced the following problem: Configuring and make OAuth works fine and liboauth.so and liboauth.la are smoothly installed e.g. in /usr/local/lib but the compiler just won't link to it's methods, like in the following example: tzang...@tzangerl-desktop:~$ g++ `pkg-config --libs oauth` test.cpp /tmp/ccR4RD4H.o: In function `main': test.cpp:(.text+0x1e9): undefined reference to `oauth_sign_url(char const*, char**, OAuthMethod, char const*, char const*, char const*, char const*)' where pkg-config returns the following: tzang...@tzangerl-desktop:~$ pkg-config --libs oauth -Wl,-Bsymbolic-functions -L/usr/local/lib -loauth -lm -lssl -lcurl The libraries are all there: tzang...@tzangerl-desktop:~$ ls -l /usr/local/lib/liboauth* -rwxr-xr-x 1 root root 73574 2009-05-05 15:57 /usr/local/lib/ liboauth.a -rwxr-xr-x 1 root root 1075 2009-05-05 15:57 /usr/local/lib/ liboauth.la lrwxrwxrwx 1 root root17 2009-05-05 15:57 /usr/local/lib/ liboauth.so - liboauth.so.1.0.0 lrwxrwxrwx 1 root root17 2009-05-05 15:57 /usr/local/lib/ liboauth.so.1 - liboauth.so.1.0.0 -rwxr-xr-x 1 root root 67232 2009-05-05 15:57 /usr/local/lib/ liboauth.so.1.0.0 and the oauth_sign_url symbol is in the library: nm /usr/local/lib/liboauth.so ... 2ed0 T oauth_sign_url ... There aren't any libraries missing either, as ldd indicates. So maybe I am just stumbling over an idiotic error here, which I fail to see with my tunnel perspective or something is very strange. May anybody have a hint or a pointer for me concerning what I might be missing (wrong libtool version or any other compile-time-specific thing maybe?)? --~--~-~--~~~---~--~~ 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 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. On Tue, May 5, 2009 at 1:16 AM, Owen Evans owenmcev...@gmail.com wrote: 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: OAuth linking problems
Sorry that I didn't mention that I was referring to the C-library of
oauth [1], which btw could be included on the list at [2]. But back to
the problem, just in case anybody happens to experience the same.
I made a beginner's mistake (well, but then again C++ has so many
quirks that I can live with that): Since liboauth is a C-library, the C
++ compiler needs to now that what follows now is C-code, once it
attempts to link the respective parts.
Hence, one has to tell the C++ compiler already at the time of
inclusion of the library definition, that what follows is C-code by
writing:
extern C {
#include oauth.h
}
instead of just #include oauth.h.
Here goes another few wasted hours... :(
But thanks for providing that list and of-course, OAuth,
Thomas
[1] http://liboauth.sourceforge.net/
[2] http://oauth.net/code
On May 5, 4:37 pm, thomas thomas.zang...@freenet.de wrote:
Dear list,
I wanted to ask if any of you have already experienced the following
problem: Configuring and make OAuth works fine and liboauth.so and
liboauth.la are smoothly installed e.g. in /usr/local/lib but the
compiler just won't link to it's methods, like in the following
example:
tzang...@tzangerl-desktop:~$ g++ `pkg-config --libs oauth` test.cpp
/tmp/ccR4RD4H.o: In function `main':
test.cpp:(.text+0x1e9): undefined reference to `oauth_sign_url(char
const*, char**, OAuthMethod, char const*, char const*, char const*,
char const*)'
where pkg-config returns the following:
tzang...@tzangerl-desktop:~$ pkg-config --libs oauth
-Wl,-Bsymbolic-functions -L/usr/local/lib -loauth -lm -lssl -lcurl
The libraries are all there:
tzang...@tzangerl-desktop:~$ ls -l /usr/local/lib/liboauth*
-rwxr-xr-x 1 root root 73574 2009-05-05 15:57 /usr/local/lib/
liboauth.a
-rwxr-xr-x 1 root root 1075 2009-05-05 15:57 /usr/local/lib/
liboauth.la
lrwxrwxrwx 1 root root 17 2009-05-05 15:57 /usr/local/lib/
liboauth.so - liboauth.so.1.0.0
lrwxrwxrwx 1 root root 17 2009-05-05 15:57 /usr/local/lib/
liboauth.so.1 - liboauth.so.1.0.0
-rwxr-xr-x 1 root root 67232 2009-05-05 15:57 /usr/local/lib/
liboauth.so.1.0.0
and the oauth_sign_url symbol is in the library:
nm /usr/local/lib/liboauth.so
...
2ed0 T oauth_sign_url
...
There aren't any libraries missing either, as ldd indicates. So maybe
I am just stumbling over an idiotic error here, which I fail to see
with my tunnel perspective or something is very strange. May anybody
have a hint or a pointer for me concerning what I might be missing
(wrong libtool version or any other compile-time-specific thing
maybe?)?
--~--~-~--~~~---~--~~
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] OAuth Core 1.0 Rev A, Draft 2
Please review: http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/2/oauth-core-1_0a.html Change log: http://code.google.com/p/oauth/source/diff?spec=svn993old=992r=993format=unidiffpath=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml The changes are minimal: 1. Define 'oob' as out-of-band 2. Clarify that 'oob' is for any out-of-band configuration, not delivery of verification code 3. Minor language tweak 4. Correct reference to first step 5. Clarify that verification code should be displayed when no callback is configured, not just via the oauth_callback parameter Deadline for feedback is still May 8th. If you provided feedback to draft 1 which was not incorporated and still believe it should, please let me know. If no changes are needed by Friday, I will promote this to an implementer draft at which point developers will be encouraged to change their code. If no changes are identified by developers, we will declare this draft final 5/25. EHL --~--~-~--~~~---~--~~ 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: Clickjacking OAuth
On May 4, 9:14 pm, Josh Roesslein wrote: A simple way to block this attack would be to force the user to login each time before displaying the approval page (even if there is a SP session cookie). This way the attacker can not load the approval page in a frame. They would need the password to do so. This does impact the user experience a bit, but does solve the issue 100% unless I over looked something. That is a solution that I considered but dismissed because of the inconvenience. However after giving it some more thought the inconvenience is not that great. And given that the other solutions are not perfect, it is one that service providers should consider. I updated the Protection section of my blog post to include it. Stephen Sclafani --~--~-~--~~~---~--~~ 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 linking problems
Hi Thomas,
Sorry, I could not reply earlier.
Great that you found and posted the solution, already.
let me know if you encounter more issues..
robin
On May 5, 6:57 pm, thomas thomas.zang...@freenet.de wrote:
Sorry that I didn't mention that I was referring to the C-library of
oauth [1], which btw could be included on the list at [2]. But back to
the problem, just in case anybody happens to experience the same.
I made a beginner's mistake (well, but then again C++ has so many
quirks that I can live with that): Since liboauth is a C-library, the C
++ compiler needs to now that what follows now is C-code, once it
attempts to link the respective parts.
Hence, one has to tell the C++ compiler already at the time of
inclusion of the library definition, that what follows is C-code by
writing:
extern C {
#include oauth.h
}
instead of just #include oauth.h.
Here goes another few wasted hours... :(
But thanks for providing that list and of-course, OAuth,
Thomas
[1]http://liboauth.sourceforge.net/
[2]http://oauth.net/code
On May 5, 4:37 pm, thomas thomas.zang...@freenet.de wrote:
Dear list,
I wanted to ask if any of you have already experienced the following
problem: Configuring and make OAuth works fine and liboauth.so and
liboauth.la are smoothly installed e.g. in /usr/local/lib but the
compiler just won't link to it's methods, like in the following
example:
tzang...@tzangerl-desktop:~$ g++ `pkg-config --libs oauth` test.cpp
/tmp/ccR4RD4H.o: In function `main':
test.cpp:(.text+0x1e9): undefined reference to `oauth_sign_url(char
const*, char**, OAuthMethod, char const*, char const*, char const*,
char const*)'
where pkg-config returns the following:
tzang...@tzangerl-desktop:~$ pkg-config --libs oauth
-Wl,-Bsymbolic-functions -L/usr/local/lib -loauth -lm -lssl -lcurl
The libraries are all there:
tzang...@tzangerl-desktop:~$ ls -l /usr/local/lib/liboauth*
-rwxr-xr-x 1 root root 73574 2009-05-05 15:57 /usr/local/lib/
liboauth.a
-rwxr-xr-x 1 root root 1075 2009-05-05 15:57 /usr/local/lib/
liboauth.la
lrwxrwxrwx 1 root root 17 2009-05-05 15:57 /usr/local/lib/
liboauth.so - liboauth.so.1.0.0
lrwxrwxrwx 1 root root 17 2009-05-05 15:57 /usr/local/lib/
liboauth.so.1 - liboauth.so.1.0.0
-rwxr-xr-x 1 root root 67232 2009-05-05 15:57 /usr/local/lib/
liboauth.so.1.0.0
and the oauth_sign_url symbol is in the library:
nm /usr/local/lib/liboauth.so
...
2ed0 T oauth_sign_url
...
There aren't any libraries missing either, as ldd indicates. So maybe
I am just stumbling over an idiotic error here, which I fail to see
with my tunnel perspective or something is very strange. May anybody
have a hint or a pointer for me concerning what I might be missing
(wrong libtool version or any other compile-time-specific thing
maybe?)?
--~--~-~--~~~---~--~~
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 Tue, May 5, 2009 at 1:20 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: Please review: http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/2/oauth-core-1_0a.html Change log: http://code.google.com/p/oauth/source/diff?spec=svn993old=992r=993format=unidiffpath=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml The changes are minimal: 1. Define 'oob' as out-of-band 2. Clarify that 'oob' is for any out-of-band configuration, not delivery of verification code 3. Minor language tweak 4. Correct reference to first step 5. Clarify that verification code should be displayed when no callback is configured, not just via the oauth_callback parameter Deadline for feedback is still May 8th. If you provided feedback to draft 1 which was not incorporated and still believe it should, please let me know. In Section 6.3.2, there is still language that assumes that the SP has two verification codes at that point: - The verification code received from the Consumer is identical to the verification code provided to the User via the redirection or manually. I believe that presupposes/dictates a particular implementation, which is not what we should be doing in the spec. Proposed change: The verification code matches the Request Token. Dirk. If no changes are needed by Friday, I will promote this to an implementer draft at which point developers will be encouraged to change their code. If no changes are identified by developers, we will declare this draft final 5/25. EHL --~--~-~--~~~---~--~~ 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
Line 837: to indicates s.b. to indicate Section 6.2: Consumers that need to maintain compatibility with both 1.0 and 1.0a service providers are going to send oauth_callback on this step. We should be explicit about how to handle backwards compatibility here or we are going to end up with incompatible implementations. Specifically: - if the consumer sent the oauth_callback on the RT step, the oauth_callback on the authorization URL should be ignored. - if the consumer did not send the oauth_callback on the RT step, the oauth_callback may be accepted if the SP wants to be compatible with OAuth 1.0 Alternatively, we should give consumers a way to detect SP version, by having the SP return oauth_callback_accepted=1 in the request token response. I think this might be a better answer. 6.2.3 non-guessable should be unguessable If the value of the oauth_callback parameter provided by the Consumer in the Consumer Obtains a Request Token (Consumer Obtains a Request Token) step was not oob (case sensitive), or a callback URL has been established by other means the Service Provider uses it to constructs an HTTP GET request, and directs the User's web browser to that URL with the following parameters added: ... I know what you mean, and I'm having a lot of trouble parsing this sentence. Can you break this into smaller pieces? If no callback URL was provided, the Service Provider MUST display the value of the verification code to the User and instruct the User to manually inform the Consumer that authorization has completed and provide the Consumer with the verification code. Same here, this sentence has too many clauses for easy comprehension. Appendix A.2: this does not demonstrate how to avoid an XSRF attack on the callback URL. Maybe add xsrf=some-gibberish here? On Tue, May 5, 2009 at 1:20 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Please review: http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/2/oauth-core-1_0a.html Change log: http://code.google.com/p/oauth/source/diff?spec=svn993old=992r=993format=unidiffpath=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml The changes are minimal: 1. Define 'oob' as out-of-band 2. Clarify that 'oob' is for any out-of-band configuration, not delivery of verification code 3. Minor language tweak 4. Correct reference to first step 5. Clarify that verification code should be displayed when no callback is configured, not just via the oauth_callback parameter Deadline for feedback is still May 8th. If you provided feedback to draft 1 which was not incorporated and still believe it should, please let me know. If no changes are needed by Friday, I will promote this to an implementer draft at which point developers will be encouraged to change their code. If no changes are identified by developers, we will declare this draft final 5/25. EHL --~--~-~--~~~---~--~~ 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] Confirm callback when getting access token
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.commailto: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
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. The request token can be stored in a cookie or some other parameter that provides XSRF protection vis-a-vis the callback URL. This allows the consumer to remain stateless by doing the right thing. 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. This does not have to change. The SP can encode the callback URL in the request token itself. 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. There is no need for such radical changes as described above. 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. Possibly. But we would have to think carefully about that. 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 -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ 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
The attack fails. On Tue, May 5, 2009 at 6:08 PM, Owen Evans owenmcev...@gmail.com wrote: 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. At this point the SP saves the malicious callback URL associated with the approved request token. 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 Original consumer sends the correct callback URL along with their access token request. SP compares callback from approval step with callback from access token step. They don't match, so the access token request fails. I'm not convinced James' proposal is secure, but the attack Owen described doesn't work. --~--~-~--~~~---~--~~ 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 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.commailto: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: 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: Confirm callback when getting access token
James, you made the best argument (in my view) of why we should stick with the existing proposal, namely that the easiest way to preserve statelessness is to implement a measure that results in XSRF protection side effects. On Tue, May 5, 2009 at 6:21 PM, Owen Evans owenmcev...@gmail.com wrote: 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 -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ 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
AFAICT there is no difference in the amount of state consumers need to maintain between OAuth 1.0, the signed callback proposal, and the approval URL verification proposal. There may be some good reason to prefer either signed callbacks or approval URL verification, but I don't think consumer state is such a reason. Unless I'm missing something pretty major: is it true that consumers need to maintain more state for the signed callback proposal? Why? On Tue, May 5, 2009 at 6:26 PM, Breno de Medeiros br...@google.com wrote: James, you made the best argument (in my view) of why we should stick with the existing proposal, namely that the easiest way to preserve statelessness is to implement a measure that results in XSRF protection side effects. On Tue, May 5, 2009 at 6:21 PM, Owen Evans owenmcev...@gmail.com wrote: 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 -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ 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
Good point. This alternate solution is less backward compatible. On May 5, 2009 7:15 PM, Josh Roesslein jroessl...@gmail.com wrote: One issue that arises is now the SP has no way to tell if we are using 1.0 old flow or the new flow.The SP will not know which one is being used until the consumer asks for the access token. So how will we know if the callback should use the old flow's format or the new flow w/ verifier? We would either have to increment the wire version OR the SP would have to use different end points for the two flows. example: http://www.test.com/oauth/1.0a OR 1.0/request On Tue, May 5, 2009 at 9:06 PM, Manger, James H james.h.man...@team.telstra.com wrote: [I sa... --~--~-~--~~~---~--~~ 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
One way around the issue of incrementing oauth_version is for the SP to see it as a minimum required version for this endpoint rather than enforcing one version requirement across all endpoints. By allowing for different minimum required versions for each endpoints, we can maintain backward compatibility while still being able to increment the oauth_version. The SP can decide which oauth version to support for each endpoint. For the session fixation fix SPs can continue allowing 1.0 versions on resource requests since we are not chaging this part of the spec. Two legged consumers would not be broken and the SP can tell which flow is being used when it might not be obvious. I was going suggest this in a seperate thread, but since this idea is blocked on this issue, I thought it would be relevent to suggest here. On Tue, May 5, 2009 at 9:29 PM, Breno de Medeiros br...@google.com wrote: Good point. This alternate solution is less backward compatible. On May 5, 2009 7:15 PM, Josh Roesslein jroessl...@gmail.com wrote: One issue that arises is now the SP has no way to tell if we are using 1.0 old flow or the new flow.The SP will not know which one is being used until the consumer asks for the access token. So how will we know if the callback should use the old flow's format or the new flow w/ verifier? We would either have to increment the wire version OR the SP would have to use different end points for the two flows. example: http://www.test.com/oauth/1.0a OR 1.0/request On Tue, May 5, 2009 at 9:06 PM, Manger, James H james.h.man...@team.telstra.com wrote: [I sa... --~--~-~--~~~---~--~~ 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 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. --~--~-~--~~~---~--~~ 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
On Tue, May 5, 2009 at 5:54 PM, Manger, James H james.h.man...@team.telstra.com wrote: 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. One interesting aspect of this proposal is that it requires consumers to reconstruct the exact callback URL used by the service provider. This is certainly possible, but it can be tricky. For example: - what if there is an SSL accelerator that terminates the HTTPS channel and forwards HTTP? - what if the consumer is load balanced in such a way that the host header changes or the port changes? - what if the consumer uses software that automatically redirects users to include additional query parameters? - what if the consumer uses high-level web app development tools that abstract away notions of URLs and parameters? It's possible to cope with all of those things, but it requires different code in different environments. It takes us farther away from protocols and libraries that just work. OpenID RPs are required to verify that the URL in the authn response matches the receiving URL, but the requirements there are less strict. The RP is able to ignore things like protocol or port or query if they know they are irrelevant (or tricky) in the RPs environment. We wouldn't have that flexibility with OAuth, because the consumer has to to send the URL to the SP for verification. if the consumer screws it up, the protocol fails. --~--~-~--~~~---~--~~ 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: Confirm callback when getting access token
[Breno said] The request token can be stored in a cookie or some other parameter that provides XSRF protection vis-a-vis the callback URL. This allows the consumer to remain stateless by doing the right thing. James, you made the best argument (in my view) of why we should stick with the existing proposal, namely that the easiest way to preserve statelessness is to implement a measure that results in XSRF protection side effects. This is a curious side-effect -- but not a great basis for protocol design. Only consumer apps that take the effort to be stateless get CSRF protection. It requires clients to support cookies. It assumes other CSRF defences cannot be sufficient (eg using Referer or Origin HTTP headers). I would prefer to fix OAuth security issue 2009-1 without unnecessarily preventing state-management options that previously worked, and without requiring cookies where they were not previously necessary. Separately, we should write advice for all OAuth consumers about implementing CSRF defences. I assume the issue is Login CSRF -- where a victim is logged in to the consumer as the attacker [in OAuth, a victim is using a consumer that is accessing a service provider on behalf of an attacker]. 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. There is no need for such radical changes as described above. Are you sure that the alternative ways to implement statelessness (other than encoding state into the callback) are viable in all situations, and will remain so in the future? Even if that was true, do we have to force consumers to switch how they implement statelessness? -- CSRF = XSRF = cross-site request forgery --~--~-~--~~~---~--~~ 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: Clickjacking OAuth
Yahoo always requires the user to enter their password (even if the user is already signed into Yahoo) before issuing persistent credentials. The intent is to verify that the user is actually sitting in front of the computer before issuing a persistent credential, to protect against the case where the attacker is trying to backdoor a victim's account, when the victim left their computer unattended, or forgot to logout. A nice side effect of requiring password verifcation is that a potential clickjacker would need to phish the user before clickjacking the OAuth permissions screen... Allen Josh Roesslein wrote: A simple way to block this attack would be to force the user to login each time before displaying the approval page (even if there is a SP session cookie). This way the attacker can not load the approval page in a frame. They would need the password to do so. This does impact the user experience a bit, but does solve the issue 100% unless I over looked something. On Mon, May 4, 2009 at 7:43 PM, Stephen Sclafani ssclaf...@gmail.com mailto:ssclaf...@gmail.com wrote: Allen, You are correct about the security attribute being able to disable frame busting scripts in IE. IE8 supports a X-Frame-Options HTTP response header which can be used by a developer to deny their approval page from rendering in a frame. However IE8 is not currently widely used. Even requiring that javascript be enabled is not a perfect solution. In my conversation with Google's security team they informed me that they were going to add frame busting javascript (which they have done) and possibly add the X-Frame-Options header. I think that this is the best a service provider can hope to do at this point. There really is no 100% solution. Stephen Sclafani On May 4, 4:15 pm, Allen Tom a...@yahoo-inc.com mailto:a...@yahoo-inc.com wrote: Hi Stephen, Thanks for pointing this out. It might not be sufficient to deploy only Framebusting JS on the approval screens, as the attacker can disable JS for the iframe in IE by setting the security attribute to restricted http://msdn.microsoft.com/en-us/library/ms534622(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms534622%28VS.85%29.aspx SPs may need to deploy Framebusting JS AND require that JS is enabled for users to approve the Access Token, otherwise the attacker could embed the approval screen in an iframe with JS disabled. Allen Stephen Sclafani wrote: There has been much discussion over the session fixation vulnerability since it was announced publicly. There is another issue that is not unique to OAuth but one that I believe poses an equal if not more serious threat to service providers. That issue is clickjacking. For those unfamiliar with clickjacking, it is when a visitor to a web page is tricked into clicking on an element that they believe to be harmless when in reality they are clicking on an element on a different website that exposes protected data or grants an attacker access. A malicious consumer developer can use a clickjacking attack against a vulnerable service provider's approval page to trick users into granting their application access. Current service providers have been notified. Google, Yahoo and Twitter have already deployed protection. I have written a blog post that goes into greater detail on the threat which can be read here: http://stephensclafani.com/2009/05/04/clickjacking-oauth/ Stephen Sclafani --~--~-~--~~~---~--~~ 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
Brian, A consumer app will have a function to create a callback URI as a string given a few parameters (request token secret, other state). It simply calls this function twice: once before sending the user to the authorization URI; and once before obtaining an access token. A consumer does not have to reconstruct the scheme/host/port/path-prefix components solely based on the user's request to the callback. I would guess the callback URI (or at least a template for a callback URI, with a few placeholders for specific items) would be a configuration parameter to most OAuth libraries -- precisely to allow a person to provide the right address when there are SSL accelerators, load balancers, auto-redirects, DNS tricks etc that the library cannot see. The same configured callback URI template is used at both steps. It is possible these issues could occasionally trip-up a consumer, but that is not a good reason to sacrifice more fundamental architectural options (eg state management). James Manger james.h.man...@team.telstra.com Identity and security team — Chief Technology Office — Telstra -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Wednesday, 6 May 2009 2:29 PM To: oauth@googlegroups.com Subject: [oauth] Re: Confirm callback when getting access token On Tue, May 5, 2009 at 5:54 PM, Manger, James H james.h.man...@team.telstra.com wrote: 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. One interesting aspect of this proposal is that it requires consumers to reconstruct the exact callback URL used by the service provider. This is certainly possible, but it can be tricky. For example: - what if there is an SSL accelerator that terminates the HTTPS channel and forwards HTTP? - what if the consumer is load balanced in such a way that the host header changes or the port changes? - what if the consumer uses software that automatically redirects users to include additional query parameters? - what if the consumer uses high-level web app development tools that abstract away notions of URLs and parameters? It's possible to cope with all of those things, but it requires different code in different environments. It takes us farther away from protocols and libraries that just work. OpenID RPs are required to verify that the URL in the authn response matches the receiving URL, but the requirements there are less strict. The RP is able to ignore things like protocol or port or query if they know they are irrelevant (or tricky) in the RPs environment. We wouldn't have that flexibility with OAuth, because the consumer has to to send the URL to the SP for verification. if the consumer screws it up, the protocol fails. --~--~-~--~~~---~--~~ 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: Clickjacking OAuth
I thought about this solution some more and one issue that came to mind, which is actually noted in the OAuth spec, is that by conditioning users to enter their credentials each time they are redirected from a Consumer site you run the risk of increasing the potential of phishing attacks. Something to consider. Stephen Sclafani On May 6, 12:45 am, Allen Tom a...@yahoo-inc.com wrote: Yahoo always requires the user to enter their password (even if the user is already signed into Yahoo) before issuing persistent credentials. The intent is to verify that the user is actually sitting in front of the computer before issuing a persistent credential, to protect against the case where the attacker is trying to backdoor a victim's account, when the victim left their computer unattended, or forgot to logout. A nice side effect of requiring password verifcation is that a potential clickjacker would need to phish the user before clickjacking the OAuth permissions screen... Allen Josh Roesslein wrote: A simple way to block this attack would be to force the user to login each time before displaying the approval page (even if there is a SP session cookie). This way the attacker can not load the approval page in a frame. They would need the password to do so. This does impact the user experience a bit, but does solve the issue 100% unless I over looked something. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
