Custom scheme redirect iOS 11

[MarcoTSS2018]

Hi @ALL
We are facing the following problem. Our authentication service only accepts a https scheme for the redirect uri. So it is not possible to use a custom scheme for a deep linking into to app. So we have implemented a redirect page with a button, which references to a custom scheme like com.myapp://token=abcd1234. This solution works perfectly for iOS 10 and below. On iOS 11 where SFAuthenticationSession is used the library closes the web view without calling any callback. The library seems to block the callbacks when the redirect uri scheme doesn't match the custom scheme.

Is there a way to omit this behavior?

[bbqsrc]

I can confirm this occurs due to this function in OIDAuthorizationService.m:

- (BOOL)shouldHandleURL:(NSURL *)URL {
  NSURL *standardizedURL = [URL standardizedURL];
  NSURL *standardizedRedirectURL = [_request.redirectURL standardizedURL];

  return OIDIsEqualIncludingNil(standardizedURL.scheme, standardizedRedirectURL.scheme) &&
      OIDIsEqualIncludingNil(standardizedURL.user, standardizedRedirectURL.user) &&
      OIDIsEqualIncludingNil(standardizedURL.password, standardizedRedirectURL.password) &&
      OIDIsEqualIncludingNil(standardizedURL.host, standardizedRedirectURL.host) &&
      OIDIsEqualIncludingNil(standardizedURL.port, standardizedRedirectURL.port) &&
      OIDIsEqualIncludingNil(standardizedURL.path, standardizedRedirectURL.path);
}

When I replace it with return YES; my custom URI scheme works as expected.

[bbqsrc]

A fix is available on my fork.

[StevenEWright]

@bbqsrc Any reason not to create a pull request? Also, I would be interested to hear more about the assumption that was being made and why that didn’t work for you.

[bbqsrc]

I haven't tested it thoroughly yet nor decided whether it is the best course of action. Once I've done that I'll provide a pull request, as I've done on the Android version for similar issues. 😄

The assumption made was that the common pattern of using a real redirect URI that has a location header redirecting to a custom scheme (eg com.example.mycallback) has no way of being specified. The function compares the URLs 1:1. By adding the chunk of code that I added, it checks the Info.plist for the supported custom schemes list and checks against that before assuming that the redirectURL can be trusted.

[StevenEWright]

One concern I have is that integrators will place their call to resumeExternalUserAgentFlowWithURL: in their app delegate’s handleURL:... method, and their application will crash with the OIDOAuthExceptionInvalidAuthorizationFlow exception thrown in that method if they get launched with one of their custom url schemes for any other reason.

@WilliamDenniss assuming we come up with a reliable approach to determine whether the request is for us or not, do you have any other concerns?

[bbqsrc]

I don't understand why this is something that the library should handle and not something that the implementer should handle. Adding a check for the correct scheme and expected URL path in the app delegate is not onerous and keeps the API clean.

You could add a convenience function for doing this too, as is already kind of there.

My current implementation is like this anyway:

    func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool {
        switch url.scheme {
        case "com.example.thingo":
            let url = ThingoOAuth.instance.redirectURL(fromCustom: url)
            ThingoOAuth.currentAuthFlow?.resumeAuthorizationFlow(with: url)
            return true
        default:
            break
        }
        
        return false
    }

[StevenEWright]

Generally it's pretty clear when AppAuth is supposed to handle a URL.

The only reason it's not in this case is because the IdP doesn't support custom schemes, and the implementor is going outside the typical flow to make it work.

As a general principle I'd say the common thing should be easy, and the workaround should be possible.

Personally, I feel the current implementation makes sense for most people in most situations, and would advocate for leaving it as the default behavior. That said, I certainly think we should make this flow possible as well.

Why not a simple refactor like:

- (BOOL)resumeExternalUserAgentFlowWithURL:(NSURL *)URL {
  // rejects URLs that don't match redirect (these may be completely unrelated to the authorization)
  if (![self shouldHandleURL:URL]) {
    return NO;
  }
  return [self uncheckedResumeExternalUserAgentFlowWithURL:URL];
}

- (BOOL)uncheckedResumeExternalUserAgentFlowWithURL:(NSURL *)URL {
  // checks for an invalid state
  ...

... which would allow implementors in cases like this one to call uncheckedResumeExternalUserAgentFlowWithURL: explicitly if they care to do so?

Edited to rename method suggestion from unsafe to unchecked, which seems like a slightly clearer suggestion.

[bbqsrc]

I don't know what IdP stands for, but having a custom scheme is something I've always encountered. I've never used a platform or worked for a company that hasn't used a custom scheme where it is available as it solves so many edge cases and oddities across OS versions and platforms.

On Android, the AppAuth implementation supports handling both as a matter of course in the manifest XML itself, so this is even a feature within your own pool of AppAuth implementations.

Perhaps the easiest option is to add an optional parameter called extraCallbackURLs on the authorization and token request objects, which is an array of URLs that a callback may be handled on. That was there's no surprises, it's explicit and handles the edge cases without requiring a subclass.

[StevenEWright]

IdP just stands for "Identity Provider". The OP referred to theirs as an "authentication service"... same thing.

They also said:

"[Their IdP] only accepts a https scheme for the redirect uri."

... and does not support custom schemes. I thought this was the edge case we were trying to solve for here?

On Android, the AppAuth implementation supports handling both as a matter of course in the manifest XML

Perhaps the easiest option is to add an optional parameter called extraCallbackURLs on the authorization and token request objects

So, just to recap, it sounds like we are discussing three possible options for a solution?

1. Let AppAuth clients write their own logic in their UIApplicationDelegate handleURL:... method.
2. Support some settings in an info.plist, analagous to Android.
3. Support some settings passed to "authorization and token request objects" at runtime.

I only based my suggestion (which is a way of supporting solution 1) on what I thought was your reasonable opinion that:

Adding a check for the correct scheme and expected URL path in the app delegate is not onerous and keeps the API clean.

The other options you've mentioned sound completely reasonable as well - though I'd think supporting solutions 2 and 3 would definitely be more work for AppAuth iOS than supporting solution 1 (which is basically a three line change, plus documentation).

Having some parity with Android is certainly a good selling point for solution 2.

Do you have any thoughts on the relative merits of these three solutions? I don't have a lot of experience with the AppAuth Android implementation, so I'd love to hear what you think especially about solution 1 vs. solution 2.

[bbqsrc]

Thanks for the jargon glossary. :)

Yes, this is the case we are solving: that the provider does not allow for custom redirect URLs, and requires http or https, and having that redirect URL do a redirect of its own to a custom scheme.

Solution 2 is by far the easiest to solve this problem, and analogous to what Android does. I could provide a proof of concept that links the "real" redirect URL to an array of other possibilities to handled if you would like? It would not be different to my current fork beyond looking at an OIDRedirectURLs dictionary or something similarly named to get a well-known list of possibilities.

[StevenEWright]

@WilliamDenniss @iainmcgin @tikurahul Opinions?

[vladikoff]

I used the custom schemes from the Android version in my projects and would love if the iOS version of AppAuth also had parity with this.

…

On Wed, May 9, 2018, 08:20 Steven E Wright ***@***.***> wrote: @WilliamDenniss <https://github.com/WilliamDenniss> @iainmcgin <https://github.com/iainmcgin> @tikurahul <https://github.com/tikurahul> Opinions? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#232 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH280KQxIG7LjykOft7CSQ2S2r2_3Jdks5twwkogaJpZM4TjC9X> .

[StevenEWright]

@vladikoff Thank you for weighing in! Much appreciate the cross platform insight.

[iainmcgin]

I think it would be useful to allow passing a set of accepted redirect URIs for a request that canHandleURL matches against (option 3?). This set may or may be disjoint from the specified redirect URI, to accommodate this case where the redirect is captured and rewritten by an intermediary.

Generally speaking, I think that it's OK for this to look different from the way Android configures redirect URIs, because the two platforms have rather different approaches for routing URIs to handlers.

@bbqsrc did you try using a universal link registration to capture the https redirect? If that works for your use case, it would likely be the best solution and require no immediate changes from AppAuth.

https://developer.apple.com/ios/universal-links/

[bbqsrc]

Universal links require control over the server side and configuring a .well-known endpoint for ensuring it works. Even when I configured this for a previous client, I could never consistently get this to work on all devices, so a custom schema fallback was always required.