SilentSafariViewController dismisses before federated logout can complete

[srgray]

When performing a federated logout, SilentSafariViewController dismisses before the federated logout can complete. (tested on iOS 10)

I suspect that SilentSafariViewController successfully loads the Auth0 logout page and its delegate method is called to dismiss the controller before the redirect to the federated logout page can occur.

I verified this by placing an arbitrary delay of 1 second before the call to dismiss SilentSafariViewController. In that case, the federated logout did occur successfully. But this arbitrary delay doesn't seem like the correct solution to this issue.

[cocojoe]

Hey @srgray curious what happens when testing in iOS11 and it uses SFAuthenticationSession pathway?

[srgray]

@cocojoe When testing on iOS11 and using SFAuthenticationSession, the federated logout works properly. I suspect that this is because the SFAuthenticationSession view controller remains visible after the redirect to federated logout page. The user must manually tap 'Cancel' on SFAuthenticationSession to get it to dismiss.

[srgray]

@cocojoe Any thoughts on this one? Is my assumption correct that the view is dismissing before it can redirect to the federated logout page?

[cocojoe]

So I tested in iOS 10 using a Google connection (I don't have SAML setup) and saw that it got redirected to google before closing. Now it may well be a timing issue, once the first URL is hit the didLoad callback is executed. It feels like the federated redirect takes place while the didLoad callback is executing. (As I didn't see it load the full page before it dismissed).

SFAuthenticationSession works differently, there is no didLoad callback available. It works using a redirect to the app. It may be when using federated this redirect can get lost, hence the manual close, which also gives it plenty of time to follow redirects regardless of connection speed.

[srgray]

OK, thanks for checking. For now, I'm going to add an arbitrary delay before the controller dismisses (on my fork of this repo, since it doesn't feel like a good, general solution).

[cocojoe]

No problem, yes it's not ideal. That is why you may also want to try adding the prompt=login the next time you use Lock after a Logout.

Lock
                    .classic()
                    .withOptions {
                        applyDefaultOptions(&$0)
                        $0.parameters = ["prompt" : "login"]
}