You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But: in OIDAuthorizationService::mresumeExternalUserAgentFlowWithURL there is a check in shouldHandleURL that validates if the URI that came back to the App matches with that I have set for redirect_uri in my initial request.
Now my authentication flow is not finishing.
The solution I'd like
It would be nice if there was some kind of configuration option that would allow me to ignore this additional check. For as far as I can tell from the comments, the check is done to "reject URLs that don't match redirect (these may be completely unrelated to the authorization)".
Alternatives I've considered
I've considered the following:
Create a fork of the repo and only comment out that one line.
Don't use "app://" but Apple's Universal Links, but my client cannot support that (yet?).
Create a patch file of this change and patch the checked out source code in my build phase (this is what I do now).
Additional context
I'm not sure if skipping this check is against the specs or if this introduces a security risk, but I guess if you have a MITM attack the redirect_uri cannot be trusted anyways.
The text was updated successfully, but these errors were encountered:
My use case
I have a current use case where the
redirect_uri
I provide is not the same URI I actually use. This is the setup:redirect_uri
But: in
OIDAuthorizationService::mresumeExternalUserAgentFlowWithURL
there is a check inshouldHandleURL
that validates if the URI that came back to the App matches with that I have set forredirect_uri
in my initial request.Now my authentication flow is not finishing.
The solution I'd like
It would be nice if there was some kind of configuration option that would allow me to ignore this additional check. For as far as I can tell from the comments, the check is done to "reject URLs that don't match redirect (these may be completely unrelated to the authorization)".
Alternatives I've considered
I've considered the following:
Additional context
I'm not sure if skipping this check is against the specs or if this introduces a security risk, but I guess if you have a MITM attack the
redirect_uri
cannot be trusted anyways.The text was updated successfully, but these errors were encountered: