I have tried bumping our fork of the plugin to use the latest omniauth-apple. (Note that there are some other changes required, not just a bump of the version number).
tl;dr: it’s still broken
I managed to hack it into working on my sandbox, but it still has a number of issues:
Apple is using a POST request on the callback. This is not common in OAuth implementations because it means
samesite=Lax cookies will not be sent with the request. That means Discourse is unable to read session cookies during the callback, and therefore throws a CSRF error.
INSECURE workaround is to disable this security by changing Discourse cookies to
Using a POST request without a CSRF token also trips another security measure in core.
INSECURE workaround is to remove this line
I was getting a 403 from apple when the omniauth gem was fetching the JWKs. I suspect that the
Accept: header is not being set correctly, but haven’t verified that
INSECURE workaround was to hard-code the keys
After all that, I finally managed to log in with apple. You can try it out on https://sandbox.dtaylor.uk (will leave it working for a few days, but please don’t enter anything sensitive on there because it is INSECURE)
And then… emails/names are still only included in the first authentication. You can try this out - sign in with apple, cancel the account creation, then try again. The second attempt will be missing your details.
So, assuming apple isn’t going to change things any time soon… how could we make this work?
window.location='/auth/apple/callback?code=...&state=.... From there, it would work just like any other provider. However, I think intercepting the POST would require some core API changes.
For (3), I think it could probably be fixed with a little work in the omniauth gem.
But we’re still stuck without name/email, so I’m not sure it’s worth fixing these other problems