AppleAuth Integration Questions

Hi Folks,

Having just completed integration of Sign in with Apple (SIWA) authentication to an application with Backendless (Swift SDK), i have two questions about SIWA and Backendless that i was wondering if you could help with.

SERVER-SERVER NOTIFICATION END POINT
Apple provides a way of providing app owners who make use of Sign in with Apple with updates relating to their SIWA user accounts by use of server-server notifications.

As written by Apple:

Sign in with Apple server to server notifications allow you to receive important updates about your users and their accounts. Notifications are sent for each app group when users change mail forwarding preferences, delete their app account, or permanently delete their Apple ID. Each group of apps can have one URL, which must be absolute and include the scheme, host, and path. TLS 1.2 or higher is required to receive notifications.

Do Backendless provide support for this? If not, are there any plans to implement support for this?

‘socialAccount’ COLUMN IN THE USERS TABLE
After registering a new SIWA-authenticated user account, i noticed that each relevant user record was assigned a socialAccount value of BACKENDLESS, which is not what I was expecting.

Mark made a great video about social logins using OAuth2 where he mentions (9:03) that user accounts that make use of OAuth2 providers for authentication are assigned a socialAccount value of OAUTH in their record in the users table.

I was just wondering whether this is expected behaviour or whether the SIWA user records should have a value of OAUTH?

Thanks,

Rory

Hi @Rory_Hannelly ,

SERVER-SERVER NOTIFICATION END POINT
Do Backendless provide support for this? If not, are there any plans to implement support for this?

Unfortunately Backendless doesn’t support this feature and we do not have plans to add it in the closest future.

‘socialAccount’ COLUMN IN THE USERS TABLE
I was just wondering whether this is expected behavior or whether the SIWA user records should have a value of OAUTH ?

It looks like a bug on our side. But at the same time you should not use that field in your logic since it is deprecated. Several years ago we added ability to associate several OAuth identities with single user and that field after that change became obsolete. Currently user can register as regular user and then login with any OAuth provider identity of which the same as in registered user. Information about all related OAuth identities now stored in oAuthIdentities field. You should use that field instead.

Regards, Andriy

1 Like