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