Microsoft Entra External ID のデバイスコード対応は、スマートテレビ、IoT機器、プリンター、CLIツール、共有端末のように「画面やキーボードで通常のログインがしづらい端末」へ、外部ユーザー向けサインインを組み込みやすくする更新です。結論から言えば、アプリ開発者にとっては認証UIを端末側に無理に作り込まなくてよくなり、IDアーキテクトにとってはコンシューマーやパートナー向けのサインイン設計に新しい選択肢が増えます。
一方で、device authorization grant flow、いわゆるデバイスコードフローはフィッシングにも悪用されやすい認証フローです。採用すべき場面は「入力制約のある端末で、本当に別デバイスによる認証が必要なケース」に絞り、条件付きアクセス、アプリ登録、トークン設計、ユーザー教育をセットで考える必要があります。
Microsoft は 2026年3月の Microsoft Entra 更新情報で、Microsoft Entra External ID の外部テナントにおいて device authorization grant flow がサポートされたことを案内しました。Microsoft Entra ID のワークフォーステナントと同様に、スマートテレビ、IoTデバイス、プリンターなどの入力制約があるデバイスでサインインできるようになる更新です。(Microsoft Learn)
Microsoft Entra External ID のデバイスコード対応で何が変わるのか
Microsoft Entra External ID は、顧客、パートナー、市民、外部ビジネスユーザーなど、組織外のユーザーに対するサインイン体験を提供する ID 基盤です。外部テナントでは、コンシューマーやビジネス顧客向けアプリに CIAM、つまり Customer Identity and Access Management を追加できます。(Microsoft Learn)
今回のポイントは、External ID の外部テナントでも OAuth 2.0 の device authorization grant flow を利用できるようになったことです。従来、外部ユーザー向けアプリでテレビや組み込み機器のような端末を扱う場合、次のような実装上の悩みがありました。
- 端末側にブラウザーやログインフォームを載せにくい
- リモコンや数個のボタンだけではメールアドレスやパスワード入力がつらい
- パートナー企業の現場端末で、個人アカウントや業務アカウントの認証を安全に扱いたい
- 認証コードを独自実装すると、セキュリティ監査や将来の保守が重くなる
device authorization grant flow を使うと、端末には短いコードと認証用URLを表示し、ユーザーはスマートフォンやPCのブラウザーでサインインします。認証が完了すると、端末側アプリはトークンを取得して API を呼び出せます。Microsoft のドキュメントでも、このフローはスマートテレビ、IoTデバイス、プリンターのような入力制約のある端末向けと説明されています。(Microsoft Learn)
つまり、今回の更新は「External ID が対応するサインイン画面が増えた」というより、外部ユーザー向けアプリをデバイス連携シナリオへ広げやすくなったと捉えるのが実務的です。
device authorization grant flow の基本動作
device authorization grant flow は、ユーザーがサインインする端末と、認証を開始した端末が異なる点が特徴です。
たとえばスマートテレビアプリでは、テレビ画面に「このコードを入力してください」と表示し、ユーザーはスマートフォンで認証ページを開いてコードを入力します。テレビ側では、ユーザーの認証完了を待ちながらトークンエンドポイントを定期的に確認します。
| ステップ | 端末側アプリの動き | ユーザーの動き | 設計上の注意点 |
|---|---|---|---|
| デバイスコード要求 | /devicecode エンドポイントへリクエストする | まだ操作しない | 必要な scope を最小限にする |
| コード表示 | user_code と verification_uri を表示する | スマホやPCでURLを開く | フィッシングと誤認されない画面文言にする |
| ユーザー認証 | /token エンドポイントをポーリングする | ブラウザーでサインインし、コードを入力する | ポーリング間隔を守る |
| トークン取得 | 認証完了後にアクセストークンなどを取得する | アプリ利用を開始する | トークン保存と失効時処理を実装する |
| エラー処理 | pending、declined、expired などを処理する | 必要に応じて再試行する | 期限切れ時は新しいコードを発行する |
Microsoft identity platform の仕様では、デバイスコード要求後、既定ではユーザーがサインインできる時間が15分とされています。また、クライアントは authorization_pending、authorization_declined、expired_token などの状態を想定して実装する必要があります。(Microsoft Learn)
開発者が特に見落としやすいのは、デバイスコードフローが「ログインが完了するまで待つだけ」の単純な仕組みではない点です。ユーザーが途中で離脱する、別のユーザーが誤ってコードを入力する、コードが期限切れになる、ネットワークが不安定になる、といった状態を前提に UI とリトライ処理を作る必要があります。
コンシューマー向けサインインで有効なシナリオ
コンシューマー向けでは、デバイスコード対応の価値が出やすいのは「入力体験が悪い端末」です。代表例は、動画配信、ゲーム連携、家電アプリ、会員制サービス、ヘルスケアデバイス、スマートホーム機器などです。
スマートテレビやセットトップボックス
リモコンでメールアドレス、パスワード、MFAコードを入力させる体験は、離脱率が高くなりがちです。デバイスコードフローを使えば、テレビ側では短いコードを表示し、ユーザーはスマートフォンで通常のサインインを完了できます。
この場合の設計ポイントは、テレビ画面に表示する文言です。
悪い例は、単に「コードを入力してください」とだけ表示することです。ユーザーは何のための認証か判断できません。
良い例は、次のように目的、アプリ名、期限、注意喚起を含めることです。
スマートフォンまたはPCでサインインページを開き、画面のコードを入力してください。
この操作は「Example TV」アプリをお客様のアカウントに接続するためのものです。
身に覚えのないコードは入力しないでください。
デバイスコードフィッシングでは、攻撃者がユーザーにコードを入力させ、攻撃者側のセッションを承認させる手口があります。Microsoft Security Blog でも、デバイスコード認証フローを悪用したフィッシングキャンペーンと、必要な場所に限定してデバイスコードフローを許可することの重要性が示されています。(マイクロソフト)
IoT機器や家庭用デバイス
IoT機器では、端末側に十分な画面がないケースがあります。小さな液晶、LED、QRコード表示、同梱アプリとの連携など、入力方法が限られるため、ブラウザー前提の認証を直接載せるのは現実的ではありません。
ただし、IoTでデバイスコードフローを使う場合は、すべての端末を同じ扱いにしないことが重要です。
| 端末タイプ | デバイスコードフローの適性 | 理由 |
|---|---|---|
| ユーザーが目の前で操作する家庭用端末 | 高い | ユーザーがコード表示を確認しやすい |
| 店舗や施設に置く共有端末 | 中程度 | 誰が認証しているかを画面上で明確にする必要がある |
| 完全無人のセンサー | 低い | 人が認証操作を行わないため、別のマシン間認証を検討すべき |
| バックエンド間通信 | 低い | ユーザーサインインではなく client credentials の領域 |
無人機器やサーバー間通信にデバイスコードフローを使うのは避けるべきです。ユーザーが関与しない処理なら、OAuth 2.0 client credentials flow など、マシン間認証に適した方式を検討します。Microsoft Entra External ID では、2026年3月の更新で client credentials も新機能として案内されていますが、M2M認証ではコストやアドオン要件を含めて確認が必要です。(Microsoft Learn)
CLIツールや開発者向けツール
コンシューマー向けとは少し異なりますが、開発者向け CLI、パートナー向け SDK、オンプレミスに配布する管理ツールでも、デバイスコードフローは有効です。
ローカルで動く CLI ツールにブラウザーリダイレクトを組み込む場合、環境によっては localhost のコールバックが使えないことがあります。デバイスコードフローであれば、CLI上にコードを表示し、ユーザーがブラウザーで認証する形にできます。
ただし、CLIでは次の点を必ず実装します。
- 権限スコープを用途別に分ける
- 取得したトークンを平文ファイルに保存しない
- ログにアクセストークンやリフレッシュトークンを出力しない
- 共有サーバー上で複数ユーザーが同じ認証キャッシュを使わないようにする
- サインアウト、トークン削除、再認証コマンドを用意する
特にパートナー企業へ配布するツールでは、利用者の端末管理レベルが自社と異なります。認証キャッシュの保存場所、暗号化、ログ収集範囲は、アプリ仕様書に明記しておくべきです。
パートナー向けサインインでの意味
Microsoft Entra External ID は、コンシューマーだけでなく、パートナーやビジネス顧客向けの外部IDシナリオにも関係します。Microsoft の概要説明でも、External ID はコンシューマー向けアプリ開発者の CIAM と、ビジネスゲストとの安全な B2B コラボレーションの両方を対象にしています。(Microsoft Learn)
パートナー向けで重要なのは、誰をどのテナントで管理するかです。
External ID には大きく分けて、従業員テナントで外部ゲストと協業する構成と、外部テナントで顧客・ビジネス顧客向けアプリを提供する構成があります。外部テナントは、従業員や社内リソースとは分離された、外部向けアプリと顧客アカウント用のテナントとして説明されています。(Microsoft Learn)
B2Bコラボレーションと外部テナントの使い分け
| 観点 | 従業員テナントのB2Bコラボレーション | External ID 外部テナント |
|---|---|---|
| 主な対象 | 取引先、委託先、ゲストユーザー | 顧客、会員、パートナーアプリ利用者 |
| アクセス先 | Microsoft 365、SaaS、社内業務アプリなど | 自社が公開する外部向けアプリ |
| ユーザー管理 | 招待やゲスト管理が中心 | サインアップ、サインイン、CIAMが中心 |
| デバイスコードの使いどころ | 社内連携ツールや管理系ツール | 外部向け端末、パートナー向けCLI、専用端末 |
| 設計の焦点 | ゲストアクセス制御、テナント間信頼 | 顧客体験、スケール、ブランディング、API連携 |
パートナー企業の現場担当者が、専用端末やCLIから自社サービスへアクセスする場合、External ID 外部テナントとデバイスコードフローの組み合わせが候補になります。
たとえば、物流パートナー向けの出荷端末、店舗向けの在庫確認端末、代理店向けの見積もりCLIなどです。端末上で複雑なログインUIを実装せず、ユーザーは自分のスマートフォンやPCで認証できます。
ただし、パートナー向けシナリオでは「便利だから採用する」だけでは不十分です。取引先ごとのアクセス範囲、退職者・異動者の扱い、端末紛失時の無効化、監査ログの保存期間まで含めて設計します。
採用すべきケースと避けるべきケース
デバイスコード対応は便利ですが、すべてのアプリに入れる機能ではありません。判断基準は明確です。
採用しやすいケース
次の条件に複数当てはまる場合は、採用候補になります。
- 端末側で通常のブラウザーログインが難しい
- ユーザーが端末の画面やコードを物理的に確認できる
- スマートフォンやPCで認証する方が明らかに使いやすい
- 端末とユーザーアカウントを一時的または継続的にひも付けたい
- ユーザーが操作するタイミングで認証を開始できる
- 監査ログ、失効、再認証、サポート対応を運用に組み込める
具体例としては、スマートテレビの会員ログイン、店舗端末の担当者ログイン、パートナー向けCLI、プリンターや複合機のクラウド連携などです。
避けるべきケース
一方、次のようなケースでは別方式を検討します。
| 避けるべきケース | 理由 | 代替候補 |
|---|---|---|
| Webアプリで通常のリダイレクトログインが可能 | デバイスコードにする理由が薄い | Authorization Code Flow + PKCE |
| ユーザーが関与しないバッチ処理 | ユーザー認証ではない | Client Credentials Flow |
| 高権限の管理操作を行う端末 | フィッシング時の被害が大きい | 条件付きアクセス、管理者用別フロー |
| 不特定多数が触る公共端末 | 誤認証やアカウント残留のリスクがある | 短時間セッション、都度認証、端末リセット |
| 画面表示やコード確認ができないIoT | ユーザーがコードを確認できない | デバイス証明書、マシン認証 |
デバイスコードフローは、ユーザー体験を改善するための選択肢です。通常のログインが問題なく使えるアプリに追加すると、攻撃面を広げるだけになる可能性があります。
実装時に押さえるべき設計ポイント
アプリ開発者とIDアーキテクトが最初に合意すべきなのは、フローの可否ではなく「このフローをどの範囲で許可するか」です。
アプリ登録とスコープは用途別に分ける
デバイスコードフローを使うアプリは、通常のWebアプリやモバイルアプリと同じアプリ登録にまとめない方が管理しやすくなります。
理由は、監査、条件付きアクセス、同意、権限見直しの単位を分けられるからです。
たとえば、次のように分けます。
| アプリ登録 | 用途 | 権限設計 |
|---|---|---|
| customer-web-app | 通常のWebログイン | Webアプリに必要な最小権限 |
| partner-cli-tool | パートナー向けCLI | CLI操作に必要なAPIスコープのみ |
| tv-device-app | スマートテレビ連携 | 視聴・プロフィール参照などに限定 |
| field-terminal-app | 現場端末 | 店舗・拠点単位の権限を別途API側で制御 |
OAuth の scope は「認証方式」ではなく「何を許可するか」を表すための重要な境界です。デバイスコードフロー用アプリに広すぎるスコープを付与すると、フィッシングや端末紛失時の影響が大きくなります。
ユーザーに表示する情報を具体化する
デバイスコードフローでは、ユーザーが別端末でコードを入力します。このときユーザーが判断できる材料を出さないと、正規操作と攻撃を見分けにくくなります。
端末画面には少なくとも次の情報を表示します。
- アプリ名
- 接続しようとしているサービス名
- コードの有効期限
- 操作を開始した端末名または場所
- 身に覚えのない場合は中止する案内
- サポート窓口やヘルプへの導線
パートナー向け端末では、さらに「会社名」「拠点名」「端末ID」を表示すると、サポート時の切り分けがしやすくなります。
ポーリング処理は仕様どおりに実装する
デバイスコードフローでは、端末側アプリが /token エンドポイントへ繰り返し問い合わせます。ここで短すぎる間隔でポーリングすると、不要な負荷やエラーの原因になります。Microsoft の仕様では、レスポンスに含まれる interval に従い、認証未完了時は authorization_pending を想定して処理します。(Microsoft Learn)
実装では次のような状態遷移を用意します。
| 状態 | UI表示例 | アプリ側処理 |
|---|---|---|
| 認証待ち | 「スマートフォンで認証を完了してください」 | interval に従ってポーリング |
| ユーザー拒否 | 「サインインがキャンセルされました」 | ポーリング停止、未認証状態へ戻す |
| 期限切れ | 「コードの有効期限が切れました」 | 新しいコードを発行する導線を表示 |
| ネットワークエラー | 「通信状態を確認してください」 | 一時停止または再試行 |
| 認証成功 | 「サインインしました」 | トークン取得後、アプリ画面へ遷移 |
ユーザーに見えないバックグラウンドで無限に再試行する実装は避けます。ユーザーが理解できる状態表示と、明示的な再試行ボタンを用意する方が安全です。
トークンを「便利な永続ログイン」として扱わない
デバイスコードフローで取得したトークンは、端末の使い勝手を良くする一方で、保存方法を誤るとリスクになります。
特に共有端末では、前のユーザーのセッションが残る事故が起きやすくなります。店舗端末、受付端末、倉庫端末などでは、次の設計を検討します。
- 操作完了後にサインアウトさせる
- 一定時間無操作でローカルセッションを破棄する
- 端末ごとの紛失・廃棄手順を定める
- 管理者が特定端末のセッションを無効化できるようにする
- 端末上に個人情報をキャッシュしすぎない
デバイスコードフローそのものは認証の入口です。実際のアクセス制御は、取得したトークンを受け取る API 側でも必ず検証します。
セキュリティ面で最も注意すべきこと
デバイスコードフローは、正しく使えば便利ですが、攻撃者にとっても悪用しやすい面があります。
Microsoft Security Blog は、デバイスコード認証フローを悪用したフィッシングでは、攻撃者がユーザーにコードを入力させ、ユーザーが気づかないうちに攻撃者側のセッションを承認してしまう可能性があると説明しています。また、必要な場合に限定して許可すること、条件付きアクセスで制御すること、ユーザー教育を行うことが推奨されています。(マイクロソフト)
フィッシング対策は「MFAを入れれば終わり」ではない
デバイスコードフィッシングの厄介な点は、ユーザーが正規のMicrosoftサインイン画面に誘導される場合があることです。つまり、見た目だけでは不審さに気づきにくいケースがあります。
ユーザー教育では、次のような具体的なルールに落とし込みます。
| ユーザーに伝えるルール | 理由 |
|---|---|
| 自分で操作を開始していないコードは入力しない | 攻撃者がコード入力を依頼する可能性がある |
| メールやチャットで送られたコード入力依頼を信用しない | フィッシングの入口になりやすい |
| サインイン画面に表示されるアプリ名を確認する | 想定外のアプリ承認を防ぐ |
| 共有端末では利用後にサインアウトする | セッション残留を防ぐ |
| 不審な認証要求はすぐ管理者へ報告する | トークン悪用を早期に止める |
特にパートナー企業や外部委託先には、自社社員と同じセキュリティ教育が行き届いていない場合があります。アプリ内ヘルプ、初回利用時の注意画面、利用規約、管理者向け導入資料に同じ注意点を入れておくと、運用で迷いにくくなります。
条件付きアクセスと監視を前提にする
IDアーキテクトは、デバイスコードフローを単独の認証機能としてではなく、条件付きアクセスやリスク検知とセットで設計します。
検討すべき項目は次のとおりです。
- デバイスコードフローを許可するアプリを限定する
- 高権限ユーザーには許可しない、または強い条件を付ける
- 国・地域、IP、ネットワーク条件を評価する
- 不審なサインインやトークン利用を監視する
- リフレッシュトークン失効の運用手順を用意する
- サポート窓口が「誤ってコードを入力した」報告を受けた時の手順を決める
Microsoft Security Blog でも、疑わしいデバイスコードフィッシングが見つかった場合には refresh token の取り消しや再認証の強制、リスクベースの条件付きアクセスなどが対策として挙げられています。(マイクロソフト)
External ID の他の更新と合わせて見るべき理由
2026年3月の Microsoft Entra 更新では、External ID 関連としてデバイス承認付与フローだけでなく、Just-In-Time パスワード移行、ユーザー名またはエイリアスによるサインイン、カスタム禁止パスワードリスト、client credentials、アプリベースのブランディング、セッション制御の条件付きアクセスなども案内されています。(TECHCOMMUNITY.MICROSOFT.COM)
これは、External ID が単に「外部ユーザーをログインさせる機能」から、より実運用に近い CIAM 基盤へ拡張されている流れと見られます。
たとえば、次のような組み合わせが考えられます。
| 要件 | 関連するExternal ID機能 | 実務での意味 |
|---|---|---|
| 既存B2C基盤から移行したい | Just-In-Time パスワード移行 | 初回サインイン時に移行負荷を下げる |
| 会員番号でログインさせたい | ユーザー名/エイリアスサインイン | メールアドレス以外の識別子を使える |
| テレビや端末からログインさせたい | device authorization grant flow | 入力制約のある端末に対応しやすい |
| サービス間連携をしたい | client credentials | ユーザーなしのAPI連携を設計できる |
| アプリごとに見た目を変えたい | アプリベースのブランディング | 複数ブランドや複数サービスに対応しやすい |
| セッションを制御したい | 条件付きアクセスのセッション制御 | サインイン頻度や永続セッションを調整できる |
External ID を採用済み、または Azure AD B2C からの移行を検討している場合は、デバイスコード対応だけを単体で評価するのではなく、外部ID基盤全体の設計見直しとして扱うのが現実的です。
なお、Microsoft のFAQでは、Microsoft Entra External ID は Azure AD B2C の単なる名称変更ではなく、次世代の CIAM ソリューションとして説明されています。また、Azure AD B2C の新規購入は2025年5月1日からできなくなり、既存顧客は少なくとも2030年5月まで利用を継続できると案内されています。(Microsoft Learn)
導入前のチェックリスト
デバイスコードフローを本番導入する前に、開発チームとID管理チームで次の項目を確認します。
要件確認
| 確認項目 | 判断基準 |
|---|---|
| 入力制約が本当にあるか | 通常のブラウザーログインで十分なら採用しない |
| 対象ユーザーは誰か | 顧客、パートナー、管理者を分けて考える |
| 対象端末は何か | 個人端末、共有端末、無人端末で設計が変わる |
| 認証後に何を許可するか | APIスコープと業務権限を最小化する |
| サインアウト要件はあるか | 共有端末では特に重要 |
実装確認
| 確認項目 | 実装のポイント |
|---|---|
| デバイスコード表示 | アプリ名、目的、期限、注意文を表示する |
| ポーリング | interval を守り、エラー状態を正しく処理する |
| トークン保存 | OSの安全なストアや暗号化を検討する |
| ログ出力 | トークン、コード、個人情報を出さない |
| 再認証 | 期限切れ、拒否、失効時の導線を用意する |
| サポート | 端末ID、ユーザーID、時刻で調査できるようにする |
セキュリティ確認
| 確認項目 | 対策 |
|---|---|
| フィッシング対策 | 身に覚えのないコード入力を禁止する教育を行う |
| 条件付きアクセス | 許可するアプリ、ユーザー、場所を絞る |
| 高権限ユーザー | 原則として利用を制限する |
| 監査ログ | デバイスコード利用を検知・調査できる状態にする |
| インシデント対応 | トークン失効、再認証、端末無効化の手順を整える |
開発者がすぐに着手すべき実装ステップ
まずは小さく検証し、端末体験とセキュリティレビューを同時に進めるのが安全です。
検証環境でフローを動かす
最初に、External ID の外部テナントで対象アプリを登録し、必要なユーザーフローやIDプロバイダー設定を確認します。外部テナントでは、メールとパスワード、メールワンタイムパスコード、Facebook、Google、Apple、Microsoft Entra ID federation、カスタム OIDC、SAML/WS-Fed などのサインイン方法が用意されています。(Microsoft Learn)
検証では、いきなり本番アプリへ組み込まず、最小構成のサンプルアプリで次を確認します。
/devicecode要求が成功するか- 表示されたコードでサインインできるか
/tokenのポーリングが正しく動くかauthorization_pendingやexpired_tokenを処理できるか- 必要な scope だけで API を呼び出せるか
UXレビューを行う
デバイスコードフローは、認証プロトコルの正しさだけでなく、ユーザーの誤操作を防げるかが重要です。
レビューでは、次のような観点で画面を確認します。
- どのアプリにサインインしているか分かるか
- 自分が開始した操作だと分かるか
- コードの有効期限が分かるか
- キャンセル方法が分かるか
- 期限切れ時に次の操作が分かるか
- 不審なコード入力依頼への注意があるか
スマートテレビのような大画面と、CLIのようなテキストUIでは、適切な表示内容が異なります。UXレビューは端末種別ごとに行うべきです。
セキュリティレビューを本番前に必ず通す
本番導入前には、少なくとも次の観点でレビューします。
- デバイスコードフローを使うアプリ登録が限定されているか
- 不要な API 権限が付与されていないか
- 管理者や高権限ユーザーが対象に含まれていないか
- 条件付きアクセスの対象になっているか
- 監査ログで追跡できるか
- 端末紛失時に無効化できるか
- ユーザーが誤ってコード入力した場合の対応が決まっているか
特に外部ユーザー向けサービスでは、セキュリティ事故が起きた場合の説明責任が重くなります。リリース直前に慌ててレビューするのではなく、設計段階からID管理チームを巻き込む方が手戻りを減らせます。
まとめ：デバイスコード対応は「端末拡張」と「攻撃面管理」を同時に考える
Microsoft Entra External ID の device authorization grant flow 対応により、コンシューマーやパートナー向けアプリは、スマートテレビ、IoT機器、プリンター、CLI、共有端末などへサインイン体験を広げやすくなりました。通常のログインフォームを端末側に無理に実装しなくても、ユーザーはスマートフォンやPCのブラウザーで認証を完了できます。
ただし、デバイスコードフローは便利な反面、フィッシングに悪用されるリスクもあります。導入判断では、入力制約が本当にあるか、対象ユーザーと端末を限定できるか、スコープを最小化できるか、条件付きアクセスや監視を組み込めるかを確認してください。
次に取るべき行動は明確です。まず対象シナリオを「コンシューマー端末」「パートナー向けツール」「無人のマシン間通信」に分け、デバイスコードフローが必要なものだけを抽出します。そのうえで、検証用アプリ登録、最小スコープ、UX文言、条件付きアクセス、インシデント対応手順をセットで設計しましょう。認証フローの追加ではなく、外部ID基盤の利用範囲を広げる設計変更として扱うことが、実務で失敗しない進め方です。
コメント