I struggled w/ this conflict as well during implementation since we also tie the redirection URI to client identity. However, URI preregistration is not required by the spec (3.1.1, paragraph 3, so, if a provider's redirect_uri validation is not dependent on client_id (be it a subset of URIs, or all URIs) then the invalid_client error is possible.
In practice, however, invalid_client will likely be an unlikely error. Perhaps the spec could make this more obvious by noting that invalid_client should not be returned by providers who require pre-registered redirection URIs. skylar On Feb 5, 2011, at 9:33 AM, Rasmus Lerdorf wrote: > In "4.1.2.1. Error Response" it says: > > If the resource owner denies the access request or if the request > fails for reasons other than a missing or invalid redirection URI, > the authorization server informs the client by adding the following > parameters to the query component of the redirection URI using the > "application/x-www-form-urlencoded" format: > > and then in the error section we have: > > invalid_client > The client identifier provided is invalid. > > Since the redirect URI is tied to a client's identity, we can't have an > invalid client identity and a valid redirect URI at the same time. > > In think the first part of 4.1.2.1 which currently says: > > If the request fails due to a missing, invalid, or mismatching > redirection URI, the authorization server SHOULD inform the resource > owner of the error, and MUST NOT redirect the user-agent to the > invalid redirection URI. > > should say: > > If the request fails due to a missing or invalid client identifier, > or due to a missing, invalid or mismatching redirect URI, the > authorization server SHOULD inform the resource owner of the error, > and MUST NOT redirect the user-agent to the invalid redirection URI. > > and the invalid_client error code should be removed from the list of > errors below. > > And a minor typo at the end of 4.1.2: > > "The authorization server should document the size of any value is > issues." > > -Rasmus > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
