Making redirect_uri required in client authentication requests to match OIDC specification

[funelie]

Hi, We are trying to get the OpenID certification for our identity manager, and one of the tests registers a client with two redirect_uri, and then makes a request with no redirect_uri in it. OpenID Certification expects the app to return an error to this request, but our app doesn't return an error, it redirects back to one of the redirect_uri that was registered before instead, causing the certification test to fail.

After investigation, it seems that Authlib checks if the request has redirect_uri it it, and if not, sets a default one : redirect_uri = client.get_default_redirect_uri() in AuthorizationEndpointMixin. This prevents the error OIDC expects to happen.

https://github.com/lepture/authlib/blob/4eafdc21891e78361f478479efe109ff0fb2f661/authlib/oauth2/rfc6749/grants/base.py#L132-L146

https://github.com/lepture/authlib/blob/4eafdc21891e78361f478479efe109ff0fb2f661/authlib/oauth2/rfc6749/models.py#L33-L42

And it seems that indeed, OIDC specification and OAuth2 specification do not match on this matter (redirect_uri is required in oidc, and is optional in OAuth2).

OIDC

redirect_uri REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). When using this flow, the Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http Redirection URIs in this case. Also, if the Client is a native application, it MAY use the http scheme with localhost or the IP loopback literals 127.0.0.1 or [::1] as the hostname. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application.

OAuth2

redirect_uri OPTIONAL. As described in Section 3.1.2.

Could this be fixed ?

Thanks !