SignInWithApple not working on MacOS BigSur

[mateo-kozomara]

SignInWithApple not working on MacOS BigSur

• Tested with AIR SDK 33.1.1.259, AIR SDK 33.1.1.345 and AIR SDK 33.1.1.406 - all of them produce same result
• Tested on MacOS BigSur v11.2.2

SignInWithApple no longer works on MacOS BigSur.
Issue is happening only on MacOS BigSur, while it works fine on older MacOS versions.

Exactly the same issue can be found here on Unity platform and seems like it is resolved in Unity 2020.

Issue can be avoided by setting com.apple.security.app-sandbox to false, but in that case app cannot be submitted to AppStore since they require it to be true.

Since SignInWithApple is required if you use third party SDKs to provide login functionality (we are using Facebook) we are pretty much blocked by this issue.

Steps to Reproduce

• Use ANE with SignInWithApple that supports MacOS
• [[ASAuthorizationAppleIDProvider alloc] init]; is called inside the ANE
• Following error can be seen in Console.app: Failed to establish connection between notification center endpoint and daemon service with error: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=} User is member of local group User belongs to local, checking passcode Authorization failed: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=}

Known Workarounds

<key>com.apple.security.app-sandbox</key> <false/> can be used in the entitlements to avoid the issue, but in that case app cannot be submitted to AppStore.

[pnico]

We have our MacOS app ready to go, our signing is all good, push notifications and purchase are working but unfortunately we neglected to test Sign in with Apple on Big Sur with sandbox enabled (and of course there's no TestFlight equivalent for MacOS), so our submission was rejected because although it works for those of us still using MacOS Catalina (and on Big Sur with sandbox disabled), it didn't work for the reviewers on Big Sur.

Our app has always offered login with email and Facebook, and we added Sign in with Apple on iOS since it became required in order to use other login methods. A small number of users are using Sign in with Apple in our app now, but it is still the least-used login method; for whatever reason, the vast majority of our users still prefer to use Facebook to log in (far more than email, even).

Sign in with Apple is also required on MacOS in order to use other login methods. We could release with only email login and tell everyone they have to set up email/password login, but it wouldn't make much sense because in practice most users aren't going to do it. So we're blocked on our MacOS release by this, and we've spent a lot of time trying to figure out what we could be doing wrong that only applies to Big Sur, without success so far.

Does anyone out there have an AIR app in Mac App Store using Sign in with Apple working on Big Sur? Any tips to share? We're really stuck here...

[ajwfrost]

How are you triggering the 'Sign in with Apple' functionality? Is there any chance of getting a simple test case together for this so that we can investigate further? From an initial view of this, there may be issues with entitlements etc but I'm assuming that you've already set those up..?

thanks

[mateo-kozomara]

We are triggering "Sign in With Apple" through our own ANE, but same result can be achieved with this ANE, the desktop demo project is included: https://github.com/tuarua/Apple-Signin-ANE

Would that work as a test case? If not, we can setup and send our own demo project for testing.

Entitlements and everything else related to setup should be fine, since the same code works for us on MacOS versions prior to BigSur.

[ajwfrost]

Hi

Thanks we can take a look further using that. Do you actually get any idea of where it's failing on Big Sur, if you run that without the sandbox enabled?

Initial thoughts are whether there is a problem because it's not using the correct button for signing in.. one of their notes says:

Important
When adding the Sign in with Apple button to your storyboard, you must also set the control’s class value to ASAuthorizationAppleIDButton in Xcode’s Identity Inspector.

See https://developer.apple.com/documentation/authenticationservices/asauthorizationappleidbutton

Not sure if that's going to cause this problem though..

thanks

[tuarua]

ASAuthorizationAppleIDButton is a red herring. You don't need to use their styled button.

See here for my own investigations
tuarua/Apple-Signin-ANE#18 (comment)

[mateo-kozomara]

We don't know yet exactly why it's failing on BigSur, but if we find something we will be sure to update here.
ASAuthorizationAppleIDButton is not obligatory to use with the SignInWithApple, so it should not be an issue.

[ajwfrost]

@mateo-kozomara one of the things we’re looking at is whether we need to have the runtime built with a later SDK and Xcode version.. we’re pushing ahead with this and will try to get a test build out ASAP..

[celine-lap]

Hello, would you have an ETA on this by any chance @ajwfrost ? Thank you!!

[ajwfrost]

Hi @celine-lap - the build is updated to use the later SDK, we're just checking to see if we can also build using the latest Xcode as well - but as a minimum, the release coming out in the next few days will be built using MacOS SDK 11.1 which we hope would help here - I'll upload our release candidate here when it's ready (should be on Monday). The update to use the latest Xcode will also then include a few other changes for ARM64 support which is taking a little longer but we're aiming for the end of next week for that i.e. in about 6 days.

thanks

[celine-lap]

Great thank you @ajwfrost

[celine-lap]

Hello! @ajwfrost please let us know when you have updates for the release candidates - looking forward to start testing :) thank you so much!

[ajwfrost]

@celine-lap can you please use the release candidate available from the below link. The release notes aren't yet updated otherwise this is what we're currently going through the QA process with..
https://transfer.harman.com/message/0gTJkRSKv5Dl03holipk7S
thanks

[mateo-kozomara]

@ajwfrost thank you so much for the quick update.

We tried it out, but are having some issues.
First, we got this message while building: Adobe AIR.framework is damaged and can't be opened.

The following command seems to resolve that issue sudo xattr -r -d com.apple.quarantine Adobe\ AIR.framework, but after that we got this during packaging the bundle:

[java] unexpected failure: Platform conversion failed. Process exited with error 139. Output was ""
[java] java.io.IOException: Platform conversion failed. Process exited with error 139. Output was ""
[java] at com.adobe.air.nai.NativePackager.conversionFail(NativePackager.java)
[java] at com.adobe.air.nai.NativePackager.invokePlatformConversion(NativePackager.java)
[java] at com.adobe.air.nai.NativePackager.createPackage(NativePackager.java)
[java] at com.adobe.air.ADT.parseArgsAndGo(ADT.java)
[java] at com.adobe.air.ADT.run(ADT.java)
[java] at com.adobe.air.ADT.main(ADT.java)

[tuarua]

I am seeing the same error when packaging a captive app

[ajwfrost]

Okay thanks - there were some NAIP changes that happened so it looks like we're hitting this - I'll ask one of the guys to look at this first thing tomorrow.. my understanding was that the NAIP binaries would just have been brought forward from the previous SDK but I'm wondering whether there's a problem with the copying or with the code-signatures that are causing issues there...

Thank you for the swift feedback!

[ajwfrost]

Hi - that too longer than it should have done, sorry, please see below the updated RC:
https://transfer.harman.com/message/CLaF354Vlox6aVeefJkEBR
thanks

[mateo-kozomara]

@ajwfrost thank you. Looks like packaging works with this one, but unfortunately SignInWithApple still produces the same error like before.

[ajwfrost]

@mateo-kozomara thanks for checking this .. would it be possible for you to upload your completed app to the below link so that we can take a look and see whether we can adjust anything in-situ for this?
https://transfer.harman.com/requests/tiRNP3GX9vRh6bPCJuNguF
thanks

[mateo-kozomara]

@ajwfrost Sure. Since SignInWithApple is not supported on Developer ID builds, Im going to create a developer build, and for that to work I'm going to need the Provisioning UDID of the Mac's you will be using for testing. It can be found in About This Mac - System Report

Edit: i just realised that you might have asked for the project files, I uploaded them to the provided link.

[ajwfrost]

Hi - sorry, missed this... actually what I was hoping for was the binary/app bundle for your final submission to Apple so that I could check the code signing. Are you notarizing it? as this is a good way to ensure that all the code-signing stuff is sorted out properly.

For the Big Sur machine that I'm using, the provisioning UDID is:
00008103-001018162EA2001E

thanks

[tuarua]

Here is a sample Main.app made with AIR v .444 including the ANE from https://github.com/tuarua/Apple-Signin-ANE

Main.app.zip

Here is a "native" Xcode project. It uses the exact same appId, Mac Developer Certificate and Provisioning Profile etc used by the AIR app.
However, this one will correctly load the Apple Sign In form without error when locally run (doesn't need to be submitted to App Store - ie just run from Xcode).

ExampleMac.zip

[mateo-kozomara]

@ajwfrost I also sent a demo app to your email, since i already uploaded project files to the link you provided.

[celine-lap]

@ajwfrost have you been able to test the demo app that mateo sent you?

[ajwfrost]

Hi @mateo-kozomara @celine-lap
Bit of a delay due to public holidays here, sorry. So the latest status:

• with the binary provided by @mateo-kozomara I was able to reproduce the problem. I had a look at the code-signing and it all seemed fine (although a bit of a mixture of different versions 2.4 vs 2.5). The script for signing definitely looked good.
• when running it, I got an error as follows
  onAppleSignInError: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.)
• with the source code, we can't actually complete the test case here because the "Sign in with Apple" isn't available for us with an Enterprise account..
• there's still a strong possibility they just need you to be compiling with the latest Xcode and/or SDK..

Looking at the console when trying the binary, it looks like this may be something to do with a sign-in method not being configured..?

default 17:05:08.009552+0100    Main    User is member of local group
default 17:05:08.009608+0100    Main    User belongs to local, checking passcode
default 17:05:08.012881+0100    opendirectoryd  While verifying password: user <private> (<private>) is NOT a SecureToken user
default 17:05:08.012917+0100    opendirectoryd  While verifying password: user <private> (<private>) is NOT a ShadowHash user
default 17:05:08.012950+0100    opendirectoryd  While verifying password: using no auth method
default 17:05:08.012984+0100    opendirectoryd  Verified password for <private> (FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000): SecureToken (ODErrorCredentialsMethodNotSupported), Shadowhash (ODErrorCredentialsMethodNotSupported)
default 17:05:08.013020+0100    opendirectoryd  Verified password for <private> (FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000): SecureToken and Shadowhash results match
default 17:05:08.014257+0100    opendirectoryd  AuthenticationAllowed: Evaluation result for record "<private>", record type "<private>": Success
error   17:05:08.014322+0100    opendirectoryd  Authentication failed for <private>: ODErrorCredentialsMethodNotSupported
default 17:05:08.014492+0100    opendirectoryd  ODRecordVerifyPassword failed with result ODErrorCredentialsMethodNotSupported
default 17:05:08.014841+0100    kernel  Sandbox: 5 duplicate reports for ContextStoreAgen deny(1) mach-lookup com.apple.ocspd
error   17:05:08.014851+0100    kernel  Sandbox: Main(37997) deny(1) mach-lookup com.apple.ak.authorizationservices.xpc
error   17:05:08.015058+0100    Main    Authorization failed: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=<private>}

Would you be able to re-build the app using the below SDK, which is built with Xcode 12.2 and includes support for arm64 binaries - so you should end up with a Universal app. If you re-create your ANE library's framework, but leave this set up as if it's just the x86_64 format in the extension.xml, it might still work there.. but that part is still tbc so let me know if there are problems.
https://transfer.harman.com/message/4qJiQEMiKpKiY6QIHgcqL4

thanks

[mateo-kozomara]

Thank you @ajwfrost. I tried rebuilding the ANE with the provided SDK, and tried it out in the app, but unfortunately result seems to be the same, it still doesn't work. I sent a new demo app to your email

[celine-lap]

Hello! any updates @ajwfrost ? :) thank you!

[ajwfrost]

@celine-lap I have kicked off the process here to try to get the appropriate updates from Apple so that we can generate our own Sign-in with Apple profiles; in the meantime we're trying to see what the differences might be between how AIR is set up here, vs how that other sample is set up. Our initial thoughts were around the fact it wasn't built on Big Sur with the latest Xcode or as a universal (x86_64+arm64) binary, but from the above, it appears this wasn't the problem.

I don't suppose there are any clues from any logs or records anywhere as to why the authentication isn't working? The only thing I could see was from the output mentioned above where it ends up with ODErrorCredentialsMethodNotSupported having not found any auth method for verifying the password..

[celine-lap]

Thank you @ajwfrost ! Do you have any idea of how long the process coul take with Apple?
And yes, let us know if you find anything that could explain the differences, but no from our logs we couldn't see anything that would explain it, right @mateo-kozomara ?

[mateo-kozomara]

@celine-lap right, nothing in the logs sticking out unfortunately. I don't believe that something is misconfigured since it works on earlier MacOS versions

[celine-lap]

Hello @ajwfrost , any updates here / any idea how long it could take with Apple?
And let us know if you found anything else!

[ajwfrost]

@celine-lap @mateo-kozomara so we've been looking a little more at this, there have been some updates in recent Big Sur and Xcode release so we're taking those in, just in case there is something relevant to that (we have found other issues where it dependent on the info.plist settings from within the AIR framework).

The other thing we've looked at are the entitlements - I'm not sure I actually have a binary yet where it's working (i.e. non-AIR example app), but if someone could list the entitlements that are granted for that (and the code-signing debug info) it would be useful. One that's been in these non-working test cases is com.apple.security.cs.allow-unsigned-executable-memory and I'm not convinced that we actually need that. We would need com.apple.security.cs.allow-jit but it could also be useful to disable that and run with interpreted ActionScript bytecode just to check that it's not these capabilities that are the problem..

@tuarua would you be able to export your ExampleMac.zip project so that we get the compiled/archived .app folder from that, which would presumably then work?

thanks

[celine-lap]

Thanks @ajwfrost

On our side, Mateo already tested all kinds of different entitlements combinations and doesn't believe the issue comes from there.

Let us know if you find anything from the recent Big Sur and Xcode updates.

Thank you!

[tuarua]

@tuarua would you be able to export your ExampleMac.zip project so that we get the compiled/archived .app folder from that, which would presumably then work?

thanks

ExampleMac.app.zip

[celine-lap]

Hello! Just checking in, are there any updates on this? Thank you

[ajwfrost]

Hi @celine-lap @mateo-kozomara - we're currently still looking at the differences between the code signatures and entitlements, now that the building/binary architectures have been sorted out. The interesting thing is that in the code signature that you've got (in the latest "HarmanDemo.zip" file, Main.app) t's signed by a "Mac Developer" certificate, and despite it using CodeDirectory version 20500 with a minimum OS version of 720896 (11.0.0) it's actually including the sha1 hashes as well as sha256. Looking at the app uploaded by @tuarua it's signed by an "Apple Development" certificate, it has the same CodeDirectory version and minimum OS version but only includes the sha256 hashes.

The minimum OS version for the AIR app is probably set due to our own build process.. I'm not sure whether this should be the issue though since the Sign In feature should presumably work on the older macOS platforms still? but it may be worth trying it with a build that has a much later minimum OS (or that matches the signature..)

The only other difference we could see is the use of the get-task-allow entitlement.

Am wondering whether anyone else has managed to get this working with AIR recently though..?

We're getting set up here to be able to attempt to reproduce it, which will hopefully allow us to move a little quicker.

thanks

[ajwfrost]

Hi again .. quick update to let you know our current focus here: it seems likely that the embedded provisioning profile, which we believe is required in order to ensure the "sign-in with apple" entitlement works, is not actually loaded by the AIR applications because of their build type/category. So we're looking to change these around a little and see if we can get it building/running locally with a more 'traditional' MacOS approach...

[celine-lap]

Ok thanks a lot for the update @ajwfrost , let us know :)

[celine-lap]

Hello @ajwfrost , are there any updates on this?
Thank you!

[celine-lap]

Hello @ajwfrost , just checking in here, let me know if you have updates :) thanks!

[ajwfrost]

Hi @celine-lap - sorry for the delay, we have got into a major mess with signing certificates and accounts which is causing all sorts of problems :-( it seems that being a member of two teams with different accounts and rights but with the same app IDs is causing Xcode/codesign a bit of difficulty. So.. not a huge amount further.. I'm wondering whether we can do something that would allow you to try things independently, will try to get back to you early next week.

[celine-lap]

Hello @ajwfrost , please let me know if you have any updates!

[ajwfrost]

Hi - so we have managed to resolve all the code-signing issues - thankfully! and just had a bit of a side-track to try to work out why the shared AIR runtime wasn't working on macOS...

But one of the guys is back looking to see how we could provide a mechanism for this where the framework is loaded by a new application.

Your app presumably needs to be a full "bundle" or native build, rather than just being a .air distributable that relies on the shared runtime? What we're looking at is:

1. create a test app in Xcode (not using AIR) that uses the Sign in with Apple thing to check that this works - using Objective-C
2. update that test app to load in the AIR framework and see if that changes anything
3. finally update it to not just load in the framework, but to do the Sign in with Apple aspects via a callback from AIR...

Ultimately this might mean that we can have an "Xcode" target from AIR i.e. we can generate a project that people can then use to build their apps via Xcode. Part of the benefit of AIR perhaps is that you don't actually need to use Xcode! but it may help people with some edge cases if they can load in and run the AIR framework dynamically.

thanks

[celine-lap]

Ok thank you @ajwfrost , let us know if you've made any progress and if you need something from us!

[celine-lap]

Hello! Any updates here? :)

[ajwfrost]

Hi @celine-lap Slow progress I'm afraid but we have got the AIR framework set up a little more as a 'framework' now - so, you can create an app using Xcode and load in AIR yourselves to display the content. I'm having to do a legal review of this though as it would change how things can be linked in...

Part of me is still a little concerned though because we don't know the reason why the Sign In wasn't working in the first place. So the idea here is to have an app for which it works, then link in the AIR framework and that shouldn't then change anything... which we hope will then be acceptable to Apple!

thanks

[celine-lap]

Ok thank you! Keep us updated :)

…

On Mon, Jul 26, 2021 at 2:33 AM Andrew Frost ***@***.***> wrote: Hi @celine-lap <https://github.com/celine-lap> Slow progress I'm afraid but we have got the AIR framework set up a little more as a 'framework' now - so, you can create an app using Xcode and load in AIR yourselves to display the content. I'm having to do a legal review of this though as it would change how things can be linked in... Part of me is still a little concerned though because we don't know the reason why the Sign In wasn't working in the first place. So the idea here is to have an app for which it works, then link in the AIR framework and that shouldn't then change anything... which we hope will then be acceptable to Apple! thanks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#729 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APCQPHEB6DVTJKFRQHL7HVTTZT6UVANCNFSM4ZA32MRQ> .

-- Céline Lapouge SongPop 2 Product Manager

[celine-lap]

Hello everyone :)
Just checking in, has there been any updates here?

[waveofthought-code]

Did this ever go anywhere? I'm currently trying to implment Apple Sign In and stumbled across this