Re: [OAUTH-WG] Redirection URI

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

I don't see any below justifying making changes. Comments inline.

From: Anthony Nadalin <[e-mail]<mailto:[e-mail]>>
Date: Thu, 11 Aug 2011 09:44:54 -0700
To: "OAuth WG ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>
Subject: [OAUTH-WG] Redirection URI

Section 3.1.2 explicitly states that the redirection endpoint URI MUST be an absolute URI. But that means that the URI could be potentially of any scheme. This is probably intentional since there are scenarios where a native client will want to register a custom scheme as the call back URI.

                But how can that ever be considered secure? Any app could potentially register a scheme with itself as the handler in the OS. Are we really in a position to state that ALL OS environments in ALL cases will only allow for the registration of new URI schemes in a completely secure way? I can't help but wonder if that isn't going too far and endangering users? Shouldn't we require that the redirect URI MUST always be a HTTPS URI and that native clients will need to have access to a browser? If we don't then how can we really be sure that a custom scheme is associated with the application we think it's associated with?


First, we already reached consensus not to require HTTPS for the redirection URI. The language is SHOULD use TLS when the redirection URI is sent over the network.

Second, the spec doesn't offer anything in terms of validating ownership of any redirection URI. There is nothing to prove that a client is in control of an HTTP URI as well. I expect custom schemes to require special relationship with the authorization server, and that most companies will either not support it, or require a human verification as a step. At the same time, there is nothing to prevent a native application from messing with existing scheme registrations, including HTTP.

Either way, custom schemes are really outside the scope of this working group because they are actually a violation of IETF protocols which require registration.

                If we are going to allow for custom schemes then fun issues come up. Let's say that an authorization server receives a request from an implicit client with a redirection URI value of foo:privatescheme:bar. Let's further say that the authorization server has an implicit client registered with it whose URI is foo:privatescheme:%62%61%72. What should the authorization server do?

                Should it:
                                A) Reject the request because the submitted redirection URI doesn't match exactly with the registered URI?
                                B) Accept the request because, if one applies URL decoding, it is identical to the registered URI but send back the response with the registered value (e.g. with :bar at the end)?
                                C) Same as B except send back the response with the same value as specified in redirect uri parameter in the request?

                Any of the above is legal according to the new or proposed language. But that clearly can't be right. After all, the host OS which allowed the client to register the "foo" scheme may not see foo:privatescheme:bar and foo:privatescheme:%62%61%72 as the same. So if a legitimate app was using the %62%61%72 value then B would cause an error since the response would be wrong and C would be right. But if the value is part of an attack then B would be right and C would be wrong. Since there is no way for the authorization server to know ahead of time what OS might be in use and what behavior it might have  I think we have to define that the correct behavior as "A".

               The agreement on how to compare redirection URIs is NOT a private agreement between the client and authorization server. It's a public agreement. The whole point of OAuth is to allow any client and any authorization server to interoperate. But as I show above if the client's assumptions about how the redirect URI is processed and the server's assumptions aren't the same then security breaks. Therefore the standard MUST define what the expected behavior is.


How is this any different from two clients using the same HTTP URI? I believe this is vendor specific. I can imagine use cases for allowing multiple clients to use the same redirection URI, especially when using localhost or other special case destinations. Also, URI comparison is scheme-specific which makes it impossible for verification and comparison by the server for custom schemes made up by the client.

                So we have to answer a couple of questions:

                                Question #1 - How should the server compare a submitted redirection URI to one it has registered if the server doesn't recognize the URI scheme?

It can't. URI comparison is scheme-specific. It should probably not allow registration of custom schemes without some additional trust which is beyond the scope.

                                Question #2 - OAuth in section 3.1.2 explicitly states that the redirection URI can contain a query component. Does that override the registered value? In other words if the registered value was foo:privatescheme:bar and the received value is foo:privatescheme:bar?foo=blah, do the two match?

That depends on how the server opts to perform its comparison. This is described in 3.1.2.3. I can see a general question about conflict between a query in both the registered and dynamic values not matching, but this is more of a bad server implementation than anything. The server should force one model (full URI registration or scheme, authority, and path components registration).

                                Question #3 - If a recognized URL scheme is used then what rules apply? And how can we be sure that both the client and the authorization server are using the same rules? Because, if they aren't, then, well, Dave Thaler's paper nicely outlines the consequences. This is especially the case if the redirection URI is pointing to a multi-tenant server where getting the URI 'wrong' means sending the response to the wrong place.


Again, this is a general issue with redirections. I believe the right way to address this is via future profiles of the protocol, based on actual deployment experience. We have failed over two years to reach consensus on even a basic set of required comparison rules. Too late to reopen that now, but if you have a proposal, publishing a profile would be very helpful.

                Propose that the only way to handle all of these rather nasty issues is by mandating that section 6.2.1 of RFC 3986 MUST be used by the authorization server when determining if a submitted redirection URI matches a registered value. This explicitly precludes the use of 'prefix' matching and it explicitly precludes having extra query parameters. If the client needs to encode state information than it can use the dedicated state variable. This is the simplest possible approach and therefore the one least likely to be screwed up by authorization servers and therefore least likely to introduce security holes. Please note that this proposal requires changes in multiple places in the spec, including but possibly not limited to sections 3.1.2, 3.1.2.2 and 3.1.2.3.


-1. OAuth 2.0 is an extremely extensible framework which will be profiled by every implementation. I'm hoping for industry best practices to emerge but beyond that, we are not likely to agree on this. I find 3986 6.2.1 to be perfectly acceptable for comparing two absolute HTTP(S) URIs, but it will fail when allowing partial registration or custom URI schemes.

We can recommend string comparison but that's as far as we can go at this point. If the WG suddenly endorses making such a dramatic change, I will not argue against it, but it is far too late IMO.

EHL