Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri

Note sure I follow this Marius:

"What can happen is that exmple.com/back can pretend to be
example.com/back, but registration does not help in this case."

I believe it does help in this case, as the Authorization server can validate the registered redirect_uri vs. the requested redirect_uri.   Hence the server would not issue a token to exmple.com in this case.   Am I missing something?

-cmort

On 6/7/10 4:36 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote:

On Fri, Jun 4, 2010 at 9:49 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> The user agent flow indicates that the redirect_uri SHOULD be preregistered
> with the auth server for a given client.  I would like to suggest that the
> SHOULD here be changed to MUST.  Unless I'm missing something, without a
> preregistered redirect_uri any arbitrary client can obtain an access token
> under the pretense of being another client, and thereby perhaps altogether
> skip a user authorization prompt.
>
> As there will likely be a few popular client_id's in use, it will actually
> make it trivially easy to obtain elevated access to private user data as a
> rogue application.  This danger is unique to the user-agent flow because in
> this flow the client_secret is not required to obtain the access token,
> whereas it is for other flows.
>
> Thoughts?

Not sure registration buys you too much.

An arbitrary client cannot pretend being another client, client in
this case is the redirect_uri. It is up to the end user to trust this
redirect_uri.

For example, bad.example.com/back cannot pretend it is
good.example.com/back because the redirect with the access token will
go to good.example.com/back and not to bad.example.com/back.

What can happen is that exmple.com/back can pretend to be
example.com/back, but registration does not help in this case.

The only case where registration really helps is if example.com allows
people to create their own pages and as a result someone could create
a JavaScript client at example.com/pages/bad. Since you can have
several clients under the same domain, the user will be confused. In
this case if example.com registers its own redirect_uri no one else
under the same domain could potentially use one. But this is a
particular case, and up to example.com to enforce. Also, if
example.com wants to allow clients installed at different paths, then
again, registration does not help.

Marius

> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth