[OAUTH-WG] Redirection URI

[Anthony Nadalin <[e-mail]>]

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?

                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.

                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?
                                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?
                                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.

                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.