Microsoft Entra 外部 IDでのネイティブ認証
適用対象: 
従業員テナント 
外部テナント (詳細情報)
Microsoft Entra のネイティブ認証を使用すると、モバイル アプリケーションとデスクトップ アプリケーションのサインイン エクスペリエンスの設計を完全に制御できます。 ブラウザーベースのソリューションと違って、ネイティブ認証を使用すると、アプリのインターフェイスとシームレスに融合された、視覚に訴える最適なピクセルの認証画面を作成することができます。 この方法を使用すると、デザイン要素、ロゴの配置、レイアウトを含むユーザー インターフェイスを完全にカスタマイズできるため、一貫性がありブランド化された外観を作成できます。
ブラウザ委任認証に依存する標準のアプリ サインイン プロセスでは、認証中に中断が発生することがよくあります。 ユーザーはサインインが完了すると、(アプリに戻されるだけのために) 認証のためにシステム ブラウザーに一時的にリダイレクトされます。
ブラウザー委任認証は、攻撃ベクトルの削減やシングル サインオン (SSO) のサポートなどの利点を提供しますが、UI のカスタマイズ オプションが制限され、ユーザー エクスペリエンスが低下します。
使用可能な認証方法
現在、ネイティブ認証では、次の 2 つの認証方法で、ローカル アカウントの ID プロバイダーがサポートされています。
- ワンタイム パスコード (OTP) 付きメールでのサインイン。
- セルフサービスのパスワード リセット (SSPR) をサポートする、メールとパスワードによるサインイン。
ネイティブ認証では、ソーシャル ID やエンタープライズ ID などフェデレーション ID のプロバイダーは、まだサポートされていません。
ネイティブ認証を使用する場合
外部 ID でモバイル アプリとデスクトップ アプリの認証を実装する場合、次の 2 つのオプションがあります。
- Microsoft がホストするブラウザー委任の認証。
- 完全なカスタム SDK ベースのネイティブ認証。
どちらのアプローチを選択するかは、アプリに特有の要件によります。 アプリにはそれぞれ固有の認証ニーズがありますが、留意しておくべき共通の考慮事項がいくつか存在します。 ネイティブ認証とブラウザー委任認証のどちらを選択した場合でも、Microsoft Entra 外部 ID は両方をサポートします。
次の表は、これら 2 つの認証方法を比較しており、アプリのために適切なオプションを決定するのに役立ちます。
| ブラウザー委任認証 | ネイティブな認証 | |
|---|---|---|
| ユーザーの認証エクスペリエンス | ユーザーはサインインが完了すると、(リダイレクトでアプリに戻されるだけのために) システム ブラウザーまたは埋め込みブラウザーに移動して認証します。 リダイレクトによるエンド ユーザー エクスペリエンスへの悪影響がない場合は、この方法をお勧めします。 | ユーザーはアプリを離れることなく、充実したネイティブのサインアップおよびサインイン プロセスを体験できます。 |
| エクスペリエンスのカスタマイズ | マネージド型の ブランド化とカスタマイズのオプションは、そのまますぐに使用できる機能として提供されます。 | この API 中心のアプローチでは高度なカスタマイズが用意されており、設計での広範な柔軟性と、目的に適合した操作性とフローを作成する機能を提供します。 |
| 適用性 | 従業員、B2B、B2C アプリ向けとして適しており、ネイティブ アプリ、シングルページ アプリケーション、Web アプリで使用できます。 | 顧客のファースト パーティー アプリでは、同じエンティティが承認サーバーとアプリを操作する場合、ユーザーはその両方を同じエンティティとして認識します。 |
| Go Live の作業 | 低 。 入手後は、そのまますぐに使用できます。 | 高 。 開発者は、認証エクスペリエンスをビルド、所有、および維持します。 |
| メンテナンス作業 | 低 。 | 高 。 Microsoft がリリースする機能ごとに、使用するユーザーは SDK を更新する必要があります。 |
| Security | 最も安全なオプションです。 | セキュリティに関する責任は開発者と共有され、ベスト プラクティスが実践される必要があります。 これはフィッシング攻撃を受ける傾向があります。 |
| サポートされている言語とフレームワーク |
|
|
利用可能な機能
次の表は、ブラウザー委任およびネイティブ認証機能の使用可否を示します。
| ブラウザー委任認証 | ネイティブな認証 | |
|---|---|---|
| メールによるワンタイム パスコード (OTP) を使ったサインアップとサインイン | ✔️ | ✔️ |
| メールとパスワードを使ったサインアップとサインイン | ✔️ | ✔️ |
| セルフサービス パスワード リセット (SSPR) | ✔️ | ✔️ |
| カスタム クレーム プロバイダー | ✔️ | ✔️ |
| ソーシャル ID プロバイダーでのサインイン | ✔️ | ❌ |
| メールでのワンタイム パスコード (OTP) を使った多要素認証 | ✔️ | ❌ |
| SMS における多要素認証 | ✔️ | ❌ |
| シングル サインオン (SSO) | ✔️ | ❌ |
ネイティブ認証を有効にする方法
最初に、いつネイティブ認証を使用するかについて上記のガイドラインを確認します。 次に、アプリケーションの経営者、デザイナー、開発チームと内部で話し合い、ネイティブ認証が必要かどうかを判断します。
アプリケーションにネイティブ認証が必要であるとチームが判断した場合は、次の手順に従って Microsoft Entra 管理センターでネイティブ認証を有効にします。
- Microsoft Entra 管理センターにサインインします。
- アプリケーション>アプリの登録に移動し、アプリを選択します。
- 認証に移動し、[設定] タブを選択します。
- ネイティブ認証の許可と パブリック クライアント フローの許可 フィールドを選択します。
ネイティブ認証の許可と パブリック クライアント フローの許可の両方を有効にしたら、それに応じて構成コードを更新します。
構成コードを更新する
管理センターでネイティブ認証 API を有効にした後も、Android または iOS/macOS のネイティブ認証フローをサポートするには、アプリケーションの構成コードを更新する必要があります。 そのためには、チャレンジ型フィールドを構成に追加する必要があります。 チャレンジ型は、アプリがサポートしている認証方法について Microsoft Entra に通知するために使用する値の一覧です。 ネイティブ認証のチャレンジ型の詳細については、こちらをご覧ください。 ネイティブ認証コンポーネントを統合するように構成が更新されていない場合、ネイティブ認証 SDK と API は使用できません。
ネイティブ認証を有効にするリスク
Microsoft Entra のネイティブ認証ではシングル サインオン (SSO) はサポートされておらず、アプリのセキュリティを確保する責任は開発チームにあります。
ネイティブ認証を使用する方法
ネイティブ認証 API または Android および iOS/macOS 用の Microsoft 認証ライブラリ (MSAL) SDK を使用して、ネイティブ認証を使用するアプリを構築できます。 可能な限り、アプリへのネイティブ認証を追加するには、MSAL を使用することをお勧めします。
ネイティブ認証のサンプルとチュートリアルについては、次の表を参照してください。
| 言語/ プラットフォーム |
コード サンプル ガイド | ビルドと統合ガイド |
|---|---|---|
| Android (Kotlin) | • ユーザーのサインイン | • ユーザーのサインイン |
| iOS (Swift) | • ユーザーのサインイン | • ユーザーのサインイン |
| macOS (Swift) | • ユーザーのサインイン | • ユーザーのサインイン |
現在 MSAL でサポートされていないフレームワークでアプリを作成する予定の場合は、認証 API を使用できます。 詳しくは、こちらの API リファレンスの記事を参照してください。