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.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
