There are only certain instances where we would use the redirect uri in an error state. If the client issues an invalid, missing, or mismatching redirect uri, we do not use it. Similarly if the client ID is missing or invalid, we again ignore the redirect URI. This is a security precaution.

If you know of any specific instances where you believe we are not adhering to the spec, please let me know and I will reopen this ticket. Thanks for getting in touch.

If the client issues an invalid, missing, or mismatching redirect uri, we do not use it. Similarly if the client ID is missing or invalid, we again ignore the redirect URI. This is a security precaution.

That is correct but this library doesn't redirect in some cases even when that's not true.

If you know of any specific instances where you believe we are not adhering to the spec, please let me know and I will reopen this ticket. Thanks for getting in touch.

That's why I created this issue, because there are such cases, which can be seen by looking at code.

Examples I noticed

• When is_confidential=false GET /authorize?response_type=code&client_id=valid&redirect_uri=https://example.com/valid_uri (no code_challenge)
• GET /authorize?response_type=invalid&client_id=valid&redirect_uri=https://example.com/valid_uri (invalid response_type)

Maybe there's others but these 2 I just checked.

Based from that article, it doesn't follow this

If one or more parameters are invalid, such as a required value is missing, or the response_type parameter is wrong, the server will redirect to the redirect URL and include query string parameters describing the problem.

Thanks. I will take a look at this over the weekend.

Confirmed as an issue for at least the first scenario. Needs resolving.