Re: [OAUTH-WG] redirect uri validation (was: Issue 15, new client registration)

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:torsten@lodderstedt-
> online.de]
> Sent: Sunday, July 24, 2011 12:36 AM
> To: Eran Hammer-Lahav; [e-mail]
> Subject: redirect uri validation (was: Issue 15, new client registration)
> 
> Hi Eran,
> 
> let's move the discussion regarding redirect uri validation into another threat.
> 
> >Personally, given the clear direction the web is taking where
> >applications are moving off hosted servers to mobile devices and
> >in-browser software, I believe >that focusing OAuth 2.0 ability to
> >identify a client based on a secret is counterproductive.
> 
> funny you mention this. I was advocating in favor of native apps support in
> OAuth 2 since I joined this group :-) And I'm not saying secrets should be
> used to authenticate those apps, I never suggested that.
> 
> >This is why my last rewrite put much more weight on the redirection
> >URI and clarifying registration requirements.
> 
> I think redirect uri validation is especially ineffective for this client category.

It’s a big category. Hosted JS clients with https:// registered redirection URI provide pretty strong identification.

> The authz server can check the redirect uri of such a client. But it can only
> detect those malicious clients which are using another URI than the pre-
> registrered uri (most probably web-based clients). Clients using the correct
> URI are not neccessarily the legitimate clients. Why?
> Because native apps will most likely use URLs with custom URI schemes
> which are used to re-activate the app on the device through the local
> browser. So there is not a single "endpoint" such a URI is pointing to, but this
> URI is resovled relative to every device. So a malicious app on one device can
> perfectly use the redirect URI a legitmate client uses on another device and it
> will still receive the authz result.

I agree. One of my OSCON OAuth 2.0 slide shows this flow with the comment "Registered custom scheme URI (custom://) provides weak client identification".

However, native apps are much harder to use for a social engineering attack (compared to web apps) because the user has to install something proactively. This means showing the user the logo of the expected client should raise a red flag when it doesn't match the application being executed.

> >OAuth 1.0 was highly criticized for failing to address client identity
> >in public clients. I believe OAuth 2.0 offers a much better story,
> >within the boundaries >of what’s possible today.
> 
> Agreed. I think we must honestly discuss the value of client
> authentication/identification itself. I personally think it is over-emphazised
> right now. The strength of OAuth 2.0 is that it allows solutions where neither
> client nor resource server have access or do store end-user credentials.
> Client authentication is nice but not the main feature.

Do you have any specific suggestions not already mentioned on the list?

EHL