I don't see any below justifying making changes. Comments inline.
From: Anthony Nadalin <[email protected]<mailto:[email protected]>>
Date: Thu, 11 Aug 2011 09:44:54 -0700
To: "OAuth WG ([email protected]<mailto:[email protected]>)"
<[email protected]<mailto:[email protected]>>
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
