I am experiencing this behavior as well. In my case, I define the redirect URL without a slash to pass to the authorization request: com.example://oauth2callback. As far as I have seen, some identity providers add a slash to the end of the redirect URL and some do not.

The slash can be seen in the path property of URL/NSURL:

if let url = URL(string: "com.example://oauth2callback?code=123") {
    print(url.path.debugDescription) // prints ""
}

if let url = URL(string: "com.example://oauth2callback/?code=123") {
    print(url.path.debugDescription) // prints "/"
}

After doing some debugging, in OIDAuthorizationService.m there is a method to determine if it should resume the authorization flow based on whether or not the redirect URLs match. Since the paths differ between the two, the flow is not resumed. See this line:

https://github.com/openid/AppAuth-iOS/blob/master/Source/OIDAuthorizationService.m#L116

A potential fix might be to relax the check on standardizedURL.path to consider the URLs as matching even if one has an ending slash and the other doesn't.

I had exactly the same problem.

A trailing slash in the "path" part (what comes AFTER the "host" part)
is most of time considered as a differentiating ("http://mydomain.com/hello" is different from"http://mydomain.com/hello/").

If the check may be relaxed, I think it should only allow to consider an empty path "" equals to "/" (just a slash and nothing after it).

https://searchfacts.com/url-trailing-slash/

As a workaround, I just added a trailing slash to the redirectUrl parameter in AuthorizationRequest initialization. There was seemingly no problems with the identity provider backend.

Related discussion including workaround in #485.