（従来の）iOSでAdobe Pass認証アクセスイネーブラを使用する場合の SSO sso-on-ios-when-using-the-primetime-authentication-access-enabler
概要
Adobe Pass認証を利用したアプリ間のシングルサインオン（SSO）は、基盤となるオペレーティングシステムに応じて異なる方法で機能します。
このドキュメントでは、iOS認証 アクセスイネーブラ を使用する場合の Adobe Pass上の SSO について説明します。
Access Enabler 1.10 は、Adobe Pass Authentication iOSのネイティブ SDKの最新バージョンです。 Adobeでは、古いバージョンのままにするのではなく、このバージョンに移行することを強くお勧めします。 古いバージョンの Access Enabler を使用している場合は、最新バージョン こちらをダウンロードできます。
iOS上の SSO は、次の条件によって決まります。
- アプリでは、同じ トークン ストレージ を使用する必要があります（アクセス イネーブラによって作成されるカスタム ペーストボードの形式）。
- アプリは同じ Device ID を生成する必要があります（Access Enabler は、OS のバージョンに応じて、MAC アドレスまたは IDFV に基づいてデバイス ID を計算します）。
動作
SSO の動作は次のとおりです。
- iOS 6 以前: SSO は、同じチームまたは異なるチームによって開発されたアプリ間で自動的に動作します。 デバイス ID はMAC アドレスに基づいて計算され（同じ値がすべてのアプリで生成されます）、ストレージ領域はすべてのアプリに共通です（カスタムペーストボードは、iOS 6 以下のアプリで共有できます）。
- 重要： iOS SDK 1.9.4 リリースでは iOSの最小デプロイメントターゲットがiOS 7. に増えたことに注意してください
- iOS 7 以降: SSO は次の条件で動作します：
-
アプリは、同じApple配布プロファイル、または同じチームに属するプロファイルを使用して公開されます。 これは、アプリがiOS 7 以降でカスタムのペーストボードを共有する唯一の方法です。 それ以外のシナリオでは、ペーストボードはアプリケーションごとにサンドボックス化されます。 https://developer.apple.com/library/IOs/releasenotes/General/RN-iOSSDK-7.0/index.html から：+[
UIPasteboard pasteboardWithName:create:\] および+[UIPasteboard pasteboardWithUniqueName] は現在、特定の名前を一意にし、同じアプリケーション グループ内のアプリだけがペーストボードにアクセスできるようにします。 既に存在する名前でペーストボードを作成しようとし、それらが同じアプリスイートに属していない場合、開発者は独自の一意でプライベートなペーストボードを取得します。 これは、システムが提供するペーストボード、一般、検索には影響しません。 -
アプリには、同じバンドル ID プレフィックスが付きます（最後のコンポーネントを除くすべてのコンポーネント）。 同じバンドル ID プレフィックスを共有するアプリケーションのみが同じ IDFV を計算します。 https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIDevice_Class/index.html#//apple_ref/occ/instp/UIDevice/identifierForVendor から：IOS 7 では、最後のコンポーネントを除くすべてのバンドル コンポーネントが、ベンダー ID の生成に使用されます。 バンドル ID に 1 つのコンポーネントのみが含まれる場合は、バンドル ID 全体が使用されます。
次に、実際のユーザーが最も頻繁に使用する のiOS 7 以降 シナリオに焦点を当てます。
両方の条件（同じ開発チームのプロファイルを共有し、共通のバンドル識別子プレフィックスを持つ）は SSO の必須条件です。
可能な組み合わせとその結果を次に示します。
- 同じチームと同じバンドル ID プレフィックスのプロファイル：アプリは同じペーストボードストレージを共有し、同じデバイス ID （IDFV）を持ちます。 ユーザーは（使用された最初のアプリで） 1 回だけ認証する必要があり、認証状態は他のすべてのアプリで共有されます。 フローの例：
- ユーザーがアプリ A （バンドル ID com.x.y.AppA）を開き、認証されない
- ユーザーがアプリ A で認証を実行します
- ユーザーがアプリ B （バンドル ID com.x.y.AppB）を開くと、アプリからの使用権限データを共有することで自動的に認証されます。
A （手順 2 から） - ユーザーがアプリ A を開いても認証済み（手順 2 から）
- 同じチームのプロファイルで異なるバンドル ID プレフィックスを持つもの：アプリは同じペーストボードストレージを共有しますが、異なるデバイス ID （IDFV）を持ちます。 ユーザーは、アプリごとに 1 回認証する必要があります。 フローの例：
- ユーザーがアプリ A （バンドル ID com.x.y.AppA）を開き、認証されない
- ユーザーがアプリ A で認証を実行します
- ユーザーがアプリ B （バンドル ID com.z.AppB）を開くと、アクセス イネーブラは、最初のアプリによって取得されたトークンを検出します（ストレージが共有されているため）。デバイス ID が異なるため、SSO 経由では使用されません
- ユーザーがアプリ B で認証を実行します
- ユーザーがアプリ A を開いても認証済み（手順 2 から）
- 異なるチームのプロファイル （このシナリオでは、バンドル ID は無関係です）：アプリには異なるペーストボードストレージがあり、アプリ間で SSO が無効になります。 ユーザーはアプリごとに 1 回認証する必要があり、アプリ間を切り替える際、認証セッションは永続的なままです。 フローの例：
- ユーザーがアプリ A を開き、認証されていません
- ユーザーがアプリ A で認証を実行します
- ユーザーがアプリ B を開き、認証されていない
- ユーザーがアプリ B で認証を実行します
- ユーザーがアプリ A を開き、認証済み（手順 2 から）
- ユーザーがアプリ B を開き、認証されます（手順 4 から）
注意： 上記の SSO 条件は、Apple App Store を使用してアプリケーションをインストールする場合にも適用されることに注意してください。 アプリがシミュレーター（アプリの署名が適用されない）にデプロイされている場合、Xcode と共にインストールされている場合、またはアドホックプロファイルを介して配布されている場合は、結果が異なる場合があります。
重要： 注意（AccessEnabler v1.8 に関して）：上記の 2 番目のシナリオ（同じチームのプロファイルでバンドル ID のプレフィックスが異なる）では、同じチーム（メディア会社）が開発したアプリケーション全体で AccessEnabler v1.8 を使用する場合に、非常に不快なユーザーエクスペリエンスが発生します。 同じメディア会社のアプリ間を移行すると、ユーザーは自動的にログアウトするので、アプリケーション開発者はバンドル ID と配信プロファイルを決定する際に注意する必要があります。 この場合の正確なシナリオを以下に示します。
アプリは同じペーストボードストレージを共有しますが、異なるデバイス ID （IDFV）を持ちます。 ユーザーはアプリごとに 1 回認証する必要がありますが アプリ間を切り替えると認証セッションが消去されます。 フローの例：
- ユーザーがアプリ A （バンドル ID com.x.y.AppA）を開き、認証されない
- ユーザーがアプリ A で認証を実行します
- ユーザーがアプリ B を開き（バンドル ID com.z.AppB）、アプリ A で作成された使用権限データがアクセスイネーブラによって自動的に消去されます（アプリ B で現在計算されているデバイス ID と、アプリ A で作成された使用権限トークンに保存されているデバイス ID との間のクラッシュを検出するセキュリティメカニズム）
- ユーザーがアプリ B で認証を実行します
- ユーザーがアプリ A を開くと、アプリ B で作成された使用権限データがアクセスイネーブラによって自動的に消去されます（アプリ A で現在計算されているデバイス ID と、アプリ B で作成された使用権限トークンに保存されているデバイス ID との間の競合を検出するセキュリティメカニズム）