I think OAuth 2.0 (http://tools.ietf.org/html/draft-ietf-oauth-v2-10)
User Agent profile is not very secure. Please let me know where/if I'm
wrong.
Let us take a look at step C in Figure 5 :
Redirect URI with access token in fragment.
It's written everywhere that one should not really put
On Sun, Aug 1, 2010 at 10:59 AM, Oleg Gryb oleg_g...@yahoo.com wrote:
I think OAuth 2.0 (http://tools.ietf.org/html/draft-ietf-oauth-v2-10)
User Agent profile is not very secure. Please let me know where/if I'm
wrong.
Let us take a look at step C in Figure 5 :
Redirect URI with access token
Redirect URI below means HTTP response code 302, right? Will not browser
follow?
- Original Message
From: Marius Scurtescu mscurte...@google.com
To: Oleg Gryb o...@gryb.info
Cc: oauth@ietf.org
Sent: Sun, August 1, 2010 11:52:22 AM
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure
Does the redirect with fragment in URL without sending it to the
server have been tested with all main browsers ?
On Sun, Aug 1, 2010 at 9:14 PM, Oleg Gryb oleg_g...@yahoo.com wrote:
Redirect URI below means HTTP response code 302, right? Will not browser
follow?
- Original Message
Let me explain my qs a little bit. It's written in the very beginning of
section
1.4.2: typically implemented in a browser using a scripting language such as
JavaScript.
That phrase, step C and knowledge about how browser redirects are usually
implemented made me think that:
1. A server
On Sun, Aug 1, 2010 at 12:47 PM, Oleg Gryb oleg_g...@yahoo.com wrote:
Let me explain my qs a little bit. It's written in the very beginning of
section
1.4.2: typically implemented in a browser using a scripting language such
as
JavaScript.
That phrase, step C and knowledge about how
On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw bou...@gmail.com wrote:
Does the redirect with fragment in URL without sending it to the
server have been tested with all main browsers ?
AFAIK this is how all major browsers behave. Does anyone know
otherwise? Browsers that don't respect this?
Marius
I'll need to check if it's true for dynamic redirects that use Location header,
but right now I can provide an example where JavaScripts are used for redirects
in which case access token is send in a URL.
Let us assume that you've implemented an endpoint on your authz server as a JSP
that
Here is an example with Location header. I don't see URI with access token been
truncated. See Location header generated by JSP and actual redirect that
browser followed below.
red.jsp (Running on local Tomcat):
% String url = http://www.google.com#access_token=123;;
I'm not sure if you mean address as in handle, or address as in uniquely
label, but... UMA's first step involves a user-delegated introduction of a
resource server to an authorization server as a special kind of client of it,
using an OAuth2 web server flow with dynamic client registration as
David,
Yes, you're right, I've should have paid attention to the GET line, not to the
URL above. Browser honors fragment sent in Location, but it's not on the GET
line.
I've also enabled Tomcat access log and could not find the fragment there.
My apologies.
--- On Sun, 8/1/10, David
I've just verified Ruby and Perl's user agents as well: both worked as expected
- no fragments in the web log files. It adds confidence. Thanks to everyone who
has answered. The code that I've used is below:
use
12 matches
Mail list logo
