How should the auth server (IDP) report the error if the authorisation request redirect_uri doesn't match the configured redirect_uri for the given client?

Let's consider concrete example:

  • auth.com is the IDP
  • service.com if the registered redirect_uri
  • service.io if passed in the authorisation request

Should the auth server:

  1. stay on auth.com and show error?
  2. redirect to service.com/?error=xxx?
  3. redirect to service.io/?error=xxx?

Option 1. seems secure, but UX is subpar — the auth server can only render generic failure that end user cannot do anything about, the requestor doesn't get an error notification and end user cannot try some other authentication method if there were multiple choices

Option 2. seems secure but a bit odd, possibly leaving end user confused (if real and fake sites look same), and I wonder if there's an attack vector I didn't think of...

Option 3. seems quite insecure, certainly auth server should not be redirecting end user to http://localhost or ftp:// or fb.com/post/new, but it does allow for the misconfigured service to learn about the error. I feel that's especially important if the service is e.g. a mobile app with custom URI scheme.

I've skimmed through OAuth 2.0 and OIDC Core specs and so far couldn't figure this out. A canonical answer would be grand!

2 Answers 2


According to the specification, you should display an error message on the authorization server (option 1):

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.


There's another, indirect statement about this case:

Unless the Redirection URI is invalid, the Authorization Server returns the Client to the Redirection URI specified in the Authorization Request with the appropriate error and state parameters. Other parameters SHOULD NOT be returned.

Source: https://openid.net/specs/openid-connect-core-1_0.html#AuthError

I think this confirms @Tangui's answer.

You must log in to answer this question.