Android で MSAL を使用してクロス アプリ SSO を有効にする
シングル サインオン (SSO) を使用すると、ユーザーは資格情報を一度入力するだけで、その資格情報をアプリケーション間で自動的に機能させることができます。
Microsoft ID プラットフォームと Microsoft Authentication Library (MSAL) は、アプリのスイート間で SSO を有効にするのに役立ちます。 ブローカー機能と Authenticator アプリケーションを使用することで、デバイス全体に SSO を拡張できます。
この攻略ガイドでは、SSO をユーザーに提供するためにアプリケーションで使用される SDK を構成する方法について説明します。
前提条件
この攻略ガイドでは、次を行う方法がわかっていることを前提としています。
- アプリをプロビジョニングします。 詳細については、Android チュートリアルのアプリ作成手順を参照してください
- アプリケーションを MSAL for Android と統合する
SSO の方法
アプリケーションで Android 用 MSAL を使用して SSO を実現するには、次の 2 つの方法があります。
-
デバイス全体の SSO、アカウント管理、条件付きアクセスなどの利点を得るために、ブローカー アプリケーションを使用することをお勧めします。 ただし、ユーザーは追加のアプリケーションをダウンロードする必要があります。
ブローカー認証による SSO
Microsoft の認証ブローカーの 1 つを使用することで、デバイス全体の SSO に参加し、組織の条件付きアクセス ポリシーを満たすことをお勧めします。 ブローカーとの統合には、次の利点があります。
- デバイス SSO
- 以下に関する条件付きアクセス:
- Intune App Protection
- Device Registration (Workplace Join)
- モバイル デバイス管理
- デバイス全体のアカウント管理
- Android AccountManager およびアカウント設定を使用
- "職場アカウント" - カスタム アカウントの種類
Android では、Microsoft の認証ブローカーは、Microsoft Authenticator および Intune ポータル サイト アプリに含まれるコンポーネントです。
次の図は、アプリ、MSAL、Microsoft の認証ブローカーの間の関係を示しています。
ブローカーをホストするアプリのインストール
ブローカーをホストするアプリは、アプリ ストア (通常は Google Play ストア) からデバイス所有者がいつでもインストールできます。 ただし、一部の API (リソース) は条件付きアクセス ポリシーによって保護されており、そのためデバイスを次のようにする必要があります。
- 登録済み (ワークプレースに参加済み)、および/または
- デバイス管理に登録済、または
- Intune App Protection に登録済
そのアプリで対話形式でのトークンの取得が試みられるとすぐに、MSAL によって、デバイスにブローカー アプリがまだインストールされていない場合はインストールするようにユーザーに対して指示されます。 その後、そのアプリで、必要なポリシーにデバイスを準拠させるための手順をユーザーに案内する必要があります。
ブローカーのインストールとアンインストールの影響
ブローカーがインストールされた場合
ブローカーがデバイスにインストールされると、以降のすべての対話型トークン要求 (acquireToken() の呼び出し) は、MSAL によってローカルに処理されるのではなく、ブローカーによって処理されます。 以前に MSAL で使用できた SSO の状態は、ブローカーでは使用できません。 その結果、ユーザーはもう一度認証を行うか、デバイスで認識されている既存のアカウントの一覧からアカウントを選ぶ必要があります。
ブローカーをインストールする場合、ユーザーは再度サインインする必要はありません。 ユーザーが MsalUiRequiredException を解決する必要がある場合にのみ、次の要求がブローカーに送られます。 MsalUiRequiredException はさまざまな理由でスローでき、対話形式で解決する必要があります。 次に例を示します。
- ユーザーがアカウントに関連付けられているパスワードを変更した。
- ユーザーのアカウントが条件付きアクセス ポリシーに適合しなくなった。
- ユーザーがアプリをアカウントに関連付ける同意を取り消した。
複数のブローカー - デバイスに複数のブローカーがインストールされている場合、最初にインストールされたブローカーが常にアクティブなブローカーです。 デバイス上でアクティブにできるブローカーは 1 つだけです。
ブローカーがアンインストールされた場合
ブローカー ホスティング アプリが 1 つだけインストールされていて、それが削除された場合、ユーザーはもう一度サインインする必要があります。 アクティブなブローカーをアンインストールすると、そのアカウントと、関連付けられているトークンがデバイスから削除されます。
Intune ポータル サイトがインストールされていて、アクティブなブローカーとして動作しており、Microsoft Authenticator もインストールされている場合、Intune ポータル サイト (アクティブなブローカー) がアンインストールされると、ユーザーはもう一度サインインする必要があります。 もう一度サインインすると、Microsoft Authenticator アプリがアクティブなブローカーになります。
ブローカーとの統合
ブローカーのリダイレクト URI を生成する
ヒント
この記事の手順は、開始するポータルによって若干異なる場合があります。
ブローカーと互換性のあるリダイレクト URI を登録する必要があります。 ブローカーのリダイレクト URI には、アプリのパッケージ名と、base64 エンコードで表されたアプリの署名が含まれている必要があります。
リダイレクト URI の形式は次のとおりです。msauth://<yourpackagename>/<base64urlencodedsignature>
keytool を使用して、アプリの署名キーを使用し Base64 でエンコードされた署名ハッシュを生成し、その後そのハッシュを使用してリダイレクト URI を生成することができます。
Linux および macOS:
keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64
Windows:
keytool -exportcert -alias androiddebugkey -keystore %HOMEPATH%\.android\debug.keystore | openssl sha1 -binary | openssl base64
keytool で署名ハッシュを生成したら、Azure portal を使用してリダイレクト URI を生成します。
- 少なくともクラウド アプリケーション管理者として Microsoft Entra 管理センターにサインインします。
- 複数のテナントにアクセスできる場合は、上部のメニューの [設定] アイコン
を使用し、[ディレクトリとサブスクリプション] メニューからアプリケーション登録が含まれるテナントに切り替えます。 - [ID]>[アプリケーション]>[アプリの登録] を参照します。
- アプリケーションを選択して、[認証]>[プラットフォームの追加]>[Android] の順に選択します。
- [お使いの Android アプリを構成する] ウィンドウが開いたら、先ほど生成した署名ハッシュとパッケージ名を入力します。
- [構成] ボタンを選択します。
リダイレクト URI が生成され、[Android の構成] ペインの [リダイレクト URI] フィールドに表示されます。
アプリに署名する方法の詳細については、Android Studio ユーザーガイドの「アプリへの署名」を参照してください。
ブローカーを使用するように MSAL を構成する
ご自身のアプリでブローカーを使用するには、ブローカー リダイレクトを構成済みであることを証明する必要があります。 たとえば、MSAL 構成ファイルに以下を含めることで、ブローカー対応リダイレクト URI を含めることと、それを登録したことの両方を示します。
"redirect_uri" : "<yourbrokerredirecturi>",
"broker_redirect_uri_registered": true
ブローカー関連の例外
MSAL とブローカーの通信は次の 2 つの方法で行われます。
- ブローカー バインド サービス
- Android AccountManager
MSAL では最初にブローカー バインド サービスが使用されます。このサービスを呼び出す場合、Android のアクセス許可は必要ないためです。 バインドされたサービスへのバインドが失敗した場合、MSAL では Android AccountManager API が使われます。 MSAL でこれが行われるのは、アプリに既に "READ_CONTACTS" のアクセス許可が付与されている場合のみです。
エラー コード "BROKER_BIND_FAILURE" の MsalClientException が返された場合は、次の 2 つのオプションがあります。
- Microsoft Authenticator アプリと Intune ポータル サイトの電力の最適化を無効にするようにユーザーに依頼します。
"READ_CONTACTS"のアクセス許可を付与するようユーザーに依頼します。
ブローカーの統合の検証
ブローカーの統合が機能しているかどうかはすぐにはわかりませんが、次の手順を使用して確認できます。
- Android デバイスで、ブローカーを使用して要求を完了します。
- Android デバイスの設定で、認証に使用したアカウントに対応する新しく作成されたアカウントを探します。 アカウントの種類は職場アカウントである必要があります。
テストを繰り返す場合は、設定からアカウントを削除することができます。
システム ブラウザーを使用した SSO
Android アプリケーションでは、認証ユーザー エクスペリエンスに WEBVIEW、システム ブラウザー、または Chrome カスタム タブの使用を選択できます。 アプリケーションでブローカー認証が使われていない場合は、SSO を実現するためにネイティブ Web ビューではなくシステム ブラウザーを使う必要があります。
承認エージェント
認可エージェントの特定の戦略を選択することが重要であり、アプリでカスタマイズできる追加機能を表します。 'WEBVIEW' を使用することをお勧めします。 その他の構成値の詳細については、Android MSAL 構成ファイルについての記事を参照してください。
MSAL では、WEBVIEW またはシステム ブラウザーを使用した承認がサポートされています。 次の図は、WEBVIEW、CustomTab 付きのシステム ブラウザー、または CustomTab なしのシステム ブラウザーを使用した認証を示しています。
SSO の影響
アプリケーションで仲介型認証をアプリに統合せずに WEBVIEW の戦略を使用している場合、ユーザーは、デバイス全体またはネイティブ アプリと Web アプリの間でシングル サインオン エクスペリエンスを利用できません。
アプリケーションを MSAL と統合して、認可のために BROWSER を使用することができます。 WEBVIEW とは異なり、BROWSER では cookie jar が既定のシステム ブラウザーと共有されるため、カスタム タブと統合された Web またはその他のネイティブ アプリでのサインインが少なくなります。
アプリケーションで Microsoft Authenticator や Intune ポータル サイトなどのブローカーを使用した MSAL を使用している場合、ユーザーがいずれかのアプリでアクティブ サインインを持っていれば、アプリケーション間で SSO を利用できます。
Note
ブローカーを使用する MSAL は Web ビューを利用し、MSAL ライブラリを使用し、仲介型認証に参加しているすべてのアプリケーションでシングル サインオン (SSO) を提供します。ブローカーからの SSO 状態は、MSAL を使用しない他のアプリには拡張されません。
WebView
アプリ内 WebView を使用するには、MSAL に渡されるアプリ構成 JSON に次の行を追加します。
"authorization_user_agent" : "WEBVIEW"
アプリ内 WEBVIEW を使用すると、ユーザーはアプリに直接サインインします。 トークンはアプリのサンドボックス内に保持され、アプリの cookie jar の外部では使用できません。 そのため、アプリが Authenticator またはポータル サイトと統合されていない限り、ユーザーはアプリケーション間で SSO を利用できません。
ただし、WEBVIEW には、サインイン UI の外観をカスタマイズする機能が用意されています。 このカスタマイズを行う方法の詳細については、「Android WebViews」(Android の WebView) を参照してください。
Browser
WEBVIEW を使用することをお勧めしますが、ブラウザーとカスタム タブ戦略を使用するオプションが用意されています。 カスタム構成ファイルで次の JSON 構成を使用して、この戦略を明示的に指定することができます。
"authorization_user_agent" : "BROWSER"
この方法を使用すると、デバイスのブラウザーで SSO を利用できるようになります。 MSAL では共有 cookie jar が使用されます。これにより、他のネイティブ アプリまたは Web アプリでは、MSAL によって設定された永続セッション Cookie を使用して、デバイスで SSO を実現できます。
ブラウザー選択ヒューリスティック
MSAL では、さまざまな Android フォンで使用するブラウザー パッケージを厳密には指定できないため、最適なクロスデバイス SSO を提供しようとするブラウザー選択ヒューリスティックが実装されています。
MSAL では、初めにパッケージ マネージャーから既定のブラウザーを取得し、それがテスト済みの安全なブラウザーの一覧にあるかどうかを確認します。 ない場合、MSAL によってセーフ リストから別の既定以外のブラウザーが起動されるのではなく、Webview を使用するようにフォール バックされます。 カスタム タブがサポートされているかどうかに関係なく、既定のブラウザーが選ばれます。 ブラウザーでカスタム タブがサポートされている場合、MSAL ではカスタム タブが起動されます。カスタム タブは、アプリ内 WebView に近い外観を持ち、基本的な UI カスタマイズが可能です。 詳細については、「Custom Tabs in Android」(Android のカスタム タブ) を参照してください。
デバイスにブラウザー パッケージがない場合、MSAL ではアプリ内 WebView が使用されます。 デバイスの既定の設定が変更されていない場合は、サインインごとに同じブラウザーを起動して、SSO エクスペリエンスを確実にする必要があります。
テスト済みのブラウザー
次のブラウザーは、構成ファイルで指定されている "redirect_uri" に正しくリダイレクトされるかどうかがテスト済みです。
| Device | 組み込みブラウザー | Chrome | Opera | Microsoft Edge | UC ブラウザー | Firefox |
|---|---|---|---|---|---|---|
| Nexus 4 (API 17) | 合格 | 合格 | 適用外 | 適用外 | 適用外 | 適用外 |
| Samsung S7 (API 25) | 合格1 | 合格 | 合格 | 合格 | 不合格 | 合格 |
| Vivo (API 26) | 合格 | 合格 | 合格 | 合格 | 合格 | 不合格 |
| Pixel 2 (API 26) | 合格 | 合格 | 合格 | 合格 | 不合格 | 合格 |
| Oppo | 合格 | 適用外2 | 適用外 | 適用外 | 適用外 | 適用外 |
| OnePlus (API 25) | 合格 | 合格 | 合格 | 合格 | 不合格 | 合格 |
| Nexus (API 28) | 合格 | 合格 | 合格 | 合格 | 不合格 | 合格 |
| MI | 合格 | 合格 | 合格 | 合格 | 不合格 | 合格 |
1Samsung の組み込みブラウザーは Samsung Internet です。
2Oppo デバイス設定内では、既定のブラウザーを変更できません。
次のステップ
Android デバイス向け共有デバイス モードを使用すると、Android デバイスを複数の従業員で容易に共有できるように構成できます。