すべてのiOSプッシュ通知連携は、同じゲートから始まります。それは、Apple Push Notification serviceに対し、アプリのユーザーにメッセージを送信する許可があることを証明することです。Appleは、そのための方法を2つ提供しています。APNs認証キー（.p8）またはAPNs証明書（.p12）です。この2つの違いは、一度設定すればよい認証情報と、毎年更新が必要になる認証情報との違いであり、しばしば最悪のタイミングで更新作業が発生します。
このガイドでは、APNs認証が実際にどのように機能するか、.p8キーと.p12証明書のどちらを使用すべきか、そしてこの設定を誤った場合に発生するいくつかのエラーについて説明します。
APNs認証の仕組み
プッシュプロバイダー（PushEngageまたは独自のサーバー）が通知を送信する際、AppleのAPNsプロバイダーAPIに接続し、2つのことを証明する必要があります。それは、あなたの代わりに送信する権限があること、そしてあなたのアプリのバンドルID（APNs用語で「トピック」）をターゲットにする許可があることです。.p8キーと.p12証明書は、それを証明するための2つの異なる方法にすぎません。
デバイス側は別です。アプリはAPNsに登録し、デバイスートークンを受け取ります。これはプロバイダーがどの認証情報を使用しても変更されません。認証は完全にサーバーからAppleへの懸念事項であり、アプリのバイナリに触れることなく方法を切り替えることができる理由です。
.p8認証キー（こちらを使用してください）
.p8はトークン署名キーです。プロバイダーはこれを使用して、APNsへの各接続を認証する短期的なJSON Webトークンを発行します。その特性により、ほとんどすべての人にとってデフォルトの選択肢となっています。
- 期限がありません。年次更新も、忘れた日付によるプッシュ停止もありません。
- 1つのキーで開発者アカウント内のすべてのアプリをカバーできます。2番目のアプリをリリースしても、同じキーで認証できます。
- 開発環境と本番環境の両方で使用できます。サンドボックス/本番証明書のペアは不要です。
- 3つの値で構成されます：.p8ファイル自体、10文字のキーID、およびチームID。
作成前に知っておくべき2つのことがあります。AppleはアカウントごとにアクティブなAPNsキーを2つに制限しているため、大規模な組織はキー作成を慎重な行為として扱い、プロジェクトごとの習慣としないようにしてください。.p8ファイルは作成時に一度しかダウンロードできません。チームが見つけられる場所に保存してください。Appleは再度提供しません。
.p12証明書（従来のパス）
.p12はTLSクライアント証明書で、Appleが発行した後、キーチェーンアクセスからエクスポートされます。トークンを署名するのではなく、接続自体を認証します。これはまだ機能しており、一部のエンタープライズセキュリティポリシーでは依然として必要とされていますが、その制約があるため、Appleは新しい統合をキーへと誘導しています。
- 毎年期限切れになります。 突然の完全なプッシュ失敗の最も一般的な原因は、静かに失効したAPNs証明書です。
- 単一のアプリにスコープが設定されています。 すべてのバンドルIDには独自の証明書が必要であり、すべての証明書には独自の更新カレンダーが必要です。
- Macが必要です。 サインリクエストとキーチェーンのエクスポートダンスには、ブラウザのみのパスはありません。
どちらを使用すべきですか？
| .p8認証キー | .p12証明書 | |
|---|---|---|
| 期限切れ | なし | 12ヶ月ごと |
| スコープ | アカウント内のすべてのアプリ | 1つのバンドルID |
| 環境 | 開発 + 本番 | 証明書ごとに個別にまたはまとめて |
| 作成元 | 任意のブラウザ | キーチェーンアクセスを搭載したMac |
| アカウント制限 | アクティブなキー2つ | アプリごとのペア |
| 使用時期 | ほぼ常に | ポリシーで証明書が必要な場合 |
正直な答え：セキュリティポリシーで証明書パスが強制されない限り、.p8キーを使用してください。可動部品が少なく、更新するものがなく、ポートフォリオ全体で1つの資格情報で済みます。
3分で.p8キーを作成する
- Apple Developerアカウントで、**証明書、ID、プロファイル → キー**に移動し、新しいキーを登録します。
- 名前を付け、**Apple Push Notifications service (APNs)** チェックボックスを有効にして、続行します。
- .p8ファイルをダウンロードします（注意：一度しかチャンスがありません）。確認画面に表示される**キーID**と、アカウントメンバーシップページにある**チームID**をメモしてください。
- これら3つの値をすべてプッシュプロバイダーにアップロードします。PushEngageでは、これはアプリ設定の単一の画面です。<a id="x1">APNs資格情報ガイド</a>でスクリーンショット付きで説明しています。
これらのエラーの説明
「プッシュが機能しない」というチケットの驚くほど多い割合は、偽装された認証情報の問題です。一般的な原因は次のとおりです。
- BadDeviceToken — サンドボックスでビルドされたアプリのトークンを、本番環境に送信しています。またはその逆です。Xcodeのデバッグビルドはサンドボックスと通信し、TestFlightおよびApp Storeのビルドは本番環境と通信します。
- TopicDisallowed — 認証情報が、ターゲットとしているバンドルIDをカバーしていません。通常、アプリごとの.p12証明書とコピー＆ペーストされた構成で発生します。
- Sudden 100% delivery failure — .p12の有効期限が切れています。他に何も確認する前に、証明書の有効期限を確認してください。
- InvalidProviderToken — 無効化された.p8キー、または有効なファイルとペアになっていない間違ったKey ID/Team IDの組み合わせ。
統合における位置づけ
APNs認証情報は、1回のセットアップセッションの最初のステップです。.p8をPushEngageに一度アップロードすれば、それ以降のすべて（iOS SDK 1.0の統合、通知拡張機能によるリッチメディア、トリガーキャンペーン、および配信自体）は、追加の手続きなしにそれに対して実行されます。Firebaseから移行する場合、FCMに提供したのと同じキーがここで機能します。これが、iOSでのFCMからの移行が午後のプロジェクトである理由の一部です。
セットアップ後の戦略レイヤーについては、まずアプリプッシュマーケティングガイドを参照してください。送信の準備ができたら、完全なiOSセットアップガイドで、認証情報の設定から最初のキャンペーン送信までを1時間以内に行えます。
