Trailing slash in URL breaks the auth flow

[fl0cke]

Describe the bug
We are using a third party OpenID provider that appends a slash to the redirect URL, e.g. scheme://my-domain.com/?code=... (note the trailing slash after my-domain.com). When this URL is opened by the browser, the user is taken back to the app but the auth flow gets stuck. Neither a result nor an error is produced. When the same URL without the trailing slash is opened, everything works fine. We are using AppAuth iOS Version 1.1.

Expected behavior
The AppAuth Android library handles this correctly and is ables to extract the authorization code from the URL, which i think should be the expected behavior.

Smartphone (please complete the following information):

• Device: iPhone 8
• OS: iOS 12.4
• Browser: stock browser

Additional context
We are using a thin wrapper around app auth for flutter (https://github.com/MaikuB/flutter_appauth) which should have no effect on the library's function.

[barnese]

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.

[tmijieux]

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.

[petea]

Related discussion including workaround in #485.