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

[Dick Hardt <[e-mail]>]

You are pointing out Marius point -- he wants to require registration. If the redirect_uri is not registered, the only party that can detect that it is the right URI is the user. The AS can only show the user the redirect_uri passed over.

-- Dick

On 2010-06-07, at 5:31 PM, Chuck Mortimore wrote:

> 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" <[e-mail]> wrote:
> 
> On Fri, Jun 4, 2010 at 9:49 PM, Andrew Arnott <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth