Crash in Auth0WebAuth.swift

[963239327]

Checklist

• The issue can be reproduced in the Auth0.swift sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

Stack Traces:

From Apple's document: You must invoke the continuation’s resume method exactly once.

In line 208 and line 216, it will be called twice.

Reproduction

N/A

Additional context

No response

Auth0.swift version

2.10.0

Platform

iOS

Platform version(s)

All

Xcode version

16.3

Package manager

Swift Package Manager

[Widcket]

Hi @963239327, thanks for reporting this.

Is this crash happening in a situation similar to this one? #827 (comment)

If so, please update to the latest version of the SDK. It'll return an error when attempting to create concurrent login operations: https://github.com/auth0/Auth0.swift/blob/master/Auth0/Auth0WebAuth.swift#L175-L177

[963239327]

Hi @Widcket, thanks for your quick response!

Yes, the crash stack looks similar to the one you mentioned. However, since I haven’t been able to reproduce it, I can’t confirm whether they’re exactly the same.

Just to clarify — when you referred to the latest version, did you mean 2.12.0 or 2.11.0? I didn’t see any mention of this crash being fixed in the release notes for either.

I also reviewed the latest code and noticed that you introduced a custom Barrier to try and address the issue. While this may help prevent the two callbacks in the diagram from being triggered concurrently, I'm wondering if it fully resolves the root cause. In the crash I encountered, the underlying issue is that CheckedContinuation can only be resumed once — the problem isn’t due to concurrency, but rather that the current logic allows the callback to be invoked twice (even without concurrent access).

Does that make sense?

[Widcket]

Hi @963239327,

Just to clarify — when you referred to the latest version, did you mean 2.12.0 or 2.11.0? I didn’t see any mention of this crash being fixed in the release notes for either.

The barrier was added to fix a different issue –see #904.

That fix went out in v2.11.0, but since v2.12.0 just went out yesterday, you might want to upgrade to the latest.

While this may help prevent the two callbacks in the diagram from being triggered concurrently, I'm wondering if it fully resolves the root cause.

The "second" callsite you mention isn't such. It happens in a closure passed to the user agent (the browser).

[963239327]

Thanks for the clarification. It seems that the callback on line 216 is only stored in storage and not actually invoked. Only the callback on line 208 is called, so there shouldn’t be a case where the callback is triggered multiple times — is that correct?

If so, I’m a bit confused. According to the crash report, the start method triggered CheckedContinuation.resume multiple times, which caused the crash. However, looking at the code, it doesn't seem like start would invoke the callback more than once. Do you think updating to the latest version would resolve this crash? (By Barrier)

[963239327]

Can the user agent(the browser) invoke the callback more than once?
Can we add some protection such as:

actor SafeContinuation<T> {
    private var isResumed = false
    private var continuation: CheckedContinuation<T, Never>?
    
    init(_ continuation: CheckedContinuation<T, Never>) {
        self.continuation = continuation
    }
    
    func resume(returning value: T) {
        guard !isResumed else { return }
        isResumed = true
        continuation?.resume(returning: value)
        continuation = nil
    }
}

[Widcket]

It seems that the callback on line 216 is only stored in storage and not actually invoked. Only the callback on line 208 is called, so there shouldn’t be a case where the callback is triggered multiple times — is that correct?

The callback is passed to the PKCE handler, which performs the code exchange. This handler only calls the callback once per code path (success/error):

If it were the case that the callback is invoked twice in the code, the SDK simply wouldn't work. Where this crash happened (see #827 and #729), it was the result of concurrent usage, which is not a valid use case anyway (you only want one Web Auth login operation at a time). Hence why the barrier should prevent it from happening.

Can the user agent(the browser) invoke the callback more than once?

That would be a bug in the browser implementation (ASWebAuthenticationSession, according to your stack trace). Before we look further into this possibility (which we wouldn't be able to fix anyway), let's see if using the barrier would solve the issue. Hence, my suggestion is to update the SDK to the latest version.

[963239327]

OK, I've updated to the latest SDK. I'll continue monitoring and let you know if it resolves the issue.

[963239327]

Hi @Widcket , after upgrading to the latest SDK (2.12.0), it still exists:

[Widcket]

Hi @963239327, can you please provide reproduction steps like in #902?

[963239327]

The bad news is that I haven't been able to reproduce it so far.
The good news is that the error message is clear — we might be able to start by investigating the logic around calling CheckedContinuation.resume multiple times.

[Widcket]

As mentioned in #950 (comment), this could be happening inside ASWebAuthenticationSession. So please provide reproduction steps like in #902 so we can proceed.