Expected behavior: Client , via autosubmit form, is posted to authorize endpoint (other endpoint works okey) but for some reasson (expired seesion, declined etc) faces error. According to OIDC spec, such behaviour is expected: "If the End-User denies the authorization or the End-User authentication fails, the Authorization Server MUST return the error Authorization Response as defined in 4.1.2.1 of OAuth 2.0 [RFC6749]. (HTTP errors unrelated to RFC 6749 are returned to the User Agent using the appropriate HTTP status code.)" In 4.1.2.1 of OAuth : "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, per Appendix B: For example, the authorization server redirects the user-agent by sending the following HTTP response: HTTP/1.1 302 Found Location: https://client.example.com/cb?error=access_denied&state=xyz" So we expect user to be returned to redirect uri via redirect, together with error and error_decription. Actual behavior: During error (for example, end user cancel authentication), flow ends on error.htm form, located at gluu. Not always redirect to redirect_uri happen. On other errors (like unsupported_response_type) , json message with error and error_decription is directly returned to end user browser (blank screen with json). In that case, also no data is forwarded to rediret_uri. error handling is set to remote. Questions: How to always return those error/error_decription messages together with end user back to redirect_uri? For example login_required case is redirected to redirect_ur only first time after server restart. Each subsequential such error always redirect client to error.htm . Why do different errors have different flows. Some are returning to browser as json, other return to redirect uri as parameters etc? How to avoid error messages to be returned directly to end-user browser (like for example for unsupported_response_type)? In that case, is seem that error json is returned to browser which actually is making post/get (browser itself). Thank you