Behavior for clients without registered redirect_uris is not well defined

[Former user]

Section 3.2.1 of OpenIDConnect Standard states that the redirect_uri provided in the Authz request "MUST match one of the redirect_uris registered for the client_id in the OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specification. "

Dynamic Client Registration, Section 2.1 states that the redirect_uris parameter is "RECOMMENDED for Clients using the code flow with a query parameter encoded response. REQUIRED for Clients requesting implicit flow fragment encoded responses as defined in OAuth 2.0 [OAuth2.0]."

The behavior when a client is NOT using the Dynamic Registration spec, or IS using it but has not registered any URIs, is not well defined in OpenIDConnect Standard.

What should happen if a client IS using DynClientReg, but has not registered any URIs?

What should happen if a client is NOT using DynClientReg, and no URIs are pre-configured for that client?

Should either of these be error conditions, or should the request just be allowed through as long as the redirect_uri parameters on the AuthZ and Token requests match?

[Michael Jones]

The WG believes that we need to be more specific than OAuth was to avoid the problems described in the e-mail thread

[Michael Jones]

The working group's conclusion was that redirect_uris must always be registered and the redirect_uri must always exactly match one of the registered redirect_uris. Furthermore, per Google's usage, the redirect_uri must be sent in the token endpoint request. (It need not be sent in the authorization request if only one is registered. John to verify that this is consistent with Google's usage and/or the spec.)

[John Bradley]

Duplicate of #593.