Sign in with Apple

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

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 :thinking:


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.

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.)

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


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:

Let’s take

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


1 Like

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:

Screenshot 2020-08-04 at 14.05.46

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!)


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


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.


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?


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.


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.


:+1: 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.


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

Thanks for taking this on.


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
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.

Yes that’s correct

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

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


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 :slight_smile: a bit.


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


Reddit offers Sign in with Apple for user registration and logging in.

Have you double checked yet? Sign in with Apple would be the best thing to happen to Discourse in a long time.

Mathway has Sign in with Apple as an option for registering an account, along with signing in.

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

  • Your apple id email is

  • You sign up to Discourse with apple

  • You change your Apple ID email to

  • You sign in to Discourse … we still think you are

  • 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.


I’ve been testing today, and the good news is that it looks like Apple fixed it :smiley: 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.