Redirect to the app not working 100% of the times

[pedropregueiro]

Redirect to the app not working 100% of the times

[hzalaz]

@pedropregueiro just tried with the sample application in the repo and works everytime with a different state. Can you provide us with a sample project or the snippets necessary to reproduce the issue?

[rezasham]

Hi hzalaz,

I´m working with Pedro on this. This is basically what we do:

We are using the callback method through AppDelegate/Auth0 toolbelt:

func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool {
        
        return Auth0.resumeAuth(url, options:options)
}

In our ViewController:

func authenticate() -> Void {
        Auth0
            .webAuth()
            .scope("openid app_metadata offline_access")
            .parameters(["device":"Iphone x2"])
            .connection("signicats")
            .start { result in
                switch result {
                case .success(let credentials):
                   print("Success")
                    break
                // You've got your credentials
                case .failure(let error):
                    print("error: \(error)")
                    break
                    // Handle the error
                }
        }
    }

We also have a Auth0.plist file containing the Domain and ClientId infromation. As Pedro describes above, it works after 2-3 times, where the successblock gets triggered. I can see that the AppDelegate method does respond consistently each time, so I don´t think the issue is there. But as Pedro describes the state information is not always the same. And therefore, we believe that the callback in webAuth is not responding.

Thanks,

Reza

[cocojoe]

It looks like you are using a custom connection?

Can you try a quick test using a standard connection and see if you have any state issues. The sample application, part of the following Quickstart guide should let you do this. easily. https://auth0.com/docs/quickstart/native/ios-swift

I would like to see if we can isolate the issue e.g. Does it happen for you using say facebook connection or it only happens when using a custom connection. Would be great if you could share this mini project with me at the point it breaks so I can recreate exactly what you are seeing.

Thanks

[pedropregueiro]

hey @cocojoe, just tried with a normal connection like facebook and indeed, it does work everytime. using our custom connection (SAML) it seems like the state gets a bit messed up when trying to login over and over again. Here's a trace of the logs when having auth0.logging(enabled: true):

Safari: https://stuff.auth0.com/authorize?state=IPl5YwEBrENjyS_4e-p-Th2s-1Cpug667KPeF6iKouE&response_type=code&connection=signicat&redirect_uri=<some-url>&client_id=<some-client-id>&code_challenge=d4vmOp8ojRO1Oe96SpmIVKxu_cF2vfcmzU3Bg293OLs&code_challenge_method=S256&scope=openid%20app_metadata%20user_metadata%20offline_access&device=some-device&auth0Client=<some-client>
error: userCancelled
Safari: https://stuff.auth0.com/authorize?state=3i9Dy64zePuVX6DiNHcWxUW4Cy__B-zwsN_KbIjWKN4&response_type=code&connection=signicat&redirect_uri=<some-url>&client_id=<some-client-id>&code_challenge=eFi50mZlHPqptVCDIkqgBD7rpaMK-ljCq2KP-41j2s0&code_challenge_method=S256&scope=openid%20app_metadata%20user_metadata%20offline_access&device=some-device&auth0Client=<some-client>
iOS Safari: <url-scheme>://stuff.auth0.com/ios/<url-scheme>/callback?code=6IuvHor1GXyBEM49&state=IPl5YwEBrENjyS_4e-p-Th2s-1Cpug667KPeF6iKouE

if you look at those requests, the 1st time we open the webAuth(), the state sent is IPl5Yw..., I then cancel that login and try again, a new state is sent 3i9Dy6... and I go through the end with this login. however, the state which is sent back when successfully login is the old one: IPl5Yw... and then the whole process just hangs on the Safari browser with a white page and no action happens afterwards, no callback even. If I then try to login again one more time, it will work as usual since the state sent back and forth is a new one and the same for both request and response.

So, the problem seems to be somehow related with cancelling the login and resetting the state from the webAuth instance. Is there a way we can forcefully "clean" the webAuth0 instance? Or is that state being stored somewhere else as well?

Unfortunately we can't really share the current state of the project and it does seems to be related with this specific use case I said above so if there's something we can try on our own, it would be great, otherwise we can try extracting this code into a separate project later on.

[cocojoe]

Thanks for the helping isolate the issue @pedropregueiro, let me discuss this internally and come back to you. Thx

[hzalaz]

@pedropregueiro seems more like a server issue than an Auth0.swift issue since we only keep track of a single auth transaction which is the latest. So we expect the last state to come back not the previous one since it was discarded.

As I can see from the small logs you provided the second time sends, correctly, a different state but the callback from the SAML IdP or Auth0 returns the old state like it resumed the old transaction instead of starting a new one.

Just to gather more info, can you pass the name of your account or at least if you have enabled the OAuth 2.0 API Authorization ?

[pedropregueiro]

sure @hzalaz, the testing account we're using is mine: pedropregueiro.eu.auth0.com. the problem seems to be exactly that one, that either Auth0 or the SAML IdP are not properly handling the state, though I think that the IdP doesn't even care about states.

if you want, we can take this a bit more privately and I can even send you more info like the client_id and so on, so you can try it yourself as well.

[pedropregueiro]

I can also provide you with more logs, but really, that's all the app is logging in terms of auth0 requests and so on

[hzalaz]

@pedropregueiro I suggest you contact us using https://support.auth0.com so you can pass more info and have some sort of tracking of this issue. Please provide as much info as you can to reproduce it so our backend devs can take a look. Will try to reproduce it on our end and let them know too.

Will close this one since it looks like it's beyond auth0.swift control. Will reopen if something changes

[pedropregueiro]

opened the issue already - no. 17711. if you can push this one internally it'd be great since we've seen quite some wait time on other support tickets before.

thanks for the help @hzalaz!

[pedropregueiro]

hey @hzalaz, one last piece of information on this. I tried grabbing your samples repo example and replicating the issue and I succeeded in it. I think this might be helpful when you guys try to debug what might be happening.

what I changed in your repo was the clientId stuff and the method performFacebookAuthentication into the following:

self.view.endEditing(true)
self.loading = true
Auth0
    .webAuth()
    .connection("signicat")
    .scope("openid")
    .start { result in
        DispatchQueue.main.async {
            self.spinner.stopAnimating()
            switch result {
            case .success(let credentials):
                self.loading = false
                print("success!")
                print("accessToken: \(credentials.accessToken)!")
    //                        self.loginWithCredentials(credentials)
            case .failure(let error):
                self.loading = false
                self.showAlertForError(error)
            }
        }
    }

as you can see, there's only a couple of changes including the self.loading = false so I can retry after success, for demonstrating my issue.

same problem as described above happened: I open the custom login, click on "Done" on the safari webview to close it, try again, and then, after login was successful from SAML IdP, I get a blank safari webview.

hope this helps!