I think that is probably reasonable advice.
Presenting a dialog to the user also has the beneficial side effect of removing
the original referrer from being seen by the party hosting the redirect_uri.
It is allowing dynamic parameters to be passed in the referrer that is the
largest security
hi again *,
after thinking a bit further IMHO an alternative for the untrusted clients can
also be to always present the consent screen (at least once) before any
redirect.
Namely all providers I have seen show the consent screen if all the request
parameters are correct and if the user accepts
thanks Phil for pointing the sections out but reading them I still think the
case I brought up is still a different one :)
On Sep 3, 2014, at 9:49 PM, Phil Hunt wrote:
> ooops,, that 6819 not 6810
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Sep 3, 2
hi Takahiko
On Sep 3, 2014, at 9:33 PM, Takahiko Kawasaki
mailto:daru...@gmail.com>> wrote:
I think the point is that the registered redirect URI is evil, meaning that the
person who registered the client application is evil. I don't think the spec
can take any countermeasure against this case
ooops,, that 6819 not 6810
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Sep 3, 2014, at 12:47 PM, Phil Hunt wrote:
> in RFC6810, see section 3.5 and 4.1.5.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Sep 3, 2014, at 12:36 P
in RFC6810, see section 3.5 and 4.1.5.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Sep 3, 2014, at 12:36 PM, Antonio Sanso wrote:
> hi Phil,
> can you point out the relative paragraph that covers this specific case in
> RFC6819?
> On Sep 3, 2014, at 9:23 PM, Phil Hunt
One improvement we made in dyn reg was the introduction of software statements.
This can be used to force all mobile clients claiming to be a particular client
to register the same redirect uri.
This closes the door on a large number of cases.
Phil
> On Sep 3, 2014, at 12:33, Takahiko Kawasa
hi Phil,
can you point out the relative paragraph that covers this specific case in
RFC6819?
On Sep 3, 2014, at 9:23 PM, Phil Hunt wrote:
> I do not believe this is a flaw specific to 6749. The flaw if any is within
> HTTP itself (RFC7230). Covert redirect is a well known problem. There are
>
I think the point is that the registered redirect URI is evil, meaning that
the person who registered the client application is evil. I don't think the
spec can take any countermeasure against this case.
If the registered redirect URI is evil, the issue happens even in the case
where the scope is
I do not believe this is a flaw specific to 6749. The flaw if any is within
HTTP itself (RFC7230). Covert redirect is a well known problem. There are
extensive recommendations that prevent this covered in 6749 and 6819.
There is no protocol fix that OAuth can make since it is a trait or feature
fine, you're talking security considerations about untrusted clients;
that's a different use case than the protocol flaw reason why Google
would not do rfc6749 as written
Hans.
On 9/3/14, 7:52 PM, John Bradley wrote:
I agree that the error case where there is no UI is the problem, as it can b
Well,
I do not know if this is only dynamic registration...
let’s talk about real use cases, namely e.g. Google , Facebook , etc.. is that
dynamic client registration? I do not know… :)
Said that what the other guys think? :)
Would this deserve some “spec adjustment” ? I mean there is a reason i
I agree that the error case where there is no UI is the problem, as it can be
used inside a Iframe.
However error responses are generally useful.
OAuth core is silent on how redirect_uri are registered and if they are
verified.
Dynamic registration should warn about OAuth errors to redire
On 9/3/14, 7:14 PM, Antonio Sanso wrote:
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote:
Is your concern clients that were registered using dynamic client registration?
yes
I think your issue is then with the trust model of dynamic client
registration; that is left out of scope of the d
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote:
> Is your concern clients that were registered using dynamic client
> registration?
yes
>
> Otherwise the positive case is returning a response to a valid URL that
> belongs to a client that was registered explicitly by the resource owner
we
Is your concern clients that were registered using dynamic client
registration?
Otherwise the positive case is returning a response to a valid URL that
belongs to a client that was registered explicitly by the resource owner
and the negative case is returning an error to that same URL.
I fai
On Sep 3, 2014, at 6:51 PM, Hans Zandbelt
mailto:hzandb...@pingidentity.com>> wrote:
Let me try and approach this from a different angle: why would you call it an
open redirect when an invalid scope is provided and call it correct protocol
behavior (hopefully) when a valid scope is provided?
Let me try and approach this from a different angle: why would you call
it an open redirect when an invalid scope is provided and call it
correct protocol behavior (hopefully) when a valid scope is provided?
Hans.
On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, J
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley
mailto:ve7...@ve7jtb.com>> wrote:
In the example the redirect_uri is vlid for the attacker.
The issue is that the AS may be allowing client registrations with arbitrary
redirect_uri.
In the spec it is unspecified how a AS validates that a clien
On Sep 3, 2014, at 6:10 PM, Bill Burke
mailto:bbu...@redhat.com>> wrote:
I don't understand. The redirect uri has to be valid in order for a redirect
to happen. The spec explicitly states this.
the redirect uri is indeed valid. The wrong parameter is the scope.
So if the attacker is the per
In the example the redirect_uri is vlid for the attacker.
The issue is that the AS may be allowing client registrations with arbitrary
redirect_uri.
In the spec it is unspecified how a AS validates that a client controls the
redirect_uri it is registering.
I think that if anything it may be th
I don't understand. The redirect uri has to be valid in order for a
redirect to happen. The spec explicitly states this.
On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,
IMHO providers that strictly follow rfc6749 are vulnerable to open redirect.
Let me explain, reading [0]
If the request f
hi *,
IMHO providers that strictly follow rfc6749 are vulnerable to open redirect.
Let me explain, reading [0]
If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Review of draft-ietf-oauth-spop-00
Gentleman, here are some notes on the OAuth SPOP Draft.
Review Summary
A few grammar errors, no major flaws, some suggestions that could
possibly make some passages clearer. Some questions as well.
Also, providi
24 matches
Mail list logo
