[oleks9o6]

Description

Adds IdentityServerOptions.StrictAuthorizeErrorResponses, off by default. When it's on, the authorize endpoint sends an error back to the client's redirect URI whenever the redirect URI and response mode have already been validated, as RFC 6749 section 4.1.2.1 describes, instead of showing the error page. With the option off, behaviour is unchanged.

What that means for the codes in the issue:

• Reach the client: invalid_request and unauthorized_client from the checks that run after the redirect URI is validated (response type, response mode, PKCE, prompt and the other parameters), and invalid_scope. Also unmet_authentication_requirements, server_error and temporarily_unavailable when an extension such as the interaction response generator returns them. invalid_target (RFC 8707) reaches the client too.
• Still go to the error page: errors found before the redirect URI is validated. That includes an unknown client or redirect URI, as the spec requires. It also includes the request object checks, so invalid_request_object, invalid_request_uri and request_uri_not_supported don't reach the client. A missing or unknown response_type also stays on the error page, because the response mode isn't known yet.
• OIS doesn't produce request_not_supported or registration_not_supported itself. If an extension does, they reach the client like any other error.

Closes #137

Type of change

• Bug fix
• Feature
• Refactoring
• Documentation
• Other

Does this PR introduce a breaking change?

Does the change cause a breaking change to any of the following?

• Changes to existing public APIs or DB schema
• Changes which could cause existing behaviour to fail (eg. feature restrictions, changes to default values, stricter validation, etc)

Testing

New AuthorizeResult unit tests cover the option off, the option on, and the option on without a validated redirect URI or response mode. Without the option check, the redirect URI and response mode check, or the new condition as a whole, the matching tests fail. The full unit and integration suites pass.

LLM Usage

The src/ changes are written by me. The tests and the options.rst entry were drafted with Claude and reviewed by me.

Other context

Question: do you want the request object errors to reach the client as well? The validator checks the request object before the client's redirect URI, because the request object can carry the redirect URI. Returning invalid_request_object to the client would mean checking the plain redirect_uri query parameter against the already loaded client when the request object fails, and choosing a response mode. That changes the validator, so I've left it out. I'm happy to add it here or in a follow-up if you'd like it.

With the option on, error codes from custom extensions also go back to the client. That's what section 4.1.2.1 describes, which returns any failure once the redirect URI is valid. If you'd rather limit it to the codes the specs define, that's a small change.

For comparison, Duende IdentityServer returns temporarily_unavailable and unmet_authentication_requirements to the client by default. This PR keeps the current default, as the issue asks.

🤖 Generated with Claude Code

[JoStevensRSK]

I think we need some additional documentation on how errors are handled now, either by adding to the authorise endpoint page or creating a dedicated error handling page? @patchandthat thoughts