Sign in with Apple

[david (David Taylor)]

Issues 1 and 2 are caused by a deliberate implementation choice from Apple. So it’s not really a technical incident, and we can work around them. Issue 3 is with the omniauth-apple gem, so we can fix it.

The thing we need from apple is to include the name/email in subsequent authentication flows. Unfortunately they have acknowledged the behaviour, and said that it works as designed https://forums.developer.apple.com/thread/121496

This behaves correctly, user info is only sent in the ASAuthorizationAppleIDCredential upon initial user sign up. Subsequent logins to your app using Sign In with Apple with the same account do not share any user info and will only return a user identifier in the ASAuthorizationAppleIDCredential. It is recommened that you securely cache the initial ASAuthorizationAppleIDCredential containing the user info until you can validate that an account has succesfully been created on your server.

I am curious though, has anyone seen other websites using sign-in-with-apple? I think I’ve only seen native apps using it

[balboah (Johnny Bergström)]

@david

I am curious though, has anyone seen other websites using sign-in-with-apple?

This feature makes a lot of sense to me, where our iOS app links to our discourse web and the app doesn’t have any login requirements for the other features.
It’s very convenient for users to login using this method since most are already logged in on the device and Apple Pay used for in-app purchases uses the same account.

[Frederik]

@david

The thing we need from apple is to include the name/email in subsequent authentication flows. Unfortunately they have acknowledged the behaviour, and said that it works as designed https://forums.developer.apple.com/thread/121496

IMO it would still make sense to contact Apple DTS about this to see what they suggest as a workaround, and also to give them the feedback that this is causing issues. (Unfortunately I’m not knowledgeable enough about this myself to have that conversation with them.)

@david

I am curious though, has anyone seen other websites using sign-in-with-apple? I think I’ve only seen native apps using it

It’s far from being as pervasive as Google/FB/etc, but I’ve seen in a couple places, e.g. ebay.com, wordpress.com and kayak.com.

[merefield (Robert)]

@Frederik

It’s far from being as pervasive as Google/FB/etc, but I’ve seen in a couple places, e.g. ebay.com , wordpress.com and kayak.com.

They may use a different API though. There’s a JS script you can add, but that won’t integrate with Discourse’s more generic OAuth system I suspect:

https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js

Let’s take Kayak.com.

If I do a bit of sleuthing in the browser inspector I find this:

[david (David Taylor)]

They are using apple’s javascript library, yes. But it’s still using the same ‘OAuth’ (but not really OAuth) API behind the scenes.

Ebay are not even trying to pull the user info. After signing in with apple you get asked for your email:

I suspect Kayak and Wordpress are caching user information from the first authentication attempt, per Apple’s recommendation.

I guess this is probably the approach we will need to take, but it’s not particularly robust (e.g. if network connection gets interrupted during the first attempt, or Discourse gets restored from a backup, or the user changes their apple email address). And, IMO, it is slightly worse from a privacy point of view (we have to store emails for users that haven’t even signed up yet!)

[sam (Sam Saffron)]

I think all the latest apple iOS changes make this workable now, no?

[david (David Taylor)]

Did anything change related to Sign in with Apple recently?

We can certainly get it working as-is - it will require a few days of working around these issues. But then we’re still stuck only receiving email/name on the first ever login.

[sam (Sam Saffron)]

I think they refined it a bit, but I can not easily dig up any specific changes.

I think getting email only once is not a giant issue? I guess we need to test what happens when you change your email on your Apple ID email?

[david (David Taylor)]

@sam

I guess we need to test what happens when you change your email on your Apple ID email?

We should keep receiving the same UID, but we will not receive the new email. The user will have to update it manually in Discourse.

[sam (Sam Saffron)]

I guess we should double check this, but honestly I don’t see this as a giant drama holding us off from implementing this.

The sign in flow on iDevices is just so amazing with sign-in from apple, plus you get 2fa with faceid.

[david (David Taylor)]

will add to my list to get the plugin up-to-scratch so we can test. If it works ok we can move it to core pretty easily.

[merefield (Robert)]

Have passed the repo to David who has moved it to Discourse

Thanks for taking this on.

[Stefan_Brighiu_M]

I read this topic 2-3 times but I don’t remember if you guys tried to get the email from jwt token provided.

This is how i do it in native code. I’m not sure if the web api allows this.

First login you can get the email directly from ASAuthorizationAppleIDCredential.email.
For subsequent logins, the email can be found if you decode the jwt data and get the “email” field.

With this the feature can be implemented right?
The email provided will be the one chosen by the user, personal or random.

[david (David Taylor)]

@Stefan_Brighiu_M

First login you can get the email

Yes that’s correct

@Stefan_Brighiu_M

For subsequent logins, the email can be found if you decode the jwt data and get the “email” field.

That’s not my experience, no. When I last checked, the JWT does not contain the email on subsequent logins.

@david

The thing we need from apple is to include the name/email in subsequent authentication flows. Unfortunately they have acknowledged the behaviour, and said that it works as designed https://forums.developer.apple.com/thread/121496

This behaves correctly, user info is only sent in the ASAuthorizationAppleIDCredential upon initial user sign up. Subsequent logins to your app using Sign In with Apple with the same account do not share any user info and will only return a user identifier in the ASAuthorizationAppleIDCredential. It is recommened that you securely cache the initial ASAuthorizationAppleIDCredential containing the user info until you can validate that an account has succesfully been created on your server.

Regardless, we do intent to get this working soon, and I’ll update this topic when it’s ready

[Stefan_Brighiu_M]

It’s so weird, because on native i got it working just using the jwt email property.

If they don’t update it on web to be similar, the only solution may just be to automatically generate a dummy email (automatically confirmed) and let the user change it afterwards if he wants to.

This would mean relying on the id Apple provides, which is not that bad of a solution, but it does smell a bit.

[david (David Taylor)]

It’s quite possible they have improved things - I’ll be sure to double check

[sam (Sam Saffron)]

We know we can get this to work. What gets complicated is:

• Your apple id email is jane.champion@somewhere.com

• You sign up to Discourse with apple

• You change your Apple ID email to jane.row@somewhere.com

• You sign in to Discourse … we still think you are jane.champion@somewhere.com

• Your email notifications in Discourse will now bounce forever.

We are unclear what process is in place when Apple ID emails change and how we can react to it if at all.

My call on this is that … we just live with this edge case and at least users can opt to change emails in Discourse for edge cases like this.

[david (David Taylor)]

I’ve been testing today, and the good news is that it looks like Apple fixed it I’m seeing the email address present in every authentication.

Still got a few issues to work through, but hope to have something public this week.

[sam (Sam Saffron)]

I would say this is certainly a candidate for shipping with Discourse. We should aim to pull the code into core or at least bundle the plugin for the next major release. (certainly not the one next week though )

[david (David Taylor)]

Yeah we can move it from plugin to core later with minimal effort. One problem is that it is mega-hard to configure when compared with google/facebook/etc.

You need a (paid?) apple developer account, and you have to configure all sorts of domain verification and certificates. It’s certainly achievable with a good #howto though.