Appleでサインインの導入手順|Apple Developerの設定と、つまずきやすい点
Appleでサインインの導入では、ほかのSNSには無い準備がいくつかあります。クライアントシークレットを自社で作って6か月以内に更新すること、転送用アドレスにメールを届けるために送信元を登録すること、名前を初回に保存することです。Apple Developerでの設定から公開後の運用までの手順を順に説明し、つまずきやすい点は後半の表で整理しました。
自社のWebサイトやアプリに「Appleでサインイン」を入れるときの、Apple Developerでの設定から、ログインの処理、公開後の運用までの手順をまとめました。Appleでサインインそのものの意味や、利用者から見た仕組みはAppleでサインインとはで解説しています。
ほかのSNSより準備が多い理由
Appleでサインインの流れは、OAuth 2.0とOpenID Connectに沿っています。ただ、GoogleやLINEと同じ感覚で進めると、次の点でつまずきます。
- 有料のApple Developer Programへの登録が必要で、組織として登録するにはD-U-N-S番号が要る
- クライアントシークレットは管理画面でもらう文字列ではなく、自社で鍵を使って作る。有効期限は最長6か月
- 利用者がメールアドレスを非公開にすると、送信元を登録しておかない限り、事業者からのメールが届かない
- 名前は初回のログインのときにしか渡されない
どれも、設計の段階で知っていれば避けられるものばかりです。

ソーシャルログイン・パスキーの導入をご検討中の方へ
LINE・Google・Apple・Yahoo! JAPAN・Facebook・X のログインとパスキーに、1つの実装で対応できます。対応SNS・料金・導入の流れを資料にまとめています。
導入の前に用意するもの
用意するもの | 内容 |
|---|---|
Apple Developer Programの登録 | 年会費がかかる有料の登録。会社のサービスなら、担当者個人の名義は避けて、組織として登録する。組織の登録にはD-U-N-S番号が必要 |
httpsで公開しているドメイン | ログインのあとに戻ってくるURL(戻り先URL)を登録する |
メールの送信元 | 会員にメールを送るドメインやアドレス。SPFかDKIMで認証しておく |
既存会員の扱いの方針 | メールアドレスで名寄せできない前提で、既存の会員とどう紐づけるかを決めておく |
組織としての登録は、D-U-N-S番号の確認に時間がかかることがあります。ほかのSNSの申請と同じ時期に、準備のいちばん初めに申し込んでおくと、あとの工程が遅れずに済みます。SNS全体の申請と実装の進め方はソーシャルログインの導入手順と期間にまとめています。
Apple Developerでの設定
設定は、Apple Developerの「Certificates, Identifiers & Profiles」で行います。Webサイトで使う場合の流れは次のとおりです。

- プライマリApp IDを作り、Sign in with Appleを有効にする。Webだけで使う場合も、App IDが1つ必要になる
- Webサイト用の識別子としてServices IDを作る。この値が、ログインの要求に付けるclient_idになる
- Services IDの設定で、自社のドメインと戻り先URLを登録する
- Sign in with Appleを有効にした秘密鍵(Key)を作ってダウンロードし、Key IDとTeam IDを控える
- メール転送サービスの設定で、メールの送信元のドメインやアドレスを登録する
- サーバー間通知を受け取る自社のURLを登録する
戻り先URLは、スキーム(https)・ホスト・パスまで含めた完全なURLで登録します。組織のアカウントなら1つのServices IDに100件まで登録できるので、本番用と検証用の両方を最初から入れておくと、公開の直前に慌てずに済みます。
秘密鍵は、プライマリApp ID 1つにつき2つまで作成できます。社外に出さず社内で管理する場所に保管し、担当者個人のパソコンに置いたままにしないようにしましょう。漏えいのおそれがある場合は、新しい鍵を作成して差し替えてください。
クライアントシークレットは自社で作り、6か月以内に作り直す
Appleでサインインのクライアントシークレットは、管理画面で発行される固定の文字列ではありません。前の手順で作った秘密鍵で署名したJWT(JSON Web Token)を、自社で作って使います。

項目 | 入れる値 |
|---|---|
署名の方式 | ES256(秘密鍵で署名し、ヘッダーにKey IDを入れる) |
iss(発行者) | 開発者アカウントの10文字のTeam ID |
aud(受け取り手) | https://appleid.apple.com |
sub(対象) | client_idと同じServices ID(大文字と小文字を区別する) |
iat・exp | 作った時刻と有効期限。期限は最長で6か月(15,777,000秒)先まで |
期限が切れた時点でトークンの交換が失敗し、Appleでログインする会員は全員入れなくなります。作り直しを人の記憶に頼らず、期限の前に自動で作り直す仕組みにするか、更新の日を運用の予定に入れておきましょう。
ログインの処理(Webサイトの場合)
自社のサーバーで行う処理は、次の順です。

- ログインボタンから、Appleの認可画面(https://appleid.apple.com/auth/authorize)に移る。client_id・戻り先URL・scope(name email)・state・nonceを付ける
- 名前やメールアドレスを求める(scopeを付ける)場合は、response_modeをform_postにする。結果は戻り先URLへのPOSTで届く
- 届いた認可コードを、クライアントシークレットと一緒にAppleに送り、IDトークンと交換する
- IDトークンの署名と、発行者・client_id・有効期限・nonceを確かめる
- IDトークンのsub(利用者の識別子)で自社の会員を探し、見つからなければ新しく作る
名前は、初回のログインのときだけ、POSTの中にuserという項目で届きます。IDトークンには含まれず、2回目以降は届きません。受け取ったその場で保存する処理は、後回しにせず最初の実装に含めておきましょう。
会員の識別にはsubを使いましょう。subは同じ開発者アカウントのアプリ・サイトの間で共通です。メールアドレスは非公開の転送用アドレスの場合もあるため、自動の名寄せには使わないでください(ソーシャルログインのアカウント統合)。
転送用アドレスにメールを届ける設定
メールを非公開にした利用者には、Appleが発行した転送用アドレス(@privaterelay.appleid.com)が渡されます。このアドレスへのメールをAppleが転送するのは、登録済みの送信元から送ったものだけです。

- 会員登録の確認、パスワードの再設定、注文の確認など、会員に送るメールの送信元のドメインやアドレスを、すべて登録する(組織のアカウントなら100件まで)
- 登録したドメインはSPFかDKIMで認証しておく
- メール配信サービスを使っている場合は、そのサービスから送るときの送信元も登録の対象になる
送信元の登録が漏れていると、非公開を選んだ利用者にだけメールが届きません。「メールが来ない」という問い合わせが一部の会員からだけ届くときは、まずここを確認しましょう。
通知とアカウント削除への対応
Appleは、利用者の側で起きた変化を、登録したURLにサーバー間通知で知らせます。

- メールの転送を止めた、または再開した
- 利用者がそのアプリ・サイトとの連携をやめた
- 利用者がAppleのアカウントそのものを削除した
転送が止まった会員にはメールが届かなくなるので、ほかの連絡手段に切り替える、マイページで案内を出す、といった扱いを決めておきましょう。
iOSアプリの場合は、App Storeの審査ガイドラインで、アカウントを作れるアプリにはアプリの中で削除できる機能が求められます。Appleでサインインで作ったアカウントを削除するときは、AppleのREST APIで利用者のトークンを取り消します。
つまずきやすい点と対処
つまずく点 | 起きること | 対処 |
|---|---|---|
戻り先URLが登録と違う | Appleの画面でエラーになる | https・パス・末尾のスラッシュまで登録と合わせる。検証用のURLも登録する |
結果をGETで待っている | 名前やメールを求めると、結果がPOSTで届き受け取れない | 戻り先URLでPOSTを受け付ける |
POSTでCookieが送られない | stateを保存したセッションが見つからず、照合できない | 他サイトからのPOSTでもstateを照合できる保存方法にする |
名前を保存し損ねた | 2回目以降は名前が届かない | 初回のPOSTで受け取ったらすぐ保存する |
シークレットの期限切れ | ある日から全員がログインできなくなる | 最長6か月の期限の前に作り直す |
転送用アドレスにメールが届かない | 非公開を選んだ会員にだけ届かない | 送信元を登録し、SPFかDKIMで認証する |
メールアドレスで会員を照合した | 同じ人が別の会員として登録される | subで照合し、既存会員とはログイン後に紐づける |
他サイトからのPOSTで戻ってくるため、Cookieの設定(SameSite属性)やCSRF対策の仕組みによっては、戻り先URLでセッションが引き継がれません。フレームワークの既定の設定のままでは動かないことがあるので、検証の環境で早いうちに試しておくと、公開直前の手戻りを防げます。
テストで確かめること
- 初回の登録と2回目のログインで、同じ会員として扱われるか。初回に名前が保存されているか
- メールを共有した場合と、非公開にした場合の両方で、登録が止まらないか。転送用アドレスにメールが届くか
- 利用者が設定の「Appleでサインイン」から連携を削除したあと、もう一度ログインしたときの動き
- iPhone・Macのほか、AndroidやWindowsのブラウザからログインできるか
- Appleの画面でキャンセルしたとき、エラーの画面で止まらないか
設定から連携を削除すると、次のログインは初回と同じ扱いになり、名前とメールアドレスを選ぶ画面がもう一度出ます。初回の処理を何度も確かめるときに使えます。
Login Plusで導入する場合

Login Plusを使う場合も、Apple Developer Programへの登録と、Apple Developerでの識別子・鍵の作成は、自社のアカウントで行います。手順は、契約企業に無償で提供している申請手順書で案内しています。
- Login Plusの管理画面でサイトを作り、「コネクション」からAppleとの接続を作る
- Apple Developerで作った値を、Appleとの接続に設定する
- ログイン後に戻ってくる自社のURLを、許可されたコールバックURLに登録する
- 自社サイトにAppleのログインボタンを置き、戻ってきたら認可コードでuserinfo APIを呼び、利用者の情報を受け取る
Appleとのやり取りはLogin Plusが受け持つので、自社サイトの実装は、ほかのSNSやパスキーと同じ形で済みます。導入期間は最短3週間、平均で約2か月です。
よくある質問
Webサイトだけでも導入できますか?
できます。iOSアプリが無くても、App IDとServices IDを作れば、Webサイトで使えます。利用者はAndroidやWindowsの端末からも、ブラウザでログインできます。
導入に費用はかかりますか?
Apple側では、有料のApple Developer Programへの登録が必要です。このほか、自社で実装・保守する人件費がかかります。方式ごとの費用の考え方はソーシャルログインの導入費用で解説しています。
個人の名義で登録してもよいですか?
会社のサービスなら、組織として登録することをおすすめします。個人の名義だと、担当者が異動・退職したときに管理画面に入れなくなるおそれがあります。組織の登録にはD-U-N-S番号が必要です。
既に会員がいるサイトに入れるときの注意は?
メールアドレスが一致しても、同じ人とは限りません。既存の会員には、ログインした状態でAppleとの連携を追加してもらう形が安全です。設計の論点はAppleでサインインとはの「実装前に決めること」にまとめています。
Login Plus について
Login Plusは、6つのソーシャルログイン(Apple・Facebook・Google・X(旧Twitter)・Yahoo! JAPAN・LINE)とパスキーに、1つの実装で対応できるサービスです。
- Appleを含む各SNSへの申請手順書を無償で提供
- 各SNSの仕様変更にはLogin Plus側で対応
- 複数のSNSとパスキーを、1つの会員IDに紐づけられる
- 最短3週間、平均約2か月でリリース
Appleでサインインを自社のサイトやアプリに組み込めるかのご相談は、資料請求またはお問い合わせからどうぞ。料金は料金ページ、導入の進め方は導入の流れにまとめています。
ソーシャルログイン・パスキーの資料をお送りします
対応SNS・料金・実装の流れ・導入事例をまとめています。
「自社に導入できるか」のご相談も、同じフォームから承ります。
個別のご相談は からもどうぞ。