Redirect Mismatch Error (OIDC - AWS Cognito)

Security
6

Digging up a bit of a dead thread, but I’ve scoured the forums and don’t see anyone getting any further with this,
Did anyone resolve this?

Just as OP described, I have an identical value in the Cognito “Callback URLs” entry as the opendistro_security.openid.base_redirect_url property in kibana.yml.

I also tried:

  • Setting it as expected
  • Setting opendistro_security.openid.base_redirect_url with a trailing suffix of /app/home etc (but the property name is base_ so I presume it really doesn’t want it
  • Commenting out the opendistro_security.openid.base_redirect_url property, as the docs describe it’s optional

No matter what I do I always get the error=redirect_mismatch issue in the URL.
Tracing this with browser debug tools, I see the following occurs:

  1. HTTP 302 from Cognito with https://<chosenid>.auth.<region>.amazoncognito.com with params client_id, type, scope and redirect_uri - and the URI looks identical to that in my kibana.yml
  2. HTTP 302 from my Kibana with https://<kibanabaseurl>/?code=<code from cognito>
  3. HTTP 302 from my Kibana with https://<kibanabaseurl>/auth/openid/login?nextUrl=?code=<code from cognito>
  4. HTTP 302 against Cognito again with https://<chosenid>.auth.<region>.amazoncognito.com/oauth2/authorize? with all the same params as before, except this time redirect_uri has a different path after an identical base url, of https://<kibanabaseurl>/auth/openid/login&state=<code>&scope=<scopes>
  5. HHTTP 400, error=redirect_mismatch back from Cognito

Note: I saw online some people trying to use http:// (plaintext). I presume you must use https:// - not only because I think OAuth says you must, but because the Cognito dashboard will only accept an https:// URL for the Callback URL field.

Did anyone get this to work?

Edit: After re-reading my post the issue became a bit clearer, although I have not resolved it yet.

As described, a request is made against Cognito. It then returns to Kibana, which then redirects to run another request against Cognito. I’m not 100% sure on why, I guess it’s an OpenIDConnect or OAuth thing - the first one gets the code, and the second one appears to authorize it?

However, there-in lies the issue. When the first request is run against Cognito the redirect_uri matches as configured in Cognito with just the base URL (and optionally also specified in kibana.yml) identically. When the second request is run the URI includes the /auth/openid/login path suffix - which I believe then makes it fail as it does not match.

Re-reading the docs, the Callback URL(s) and Sign out URL(s) fields in the Cognito config actually accept multiple URLs - they have to be comma separated. The next obvious option appeared to be to specify both https://<kibanaserver> and https://<kibanaserver>/auth/openid/login.

Specifying both though does not resolve this. Now I end up with the first request succeeding as usual followed by the second request causing error=invalid_request&error_description=invalid_scope. Having had scope issues previously I am not sure if this is evaluated before or after the redirect issue - it is definitely possible to get this issue before the redirect value is considered. Following this is ends up in a loop between the second request attempt and the server rejecting it, until the browser stops it and displays an error related to too many redirects.

At any rate, it’s very peculiar. Reading the OpenIDConnect spec it sounds like the app (i.e. Kibana) should define the redirect URL. I understand that some identity providers also offer features (or is required?) where the identity provider then also allows you to set permissable values - presumably to prevent some sort of security issue - but this AWS setting appears to control where it goes and is not just a suggestion.
To show this, you can easily try yourself - simply set your callback URL to a fake URL in the Cognito GUI, and hit Launch Hosted UI or trigger the flow via your app and after the initial authentication AWS will re-direct you to your location specified in the AWS console, totally ignoring what the client said
(no guarantees I haven’t misunderstood the spec though!)