It appears that for iOS app's that offer social Sign In options like Facebook, Google, Twitter etc, "Sign in with Apple" will be a mandatory option we must include.
Any plan's to add support for this? Major key will be avoiding conflict with accounts created with FB/Twitter/Google that later on choose to sign in with Apple or those created with Apple and Sign In on android devices with other social Sign In options.
Nightmare
I haven't seen anything about it being mandatory but definitely recommended.
I would like to see this implemented as well, I'm going to look into the details of how it should be done but would appreciate any help from people who would also like this added to Parse Server & client SDKs.
@TomWFox It's definitely mandatory: SOURCE
I stand corrected, thanks for that information
Apple back at it again. Would this be something you would like to implement?
+1
Isn't it just another auth adapter with a user identifier and a JWT token?
I don't see why it could lead to any conflicts...
@SebC99 I need exactly that!! but for wordpress authentication. Do you know of any examples which show how to do this ? I just opened an issue on the matter here https://github.com/parse-community/parse-server/issues/5649
has anyone succeeded with Apple SignIn & Parse Server?
I opened a Pull Request with this feature. https://github.com/parse-community/parse-server/pull/5694
Thank you @dplewis !
Has this worked for anyone? I keep getting Insufficient Auth when I try to log in via apple. I send the auth provider apple and id correctly. But cannot get past insufficient auth. My app uses Anon users so I can see the Anon exists in the DB when I think try to login.
Yes it does
@AlexmReynolds Update to the latest version of Parse Server and follow the guide
Yes it does
Anyone know why it's throwing insufficient auth only for sign in with apple? Other sign in paths seem to be just fine. Spent 3 days debugging so far
Figured I'd ask about known issues before opening an issue
@AlexmReynolds Update to the latest version of Parse Server and follow the guide
We have and do. Still no go. The guide also appears to be written with very little clarity on the payload. Not sure if the guide was written by an iOS dev or not. Would be nice if the "id" field references the "[authorization.credential user]" and the token reference "[authorization.credential identityToken]" on the ASAuthorizationAppleIDCredential object. Since we just have to guess which of the values apple gives to send to parse server. Also since identityToken is NSData we are converting this to an NSString for sending to server. No idea if that is correct either since docs don't say how to send the NSData from apple to parse server.
If the guide isn't clear then we will gladly update them.
The auth data requires id and token field
id is a unique identifier. Some sdks will return this. If not you can use the sub component of the JWT token.
token is id_token. Some sdks will return this. If not you can decrypt the sub component of the JWT token to retrieve the id_token.
@SebC99 Want to add anything?
For iOS specifically, the ASAuthorizationAppleIDCredential contains the identityToken which has to be converted in utf8 string, and the user which is the unique id to pass to parse.
PFUser.logInWithAuthType(inBackground: "apple", authData: ["token":String(data: appleIDCredential.identityToken, encoding: .utf8), "id": appleIDCredential.user])
The only disturbing thing to know is that the ASAuthorizationAppleIDCredential doesn't always include the fullName and email of the user, even with the right requested scope as Apple sends it only the first time.
So if a user delete his account on your app, you will never be able to let him create a new one with Apple Sign-In.
@SebC99 that鈥檚 useful info there, might be nice to add a note about use with iOS to the parse server guide and/or the iOS guide as it can definitely be confusing.
Thanks for the clarifications. Sadly this is what we have assumed and what we are sending. When we send the PFUser.logInWithAuthType(inBackground: "apple", authData: ["token":String(data: appleIDCredential.identityToken, encoding: .utf8), "id": appleIDCredential.user]) the request has the new auth data and I see my session token is attached correctly for the anonymous user that is logging in. Still Insufficient Auth. Oh well I'll open an issue shortly. Thanks for your time in helping me know if this is known or if I was reading the docs wrong.
@AlexmReynolds if you already have an anonymous user, you should do a linkWith and not a login
The unsufficient auth is when you try to update a user being unauthenticated, and you shouldn't be trying to update a user at that stage.
Our exact code:
PFUser.current()?.linkWithAuthType(inBackground: "apple", authData: ["token": token, "id": appIDCredential.user]).continueWith { [weak self] task -> Any? in
guard task.result == true else {
PFUser.logInWithAuthType(inBackground: "apple", authData: ["token": token, "id": appIDCredential.user]).continueWith { [weak self] task -> Any? in
guard task.error == nil, let currentUser = task.result else {
return task
}
self?.updateUserProfile(appIDCredential)
return task
}
return task
}
self?.updateUserProfile(appIDCredential)
return task
}
@SebC99 interesting. I was following the facebook and twitter iOS plugins in the Parse iOS SDK. These call login directly and never call link that I could find. Wonder if those auth providers are treated differently in the Parse Server code.
@SebC99 Seems like us adding the below fixed the insufficient auth error. Guess the "optional" text made it seem like it was optional. However without that block, the auth fails. Maybe the docs should denote this block is required but client id is optional? Myself and our Senior backend dev inherited a parse setup and it's confusing as hell so we failed to make the assumption that this block was required. Thanks for your time and help.
auth: {
apple: {
client_id: "" // optional (for extra validation), use the Service ID from Apple.
},
},
That鈥檚 interesting. I assumed it was optional. Would you be willing to write a failing test here?
https://github.com/parse-community/parse-server/blob/master/src/Adapters/Auth/apple.js
Actually there isn鈥檛 a test case for it. Would you like to provide a fix? It looks like it is covered in the code.
@AlexmReynolds We have set the client_id with our app bundle, as we use it to check the JWT validity, so yes it is set for us too.
So was the takeaway from this that the client ID is not actually optional? - if so I'll update the docs
Value is needed according to me. Service id didn鈥檛 work for me. Bundle id did.
Value is needed according to me. Service id didn鈥檛 work for me. Bundle id did.
Where do you get the Service ID anyways ?
Most helpful comment
For iOS specifically, the
ASAuthorizationAppleIDCredentialcontains theidentityTokenwhich has to be converted in utf8 string, and theuserwhich is the uniqueidto pass to parse.The only disturbing thing to know is that the
ASAuthorizationAppleIDCredentialdoesn't always include the fullName and email of the user, even with the right requested scope as Apple sends it only the first time.So if a user delete his account on your app, you will never be able to let him create a new one with Apple Sign-In.