今年後半に一般公開された際、Appleでのサインインはサポートされるサインイン方法になりますか？
まだ担当者は割り当てられていませんが、話題になれば誰かが担当するでしょう。Discourse コアで迅速に対応しなくても、コミュニティの誰かがプラグインを作成する可能性が高いと思います。
「いいね！」 12
いいね。まだどこにも書かれていなかったから、話題にしようと思ったよ！
Discord用のプラグインに先ほどPRを出したばかりなので、私がやってみるのも悪くないかもしれませんね。どうせたいしたことじゃないでしょう？ 
また、プライバシーに重点を置いている企業（あえて他社名には触れませんが）によるアイデンティティ管理のサポートも重要だと感じています。
「いいね！」 13
@merefield さん、ぜひやってみてください！
すでに omniauth-apple 戦略が存在するため、実現可能です GitHub - nhosoya/omniauth-apple: OmniAuth strategy for Sign In with Apple · GitHub
「いいね！」 16
とても役立ちました、ラファエルさん、ありがとうございます
ほぼ完成に近づきましたが、ここで問題が発生しました：
OAuth 戦略には、Apple の親切な方々から提供される pem キーファイルが必要です。
これを SiteSetting に保存しようとすると、テキストが何らかの理由で破損し、秘密鍵の生成に失敗します：
::OpenSSL::PKey::EC.new(options.pem)
# OpenSSL::PKey::ECError
## invalid curve name
改行がある箇所に \n でエスケープを試みましたが、
このファイルの内容を SiteSetting に保存する方法がなければ、デプロイ可能な形にはならないように思えます。
「いいね！」 1
.pem は公開鍵そのものですよね？
この場合、秘密鍵が含まれています（どうやら他にもエンコードされたものが含まれているようです）。\n\nコードは、この秘密鍵を使ってクライアントシークレットを生成します。\n\nこのライブラリを pem ファイルでテストしましたが、有効でした。しかし、ファイルを SiteSetting に貼り付けると（おそらく予測通り）、微妙に変化してしまいます。\n\n更新: SiteSettings では \n が \\n に置換されているようです。そのため、取得時に \\ を検索して、1 つ減らすことができるかもしれません。\n\nどうやら対応できたようです。スパムになってしまい申し訳ありません。
「いいね！」 7
更新情報：
私のプラグインはある程度まで機能しているようですが、Apple 開発者として設定した認証情報で認証を試みると、Apple から曖昧なエラーが返ってきます。
「エラーによりリクエストを完了できませんでした。後ほど再度お試しください」
ご想像の通り、これでは手がかりがほとんどありません。
さらに複雑なことに、彼らの認証スキームは OAuth 2.0 標準とは大きく異なります。
残念ながら、この機能はまだプレリリース段階のため、Apple に完全な TSI チケットを提出することはできませんが、フィードバック issue として提出する予定です。
リポジトリはこちらです：
※自己責任でご利用ください。まだ正常にテストされていません！
「いいね！」 7
もしかして、pem ファイルのアップロードを使ってみてはどうでしょうか？サイズはどのくらいですか？
とても小さいですよ 
PEM「ファイル」（Site Settings 内の文字列として）は問題なく処理されるようですので、もはやそれが問題ではないようです。
元のエラーは消えました。JWT も今は正常に処理されています。
私は、改行を「$」記号に置き換え、JWT 関数に渡す際に再び「$」を改行に戻すことで解決しました。非標準的な方法ですが、動作します。Ruby の扱い方のせいで、‘/’ をそのまま渡すと問題が発生します（ただし、例外は発生しませんが、この部分に依然として問題が残っている可能性はありますと認めます）。
Apple の認証情報を使って試してみるのは大歓迎です。
認証情報に何か間違えているような気がします。
以下の情報が必要です：
- Team ID
- Client ID
- PEM
- Key ID
Apple のウェブサイト上でこれをすべて設定するのは非常に手間がかかります
「いいね！」 8
@merefield sandbox.dtaylor.uk で正常に動作するようになりました 
ドメイン検証を可能にするために、当社のフォーク でいくつかの変更を行いました。また、サイト設定により具体的な説明を追加し、PEM のマルチラインサポートを有効にしました。
omniauth-apple gem は（まだ？）ユーザーに関する情報を渡すことをサポートしていないようです。これは私たちの用途にはあまり役立ちません。sign-in-with-apple は ほぼ OpenID-Connect 互換のようですので、そのプラグインの機能の一部を再利用できる可能性があります。
資格情報の設定については、Apple のドキュメントよりも、この（非常に適切な名前の）ブログ記事の方がはるかに役立ちました。
「いいね！」 11
素晴らしいですね！textarea は私にとって新しい知識です。私の追加した「ハック」をきれいに回避できて完璧です！もし事前に知っていればよかったのに 
追加された txt ファイルによる検証チェックも気に入っています。素敵な工夫ですね。私は手動で行っていましたが、デプロイ環境での利用には非常に役立ちます。
はい、私もそれを使いました。
残念なことに、あなたのフォークをマージしても、Apple 側の同じエラーが発生したままです。おそらく、資格情報の扱い方でまだ何か愚かなことをしているのでしょう。もしよろしければ、PM で連絡を取り合って情報交換させてください！
「いいね！」 7
はい、私の問題の原因は、ほぼ間違いなく、部分的に開発中のサイト（nginx で実行中かつ HTTPS 経由）へのアクセスを試みたことでした。
本番環境のサイトでもう一度試してみると、 です！
しかし、残念ながら、おっしゃる通り「Name」が返ってきません。これはミドルウェアのせいでしょう？Apple が認証を許可しているように見えます。
名前が返されることは確実でしょうか？プライバシーの観点からは、ユーザー自身が名前を選択する方が、この過程で公開個人識別情報（PII）が漏洩するリスクを避けるのにほぼ優れています。
技術的にはそうなるはずです。ただ、あなたの指摘には同意します。Apple のページで公開しないことを選べる点は、その通りです。しかし、現時点では問題にならなかったようです！
はい、これについて誰かが issue を立てましたが、その後クローズされました。
おそらく、私たちが懸念しているのは このコード部分 でしょうか：
info do
{ sub: id_token['sub'] }
end
一方、discord auth gem の場合は、例えば このように なっています：
info do
{
name: raw_info['username'],
email: raw_info['verified'] ? raw_info['email'] : nil,
image: "https://cdn.discordapp.com/avatars/#{raw_info['id']}/#{raw_info['avatar']}"
}
end
参考までに、Apple の API ドキュメントにはそれらのフィールドについての言及はありません…
この PR は有用なユーザー情報を追加しているようです：https://github.com/nhosoya/omniauth-apple/pull/7。早急にマージされることを願っていますが、もしそうでなければフォークの利用を検討することもできます。
「いいね！」 5
はい、その通りです。その PR は見ていましたが、コードを詳しく調べず、単に依存関係が切り替わっただけだと思っていました。このような広範な変更を PR として提出する際は、そのように詳細が失われる可能性があるため、注意が必要です。
おっしゃる通り：
{
sub: id_info['sub'],
email: user_info.dig('email'),
first_name: user_info.dig('name', 'firstName'),
last_name: user_info.dig('name', 'lastName'),
extra: {
raw_info: id_info.merge(user_info)
}
}
PR を支援するコメントを追加しました。
「いいね！」 4