You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When authenticating via Sign in with Apple, despite the full name scope being set, the created user is missing the full name claim.
This works when signing in with Google instead.
Fundamentally, the difference seems to be that Google (correctly) provides the full name as part of the ID token. Apple, on the other hand, has its own custom return type AuthorizationCredentialAppleID which may contain a given and family name.
The current flow retrieves the ID token via the native modal, and then uses signInWithIdToken1 to create the user. If the data is not in the ID token, it just won't be available to the backend.
I found some previous discussion in #105 - where they reached the same conclusion as ourselves.
The Flutter app must be configured to use sign_in_with_apple2.
Deploy the app to iOS. Now you may attempt the Sign in with Apple flow.
Finally, go to Supabase, in the table view, and check auth.users. Under raw_user_meta_data it'll be a JSON object with claims coming from the ID token, confirm that the full name is not there.
To perform further tests, since Apple sends the full name only once per app, on iOS:
Go to Settings > Apple Account3 > Sign in with Apple
If the app is there, it means a previous sign in was performed - the full name won't be provided again - tap on it
Tap Delete > Stop Using
Expected behavior
I would expect the user name to be available in Supabase Auth.
System information
OS: iOS (macOS too, I think)
Browser (if applies): I'm not sure how to fix it here, as a "plain OAuth" flow is used, with browser redirection
Additional context
We have a proposed fix in our fork4, I'm happy to contribute this in its own branch if you'd like to upstream this specific fix.
Our proposal is to add a call to updateUser5 if a given and/or family name are provided.
Bug report
Describe the bug
When authenticating via Sign in with Apple, despite the full name scope being set, the created user is missing the full name claim.
This works when signing in with Google instead.
Fundamentally, the difference seems to be that Google (correctly) provides the full name as part of the ID token. Apple, on the other hand, has its own custom return type
AuthorizationCredentialAppleID
which may contain a given and family name.The current flow retrieves the ID token via the native modal, and then uses
signInWithIdToken
1 to create the user. If the data is not in the ID token, it just won't be available to the backend.I found some previous discussion in #105 - where they reached the same conclusion as ourselves.
To Reproduce
SupaSocialsAuth
must be configured as follows:The Flutter app must be configured to use
sign_in_with_apple
2.Deploy the app to iOS. Now you may attempt the Sign in with Apple flow.
Finally, go to Supabase, in the table view, and check
auth.users
. Underraw_user_meta_data
it'll be a JSON object with claims coming from the ID token, confirm that the full name is not there.To perform further tests, since Apple sends the full name only once per app, on iOS:
Expected behavior
I would expect the user name to be available in Supabase Auth.
System information
Additional context
We have a proposed fix in our fork4, I'm happy to contribute this in its own branch if you'd like to upstream this specific fix.
Our proposal is to add a call to
updateUser
5 if a given and/or family name are provided.Footnotes
https://supabase.com/docs/reference/dart/auth-signinwithidtoken ↩
https://pub.dev/packages/sign_in_with_apple ↩
This is the very first entry in the settings app, the one referring to your Apple ID ↩
https://github.com/supabase-community/flutter-auth-ui/commit/ae08034a859fa4c44897b259c6d1a8dfcb7ab013#diff-d913ee46f46e1f3c9eea9b13af4b7b5c698acf1eac4e9fb7b898bf57e944e9bd ↩
https://supabase.com/docs/reference/dart/auth-updateuser ↩
The text was updated successfully, but these errors were encountered: