Harden default security

[bshaffer]

Harden default security

[bshaffer]

I agree with 2, but am on the fence about 1. Does the spec mention exact matches anywhere? We can supply a config flag to enforce exact matches, but use cases exist where fuzzy matching is safe and desirable.

[bojanz]

The relevant part of the spec is http://tools.ietf.org/html/rfc6749#section-3.1.2

The authorization server SHOULD require the client to provide the
complete redirection URI (the client MAY use the "state" request
parameter to achieve per-request customization). If requiring the
registration of the complete redirection URI is not possible, the
authorization server SHOULD require the registration of the URI
scheme, authority, and path (allowing the client to dynamically vary
only the query component of the redirection URI when requesting
authorization).
The authorization server MAY allow the client to register multiple
redirection endpoints.

http://tools.ietf.org/html/rfc6749#section-10.15 says

In addition, if the authorization server allows the client to register only part of the
redirection URI, an attacker can use an open redirector operated by
the client to construct a redirection URI that will pass the
authorization server validation but will send the authorization code
or access token to an endpoint under the control of the attacker.

So, maybe a flag that's on by default? Dunno

[bshaffer]

Thank you! Yes, that is certainly sufficient to make exact matching the default.

[bshaffer]

These changes have been made. @bojanz please review and reopen if you see something missing