LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

ソーシャルログインとApp Store審査——知らないと審査落ちする必須要件

モバイルアプリのソーシャルログインとは、Apple・Google・Facebookなどの外部IdP（Identity Provider＝認証情報の提供元）のアカウントを使って、ユーザーがアプリにサインインできるようにする機能を指します。独自のID/パスワード管理が不要になるためユーザーの離脱を抑えやすく、モバイルアプリ開発の現場で広く採用されています。

ただし、iOSアプリでの実装には注意すべき審査要件があります。Appleの「App Store Review Guidelines」Section 4.8「Login Services」では、FacebookログインやGoogleサインインなどの第三者ソーシャルログインを主要な認証手段として提供するアプリに対し、Sign in with Appleを原則必須として求めています。^*1

他社ソーシャルログインを使うなら、Sign in with Appleは審査で原則必須

App Store Review Guidelines Section 4.8では、Facebookログイン・Googleサインイン・Xログイン・LinkedInログイン・Amazonログイン・WeChatログインなどを主要な認証手段として提供するアプリに対し、同等のプライバシー要件を持つ代替ログイン手段の提供を求めています。^*1

この「同等のプライバシー要件」を満たす選択肢として、Sign in with Appleが具体的に位置づけられています。Sign in with Appleが要件を満たす理由は、収集データをユーザーの名前とメールアドレスのみに限定し、ユーザーがメールアドレスを非公開にできる仕組みを持ち、広告目的のインタラクション追跡を行わない点にあります。

例外として審査要件が適用されないケースもあります。自社独自のアカウント管理システムのみを使うアプリ、教育・法人・業務系アプリで既存の機関アカウントを必要とするケース、特定の第三者サービスのクライアントアプリ（メールクライアント等）などが該当します。ただしこれらに当てはまらない一般的なコンシューマー向けアプリで、Googleログイン等を実装する場合は、Sign in with Appleを合わせて実装しないと審査を通過できません。

Sign in with Appleが「同等のプライバシー要件」を持つ理由

Sign in with Appleには「メール非公開リレー」という独自の機能があります。ユーザーがメールアドレスの共有を望まない場合、Appleは「privaterelay.appleid.com」形式のプロキシアドレスを提供します。アプリ側に渡るのはこのリレーアドレスであり、ユーザーの実際のメールアドレスは公開されません。

また、Appleはユーザー情報（名前・メールアドレス）を初回のサインイン時にのみ共有します。2回目以降のサインインではユーザー情報が渡されないため、アプリ側はこの初回データを適切に保存しておく実装が求められます。これらの仕様は外注先に正確に伝えておくべき技術要件です。

ソーシャルログイン実装の技術構成——iOS/Android別の主要コンポーネント

ソーシャルログインの実装には、プラットフォームごとに異なるSDKとフレームワークを使用します。発注者としてすべての技術詳細を把握する必要はありませんが、外注先に伝える技術要件の整理と、成果物の品質確認のために基本的な構成を理解しておくことが大切です。

iOS——AuthenticationServicesフレームワークとOAuth 2.0/OIDC

iOSでのSign in with Apple実装には、Appleが提供するAuthenticationServices（認証サービス）フレームワークを使用します。このフレームワークの「ASAuthorizationAppleIDProvider」クラスを通じて認証リクエストを送信し、ユーザーのApple IDでの認証フローを呼び出す仕組みです。

Sign in with Apple以外のGoogleやFacebookなどのソーシャルログインは、OAuth 2.0（オープンスタンダードの認可プロトコル）またはOIDC（OpenID Connect＝OAuth 2.0を拡張した認証プロトコル）を使って実装します。各プロバイダーのSDKを組み込み、認可コードを取得してバックエンドのサーバーとトークン交換を行う流れが一般的です。

セキュリティ面で重要なのが「nonce」（ノンス）の実装です。nonceとは、リプレイ攻撃（過去のトークンを再利用して不正ログインを試みる攻撃）を防ぐために、サインインリクエストごとに生成する暗号学的にランダムな文字列です。FirebaseのSign in with Apple実装ではnonceをSHA256でハッシュ化してAppleのリクエストに含め、Firebaseがレスポンスとの照合で改ざんを検出します。

Android/マルチプラットフォーム——Firebase Authenticationによる複数プロバイダー集約

Google・Firebase製の「Firebase Authentication」（ファイヤーベース オーセンティケーション）は、Sign in with Apple・Google・Facebook・Twitter（X）・GitHubなど複数のソーシャルログインプロバイダーを一元管理できるバックエンドサービスです。^*2

Androidアプリではもちろん、iOSアプリでもFirebase Authenticationを使うことで、複数のプロバイダーを統一したインターフェースで扱えます。各プロバイダーへの個別実装をFirebaseが吸収するため、開発工数の削減とコードの統一化が期待できます。より高度なSAMLやOpenID Connect連携が必要な場合は、Firebase Authentication上位サービスの「Identity Platform」を使うことで追加の認証基盤にも対応できます。

React NativeやFlutterなどのクロスプラットフォーム開発でも、Firebase Authentication SDKが各フレームワーク向けに提供されています。iOS/Android両対応のアプリを外注する場合、外注先がFirebase Authenticationの実装経験を持つかどうかが選定の重要な基準になります。

外注前に固めておくべき要件定義——発注者が準備する5項目

ソーシャルログインの外注で失敗しやすいのは、技術的な設定作業を外注先に丸投げした結果、Apple Developer ProgramのアカウントやService IDなどの管理権限があいまいになるケースです。認証基盤は事業継続に直結する部分であり、発注者側が主体的に管理権限を保持する設計が求められます。

Apple Developer Programのアカウントと各種ID（Team ID・Key ID・Service ID）

Sign in with Appleを実装するには、Apple Developer Program（年額$99）への登録が前提です。登録後、以下の4種類の設定値をApple Developerポータルで取得・設定します。

これらの設定値は、発注者が自社のApple Developerアカウントで管理することを推奨します。外注先のアカウントで設定した場合、契約終了後の権限移管に手間がかかる場合があります。

プライバシーポリシーとメール非公開リレー対応の合意

ユーザーがSign in with Appleでメール非公開を選択した場合、アプリ側には「privaterelay.appleid.com」形式のリレーアドレスが渡されます。このリレーアドレス宛てにメールを送信するには、Apple側でのドメイン登録（送信元ドメインの認証）が必要です。

また、プライバシーポリシーにはソーシャルログインで取得する情報（名前・メールアドレス）の取り扱いを明記する必要があります。個人情報保護法の観点からも、どのデータをいつ取得し、どのように管理・削除するかを明確にしておくことが大切です。法務部門との確認事項として、要件定義の段階で整理しておくことを推奨します。

セキュリティ要件——nonceとリプレイ攻撃防止の確認

前述のnonce実装はセキュリティ上の要件であり、外注先が適切に実装しているかを発注者として確認する必要があります。特にFirebase Authenticationを使う場合、Firebase公式が推奨する実装方式（SHA256ハッシュ化済みのnonceをリクエストに含め、Firebaseが検証する方式）^*3に準拠しているかを設計書で確認しましょう。

また、Appleはユーザー情報（名前・メールアドレス）を初回サインイン時にのみ共有します。外注先がこの仕様を正しく把握し、初回サインイン時のデータを保存する実装を行っているかを確認してください。この仕様を見落とすと、ユーザー登録後のプロフィール情報が欠落するバグにつながります。

外注先選定——ソーシャルログイン実装を任せられるベンダーの見極め方

ソーシャルログインの実装は、各プロバイダーの仕様変更や審査要件の更新に対応し続ける必要があります。単発の実装経験だけでなく、継続的なメンテナンスへの対応力も外注先選定の基準になります。

iOS/Android両対応か、特定プラットフォームのみか

iOS専門、Android専門のベンダーの場合、もう一方のプラットフォームへの対応を別途依頼することになり、開発効率が下がる場合があります。iOS/Android両対応のアプリを開発する場合は、React NativeやFlutterによるクロスプラットフォーム開発の経験も確認しましょう。

ネイティブ開発とクロスプラットフォーム開発では、ソーシャルログインの実装方法も異なります。ネイティブiOSではSwift、ネイティブAndroidではKotlinでの実装になり、クロスプラットフォームの場合はフレームワークごとのSDKを使います。依頼するプラットフォームと技術スタックを明確にしてから外注先を絞り込むことが大切です。

Firebase Authenticationの実績と複数プロバイダー集約経験

複数のソーシャルログインプロバイダー（Apple・Google・Facebookなど）を実装する場合、Firebase Authenticationを使った集約が現実的な選択肢になります。外注先にFirebase Authenticationの実装経験があるかを確認し、可能であれば類似案件の実績を示してもらいましょう。

Firebase Authenticationの設定（Firebase Console上でのApple・Google・Facebookプロバイダーの有効化）や、バックエンドのIDトークン検証実装まで一気通貫で対応できるかも確認点です。フロントエンドの実装のみで、バックエンド連携は対応外というベンダーの場合、別途バックエンド担当を確保する必要があります。

App Store審査サポートの有無

ソーシャルログインの実装誤りや、Sign in with Appleの設定漏れは、App Store審査での却下理由になります。外注先が審査プロセスのサポート（審査提出の代行・却下時の修正対応）まで含めた対応を行うかを事前に確認しましょう。

審査後の修正対応まで含めた契約であれば、発注者の負担が大きく軽減されます。一方、「実装のみ、審査は別途」というベンダーの場合は、審査対応の工数を自社で見込んでおく必要があります。

実装工程と発注者が関与すべき確認ポイント

ソーシャルログインの実装は、技術的な作業だけでなく、発注者によるApple Developer設定や法務確認が必要な工程を含みます。外注先に任せる部分と、発注者が責任を持って関与する部分を工程ごとに整理しておくことが重要です。

要件定義→設計→実装→テスト→審査申請の各フェーズ

要件定義フェーズでは、使用するソーシャルログインプロバイダーの確定（Apple必須、Google・Facebookのどれを追加するか）と、審査要件（Sign in with Appleの必須化）の確認を行います。発注者がApple Developer Programに登録し、Team IDを取得しておくことも必要です。

設計フェーズでは、認証フローの設計とFirebase Authentication利用の有無を決定します。メール非公開リレー対応のドメイン設定方針や、ユーザーデータの保存方針（初回サインイン時のみ渡されるデータの扱い）もここで確定します。外注先の設計書にnonce実装の方針が明記されているかを確認してください。

実装フェーズでは、外注先によるSDK組み込みとバックエンド連携を進めます。発注者は途中レビュー（中間報告）でApple Developer設定の反映状況を確認し、秘密鍵（.p8ファイル）の管理状況も把握しておきましょう。秘密鍵は1回しかダウンロードできないため、紛失した場合は再作成が必要になります。

テストフェーズでは、Sign in with AppleとGoogle・Facebookなど全プロバイダーの動作確認を実際のデバイスで行います。メール非公開を選択した際のリレーアドレスの受信確認や、nonce検証が正しく機能しているかのセキュリティテストも含めます。

審査申請フェーズでは、App Store ConnectからTestFlight配布・審査申請を進めます。Sign in with Appleのボタン表示要件（Appleの定めたデザインガイドラインに沿ったボタンのみ使用可能）への準拠確認も、審査前に行ってください。

内製では難しい専門知識と関与が必要な工数

ソーシャルログインを内製で実装する場合、iOS向けにはSwiftとAuthenticationServicesフレームワーク、Android向けにはKotlinとGoogle Identity Services、バックエンドにはJWTトークン検証とOAuth 2.0フローの実装知識が必要です。Firebase Authenticationを使う場合は、さらにFirebaseのプロジェクト設定・セキュリティルール設計の知識も求められます。

これらを内製でカバーするには、iOS/Androidエンジニアとバックエンドエンジニアが協力して取り組む体制が必要です。Apple Developer設定・Firebase Console設定・プライバシーポリシー更新・審査対応を含めると、実装から審査完了まで一定の期間を見込む必要があります。セキュリティ要件（nonce、トークン検証）の見落としは公開後のリスクに直結するため、ソーシャルログインの実装経験を持つベンダーへの外注が、リスク低減の観点から有効な選択肢です。

まとめ——ソーシャルログイン外注の3つの判断軸

本稿では、モバイルアプリのソーシャルログイン（Sign in with Apple等）を外注で実装する際の要点を整理しました。要点を3つに集約すると次の通りです。

第一に、App Store審査要件の確認です。他社ソーシャルログインを主要手段として提供するiOSアプリには、Sign in with Appleの実装が原則必須となります。発注前にこの要件を把握し、外注先にも明確に伝えることが審査通過の前提になります。

第二に、Apple Developer設定の発注者主導管理です。Team ID・Service ID・Key ID・秘密鍵の4種類の設定値は、発注者自身のApple Developerアカウントで管理することが大切です。外注先任せにすると、契約終了後の権限移管が煩雑になる場合があります。

第三に、nonce実装と初回データ保存の仕様確認です。リプレイ攻撃防止のnonce実装と、Apple初回サインイン時のみ渡されるユーザー情報の保存方針は、設計書レベルで外注先の実装方針を確認しておくべき重要な技術要件です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apple「App Store Review Guidelines」Section 4.8 Login Services
2. *2　出典：Google Firebase「Firebase Authentication」公式ドキュメント
3. *3　出典：Google Firebase「Authenticate Using Apple on iOS」公式ドキュメント

Tweet