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

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 24 Jul 2011 00:46:00 -0700

> -----Original Message-----
> From: [email-masked] [mailto:torsten@lodderstedt-
> online.de]
> Sent: Sunday, July 24, 2011 12:36 AM
> To: Eran Hammer-Lahav; [email-masked]
> 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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 25 Jul 2011 13:42:02 -0400

Hi Eran,

>>> within the boundaries>of what’s possible today.

I would suggest to mention that while an invalid redirect_uri indicates 
a counterfeit clients a valid redirect does not prove the calling 
client's identity.

regards,
Torsten.

> EHL
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth