Microsoft Entraの「General Availability: Refresh Token (RT) Transfer to Apple Watch in Microsoft Entra External ID Native Authentication」は、Apple Watchなどのコンパニオンデバイスでも認証済み状態を継続しやすくするための更新です。結論から言うと、iOSアプリでサインインしたユーザーのリフレッシュトークンを、開発者が明示的に有効化したうえでApple Watch側へ安全に渡し、Watchアプリ単独でもアクセストークンを更新できるようになります。(Microsoft for Developers)
この更新は、Apple Watch対応アプリを開発しているチーム、Microsoft Entra External IDで顧客向け認証を設計している管理者、CIAMアプリのロードマップを追っているプロダクト担当者にとって重要です。ただし「便利になったからリフレッシュトークンを広く配ってよい」という話ではありません。リフレッシュトークンは長く使える資格情報であり、保存・転送・失効処理まで含めて設計する必要があります。(Microsoft Learn)
General Availability: Refresh Token (RT) Transfer to Apple Watch in Microsoft Entra External ID Native Authenticationで何が変わったか
今回のGAは、Microsoft Entra External IDのNative Authenticationを使うアプリで、Apple Watchのようなコンパニオンデバイスにリフレッシュトークンを転送するシナリオが正式に扱えるようになった、という位置づけです。Microsoftの公式ブログでは、Apple WatchがiPhoneとの常時接続に依存せず、必要に応じてアクセストークンを更新できる点が強調されています。(Microsoft for Developers)
従来は、MSALがリフレッシュトークンを内部で管理し、アプリケーションコードへ返さない設計が基本でした。これはセキュリティ上は自然な設計ですが、Apple Watch側がAPIへ継続アクセスしたい場合、iPhoneに接続できないタイミングでトークン更新ができないという課題がありました。今回の更新では、開発者が明示的にオプトインした場合に限り、リフレッシュトークンを取得し、Apple Watch側へ安全に転送する実装が可能になります。(Microsoft Learn)
| 観点 | 従来の課題 | GA後にできること |
|---|---|---|
| Apple Watch側のAPIアクセス | アクセストークン期限切れ後、iPhone接続や再認証が必要になりやすい | Watch側でリフレッシュトークンを使い、アクセストークンを更新できる |
| ユーザー体験 | Watchアプリ利用中に認証切れや再ログインが発生しやすい | 一度サインインした状態を複数サーフェスで継続しやすい |
| 開発者の実装 | 非公式な回避策や独自転送に頼るリスクがある | 明示的な設定とセキュリティガイダンスに基づいて実装できる |
| セキュリティ管理 | トークンの扱いがチームごとにばらつきやすい | 保存、転送、失効、ローテーションを前提に設計できる |
そもそもNative Authenticationとリフレッシュトークンとは
Microsoft Entra External IDのNative Authenticationは、モバイルアプリやデスクトップアプリのサインイン画面を、ブラウザーリダイレクトではなくアプリ内のUIとして作り込める仕組みです。Microsoft Learnでは、ブランドに合わせた認証画面を作れる一方で、開発チーム側が安全なトークン処理や通信を実装する責任を持つことが説明されています。(Microsoft Learn)
ここで重要になるのが、アクセストークンとリフレッシュトークンの違いです。
| 種類 | 主な役割 | 実務上の注意点 |
|---|---|---|
| アクセストークン | APIや保護されたリソースへアクセスするために使う | 有効期間は比較的短く、漏えい時の影響時間を抑えやすい |
| リフレッシュトークン | アクセストークンが期限切れになったとき、新しいトークンを取得するために使う | 長く使える資格情報なので、漏えい時の影響が大きい |
| IDトークン | ユーザー情報やサインイン状態の確認に使う | API認可のためのトークンとして扱わない |
Microsoftのドキュメントでは、リフレッシュトークンはユーザーとクライアントの組み合わせにバインドされ、Microsoft IDプラットフォームのみが読み取れる形で暗号化されると説明されています。また、使用するたびに新しいリフレッシュトークンへ置き換えられる一方、古いリフレッシュトークンが自動的に失効するとは限らないため、新しいトークン取得後に古いものを安全に削除する必要があります。(Microsoft Learn)
どのようなアプリに影響するか
この更新の価値が大きいのは、Apple Watch側が単なる通知表示ではなく、認証済みユーザーとしてAPIへアクセスする必要があるアプリです。たとえば、フィットネス、ヘルスケア予約、会員向けポイント、車両連携、配送・現場作業、金融系の軽量操作など、iPhoneを取り出さずにWatch側で処理を完結させたいケースが考えられます。
ただし、すべてのApple Watch対応アプリでリフレッシュトークン転送が必要になるわけではありません。Watch側が表示だけを行い、認証済みAPIアクセスをほとんど必要としないなら、リフレッシュトークンを持たせない設計のほうが安全です。判断基準は「Watch側がiPhone非接続時にも、ユーザー本人としてAPIへ継続アクセスする必要があるか」です。
| アプリの状況 | RT Transferの必要性 | 判断のポイント |
|---|---|---|
| Watchは通知や簡易表示だけ | 低い | iPhone側の処理結果を表示するだけなら不要な場合が多い |
| Watch単独でAPIから最新データを取得する | 高い | アクセストークン期限切れ後も継続利用できる設計が必要 |
| Watchで決済、予約、状態変更などを行う | 高い | 認可、監査ログ、失効処理まで慎重に設計する |
| セキュリティ要件が非常に高い業務アプリ | 要検討 | 利便性より、端末紛失時のリスク評価を優先する |
管理者・開発者・プロダクト担当者が見るべきポイント
管理者は「許可してよいアプリ」を絞る
Microsoft Entra管理者は、リフレッシュトークン転送を単なる開発機能として見ないほうがよいです。これは、認証セッションを別デバイスへ広げる設計変更です。どのアプリが対象なのか、Apple Watch側でどのAPIへアクセスするのか、サインアウト時にすべてのデバイスからトークンを削除できるのかを確認する必要があります。
特に、顧客向けアプリであっても、アカウント情報、決済、個人データ、位置情報、医療・健康関連データなどを扱う場合は、トークンの保存場所と削除フローをレビュー対象に含めるべきです。
開発者は「取得・転送・保存・失効」を一連の処理として実装する
開発者が最初に確認すべきなのは、MSAL Native Authenticationでリフレッシュトークンを返す設定を明示的に有効化しているかです。Microsoft Learnでは、MSALNativeAuthGetAccessTokenParametersのreturnRefreshTokenをtrueに設定する例が示されています。(Microsoft Learn)
let parameters = MSALNativeAuthGetAccessTokenParameters()
parameters.returnRefreshToken = true
result.getAccessToken(parameters: parameters, delegate: self)ただし、このコードだけで実装が完了するわけではありません。iOS側で取得したリフレッシュトークンをApple Watchへ渡す転送経路、Watch側での暗号化保存、トークン更新時の差し替え、サインアウト時の削除、失効時の再サインイン誘導まで含めて設計します。
プロダクト担当者は「Watchで完結する体験」を再設計できる
プロダクト面では、Apple Watchアプリを「iPhoneアプリの付属品」から「認証済みの小さな独立画面」として設計しやすくなります。たとえば、ユーザーがジムでiPhoneをロッカーに置いたまま、Watchだけで会員ステータスを確認する。車両アプリでWatchから状態確認や軽い操作を行う。サポートアプリでチケット状況をすばやく確認する。こうした体験が現実的になります。
一方で、Watchでできることを増やしすぎると、端末紛失時や共有端末利用時のリスクも増えます。Watch側では「確認はできるが高リスク操作は追加確認を求める」など、操作の重要度に応じた体験設計が必要です。
実装の基本ステップ
公式ブログでは、Apple Watchへのリフレッシュトークン転送を有効にする流れとして、External IDテナントでNative Authenticationを構成し、RTアクセスを明示的に有効化し、安全な転送とトークンのローテーション・失効・保存を実装することが示されています。(Microsoft for Developers)
| ステップ | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | Microsoft Entra External IDテナントでNative Authenticationを構成する | 通常のブラウザー委任認証とNative Authenticationの前提を混同する |
| 2 | 対象アプリでRTアクセスを明示的に有効化する | すべてのアプリに一律許可してしまう |
| 3 | iOSアプリでサインイン後にRTを取得する | ログ出力やデバッグ出力にトークンを含めてしまう |
| 4 | Apple Watchへ安全に転送する | 転送経路の暗号化や端末状態の検証を軽視する |
| 5 | Watch側で安全に保存する | 平文保存、不要な複製、バックアップ対象への混入が起きる |
| 6 | トークン更新・ローテーションを実装する | 新しいRT取得後に古いRTを削除しない |
| 7 | サインアウト・失効・端末紛失時の処理を実装する | iPhone側だけサインアウトし、Watch側の認証状態が残る |
| 8 | iPhone非接続、通信断、期限切れ、失効をテストする | 通常時だけ動作確認し、障害時の再認証導線を見落とす |
セキュリティ設計で必ず押さえるべき注意点
リフレッシュトークンは、アクセストークンよりも長く使える資格情報です。Microsoftのドキュメントでも、リフレッシュトークンは安全に保存する必要があり、期限切れ前に取り消される可能性もあるため、アプリ側で再認証フローを適切に処理する必要があると説明されています。(Microsoft Learn)
| 注意点 | 実務での対策 |
|---|---|
| RTを不要なアプリで取得しない | Watch単独アクセスが必要なアプリだけに限定する |
| RTをログに出さない | デバッグログ、クラッシュログ、分析基盤への送信を禁止する |
| RTの複製を増やさない | iPhone、Watch、バックエンドなど保存場所を最小化する |
| 新しいRT取得後に古いRTを残さない | 更新成功後の削除処理を必ず実装する |
| サインアウト時にWatch側を消し忘れない | iPhoneとWatchの両方でトークン削除を行う |
| 失効時のUXを用意する | APIエラー時に無限リトライせず、再サインインへ誘導する |
| 端末紛失を想定する | アカウントからのセッション無効化、再認証、監査ログを確認する |
また、トークン有効期間を管理ポリシーで自由に短縮すれば解決する、という単純な話でもありません。Microsoft Learnでは、アクセストークン、IDトークン、SAMLトークンの有効期間ポリシーは構成できる一方、リフレッシュトークンとセッショントークンの有効期間はトークン有効期間ポリシーでは構成できず、サインイン頻度の制御にはConditional Accessの利用が案内されています。(Microsoft Learn)
直近のSSO GAとの違いを整理する
今回のRT Transferは、同時期に発表された「Native Apps to Embedded Web Views」のSSO GAと混同しやすい更新です。2026年4月23日のSSO GAは、ネイティブアプリ内でサインインしたユーザーを、同じアプリ内の埋め込みWebビューへ二重ログインなしでつなぐためのものです。アプリがアクセストークンを取得し、WebビューのHTTPリクエストへAuthorization: Bearer <access_token>を渡す流れが説明されています。(Microsoft for Developers)
一方、2026年4月29日のRT Transferは、iOSアプリからApple Watchのようなコンパニオンデバイスへリフレッシュトークンを渡し、Watch側が独立してアクセストークンを更新できるようにする更新です。前者は「ネイティブ画面から埋め込みWeb画面へのSSO」、後者は「iPhoneアプリからApple Watchへの認証継続」と捉えると分かりやすいです。(Microsoft for Developers)
| 比較項目 | Embedded Web Views向けSSO | Apple Watch向けRT Transfer |
|---|---|---|
| 主な対象 | アプリ内Webビュー | Apple Watchなどのコンパニオンデバイス |
| 目的 | ネイティブ画面からWeb画面へ再ログインなしで遷移 | Watch側で認証済みAPIアクセスを継続 |
| 使う中心的なトークン | アクセストークン | リフレッシュトークン |
| 主な価値 | アプリ内のWebコンテンツ体験を滑らかにする | iPhone非接続時でもWatchアプリを動かしやすくする |
| 注意点 | Webリソース側のトークン検証とセッション確立 | RTの保存、転送、失効、ローテーション管理 |
導入前に確認すべきチェックリスト
RT Transferを採用する前に、まず次の質問に答えると判断しやすくなります。
| 確認項目 | 採用判断の目安 |
|---|---|
| Apple Watch側がiPhone非接続時にもAPIアクセスする必要があるか | 必要ないならRT転送は見送る |
| Watch側で扱うデータは高リスクか | 高リスクなら操作制限や追加確認を検討する |
| サインアウト時に全デバイスからトークンを削除できるか | できない場合は実装を見直す |
| RT更新後に古いRTを削除できるか | できない場合はローテーション設計が不十分 |
| 失効・期限切れ・通信断のテストケースがあるか | ない場合は本番導入前に追加する |
| ログや分析基盤にトークンが流れないか | ログ設計とマスキングを確認する |
最初にやるべきことは、Apple Watch側で本当に認証済みAPIアクセスが必要なユースケースを洗い出すことです。必要な場合は、Native Authenticationの構成、RT取得のオプトイン、WatchConnectivityなどを使った安全な転送、Watch側の保護された保存、サインアウト時の削除、失効時の再認証までを1つの認証ライフサイクルとして設計します。
今回のGAは、Microsoft Entra External ID Native Authenticationを使うCIAMアプリにとって、マルチデバイス体験を実装しやすくする前進です。ただし、リフレッシュトークンをApple Watchへ渡すことは、ユーザー体験の改善と同時に攻撃面の拡大も意味します。導入の可否は「便利だから」ではなく、「Watch単独で動く価値があり、そのリスクを設計で抑えられるか」で判断するのが安全です。
コメント