Power Pages を Microsoft Entra External ID(旧 Azure AD External Identities/CIAM)と連携すると、「IdP(トークン)」と「サイト(Cookie)」の2層でセッションが動きます。本記事はその責任分界と具体的な設定場所、メール OTP 利用時に話題となる“12 時間で再サインインが必要になる”現象の整理、そして実務で採れる回避策までを、手順・キー名・検証ポイント込みで徹底的に解説します。
全体像:セッション管理は「Entra External ID」と「Power Pages」の二層
Power Pages でのサインインは OIDC を用いるため、トークンの寿命(Access/ID/Refresh)は IdP 側(Entra External ID)が決め、アイドルタイムアウト(未操作自動ログアウト)はサイト側(Power Pages)が Cookie で制御します。両者は独立しており、どちらか一方だけを調整しても体験は最適化されません。
| 管理ポイント | 主な役割 | 既定値/制約(要点) | 設定場所(要点) |
|---|---|---|---|
| Entra External ID(IdP) | Access/ID/Refresh トークンの寿命、MFA の方式 | Access トークン:60–90 分(平均 75 分)で変動(CAE 等の例外あり) Refresh トークン:非 SPA は既定 90 日(SPA は 24 時間) Refresh/Session は CTL(Configurable Token Lifetime)では変更不可 | (必要時)Configurable Token Lifetime で ID/Access/SAML は個別に調整可 外部テナント(Customers/CIAM)の MFA 二要素は メール OTP と SMSがサポート対象 |
| Power Pages(サイト) | 未操作の検知/強制ログアウト、トークン寿命との同期 | アイドルタイムアウトは任意に設定可 「Use token lifetime」をオンにすると IdP の寿命を優先 | Site Settings:Authentication/ApplicationCookie/ExpireTimeSpan 等 OpenID Provider 設定:Use token lifetime を有効化可 |
Access トークン既定の 60–90 分変動および CTL の対象外/対象の区分、Refresh トークン既定(非 SPA 90 日/SPA 24 時間)は Microsoft 公式仕様に基づきます。
まず押さえる:トークン種別と「体験」に効く箇所
- Access トークン:API 呼び出し用の短命トークン。失効後は Refresh で静かに更新。
- ID トークン:サインイン情報(クレーム)を含む。アプリのセッション開始に使われる。
- Refresh トークン:再認証無しで Access/ID を取り直すための長命トークン。失効するとサインイン UI が必要。
- ブラウザー Cookie(アプリセッション):サイトが保持するログイン状態。Power Pages の
ApplicationCookieの寿命やスライディング更新が体験に直結。
Entra External ID 側:既定・調整可否・よくある誤解
既定のトークン寿命(要点)
- Access トークンは60–90 分(平均 75 分)でランダム化。負荷分散のため仕様で変動します。
- Refresh トークンは非 SPA 90 日/SPA 24 時間が基本。刷新時に新しい Refresh が再発行されローテーションします。
- CTL でAccess/ID/SAMLの寿命は調整できる一方、Refresh/セッショントークンは対象外です。
External ID(Customers/CIAM)の MFA で選べるもの
外部テナント(Customers/CIAM)における二要素は メール OTP と SMS がサポート対象です。Authenticator や FIDO2 は現時点の公式機能一覧には含まれていません。したがって「FIDO にすると 90 日になる」といった言い回しは、Customers/CIAM の前提では誤解を招きます。
「サインイン頻度(Sign‑in frequency)」は External ID で効くのか?
Entra の条件付きアクセス(CA)にはセッション制御として「サインイン頻度」がありますが、External ID(Customers/CIAM)では UI が無効化されている/適用できないとの報告が散見されます。少なくとも 2024–2025 年の時点で「External テナントで頻度を細かく制御できない」事例が Q&A で確認されています。したがって、Power Pages の Cookie 側で体験を整えるのが現実解です。
Power Pages 側:アイドルタイムアウト(自動ログアウト)の実装
管理アプリで編集する場所
- Power Platform 管理センターから対象環境を開く → Portal Management(Portal 管理アプリ) を起動。
- Site Settings エンティティに以下のキーを作成/調整します。
| Site Setting 名 | 役割 | 値の例 | 備考 |
|---|---|---|---|
Authentication/ApplicationCookie/ExpireTimeSpan | 未操作での自動ログアウトまでの時間 | 00:10:00(10 分) | HH:MM:SS 形式。スライディング更新の有無と併せて設計。 |
Authentication/ApplicationCookie/SlidingExpiration | 有効期限のスライディング更新 | true / false | 既定 true(中間操作で延長)。厳格な業務では false も検討。 |
Authentication/OpenIdConnect/<provider>/UseTokenLifetime | Cookie の寿命を IdP のトークン寿命に同期 | true | オンにすると ExpireTimeSpan よりトークン寿命が優先されます。 |
Power Pages の OpenID Connect 設定画面にも「Use token lifetime」があり、オンにすると Application Cookie Expire Timespan を上書きして IdP の寿命に追随します。トークン側が短い環境(Access 60–90 分)では、サイト側だけを延ばしても再発行ができず結局サインインを求められるため、業務要件に応じて両者を整合させてください。
質問 1:
「どこで」セッション(トークン)とアイドルタイムアウトを設定する?
- トークン寿命は Entra External ID 側で決まります。Access は 60–90 分、Refresh は(非 SPA)90 日が基本。CTL で Access/ID は延長・短縮できるが、Refresh は不可。
- アイドルタイムアウトは Power Pages 側の
ApplicationCookieで制御。ExpireTimeSpan、SlidingExpiration、必要に応じて「Use token lifetime」を組み合わせます。
質問 2:
「パスワード + メール OTP(二要素)」採用で Refresh トークン寿命はどう変わる?
仕様上は「直接は変わりません」。Refresh の基本は「非 SPA 90 日/SPA 24 時間」です(サインイン方式や MFA の種類それ自体が Refresh 寿命を短縮する、という公式仕様はありません)。ただし External ID で OTP を絡めたフロー(特にネイティブ認証や OTP を主要因とするサインイン)では、実効寿命が 12–24 時間に収束する現象が広く報告されています。これは “非アクティブ 12:00:00(AADSTS700082)で失効”として検知されるもので、2024–2025 年の Q&A でも話題になりました。現時点では管理者が任意に延長する手段は公開されていません。
質問 3:
「12 時間失効」を避けるために Email OTP を無効化/削除できる?
External ID(Customers/CIAM)での考え方
- 一次要素=メール OTPを使っている場合:ユーザーフローの「ローカル アカウント方式」を「Email with password」へ切替することで、サインイン主因から OTP を外せます。そのうえで MFA(二要素)として OTP か SMSを構成します(一次要素を OTP にした場合は二要素に OTP を重ねられません)。
- 二要素(MFA)=メール OTPを止めたい場合:Authentication methods(認証方法ポリシー)で「Email one-time passcode」を対象ユーザーから外す/無効化します(代替として SMS を有効化)。OTP をすべて外す前に、全ユーザーに代替の二要素が行き渡っていることを必ず検証してください。
B2B(ゲスト)での明示的な無効化手順
- Entra 管理センター → External Identities → All identity providers → Email one‑time passcode
- Allow guests to use one‑time passcode を Off にして保存(必要に応じて Redemption のリセットも考慮)
この手順は Microsoft の公式ガイダンスとして提供されており、OTP を切ると既存の OTP 依存ユーザーはサインインできなくなる点に注意が必要です(再招待/救済が必要)。
実務パターン:要件別のおすすめ構成
| 要件 | External ID(一次要素) | MFA(二要素) | Power Pages 側の要点 | 備考 |
|---|---|---|---|---|
| できるだけ長くログイン維持(業務アプリ) | Email with password | SMS(または必要な範囲でメール OTP) | Use token lifetime=true/Cookie は Access より短くしない | Refresh は 90 日(非 SPA)。OTP を主因にしない方が無難。 |
| パスワードレス志向/メールだけで手軽に | Email one‑time passcode | (二要素は SMS のみ可) | Cookie は短め(例:15–30 分)+スライディング有効 | OTP 主因は 12–24 時間での再サインイン報告が多い。業務 UX に注意。 |
| 高リスク操作は都度強い再認証 | Email with password | SMS または OTP | 高権限ページは Power Pages 側でセッション短縮や再認証リンクを実装 | External ID の CA セッション制御が使えない場面があるためアプリ側で補完。 |
設定手順(ダイジェスト)
Power Pages:アイドルタイムアウトと遷移
- Portal Management → Site Settings に以下を登録
Authentication/ApplicationCookie/ExpireTimeSpan:00:10:00などAuthentication/ApplicationCookie/SlidingExpiration:trueAuthentication/OpenIdConnect/<provider>/UseTokenLifetime:true
- (任意)タイムアウト時の遷移先:
Authentication/ApplicationCookie/LoginPathに/SignIn等を設定
ApplicationCookie 系キーはポータルの定番で、ExpireTimeSpan と SlidingExpiration の組み合わせで UX が大きく変わります。
External ID(Customers/CIAM):ユーザーフローと MFA
- External Identities → User flows → 対象フローを開く
- ローカル アカウントの方式を
- 長期維持重視:「Email with password」 を選択(一次要素を OTP にしない)
- パスワードレス重視:「Email one‑time passcode」(ただし UX は前述の注意点)
- MFA は管理センターの Authentication methods で対象ユーザーに対し Email OTP / SMS を有効化(または OTP を除外)
External テナントで二要素に選べるのはメール OTP と SMS であり、Authenticator や FIDO2 は現時点のサポートに含まれていません。
“12 時間で失効する”現象の詳細と向き合い方
モバイルアプリやネイティブ認証サンプルを基にした OTP サインインでは、Refresh が 12:00:00 の非アクティブで失効し、毎日サインインが必要になるという報告が複数あります。これは仕様・バグのいずれにせよ、管理者が設定で延ばせる類ではありません。Power Pages の Web では OIDC/PKCE によるリフレッシュが可能でも、IdP 側が Refresh を失効させたら UI リダイレクトは不可避です。
回避と緩和の具体策
- OTP を一次要素にしない(ユーザーフローを Email with password に変更)+ 必要なら MFA を SMS で実施。
- どうしても OTP 主因が前提のときは、Power Pages 側で「セッション残り時間の可視化」と「グレース再認証(サインイン画面へ早めのソフト遷移)」を実装。
- B2B で OTP を使わせたくない場合はIdP 側で OTP 自体をオフにして、MSA/Entra/Federation に誘導。
テスト計画:本番前に必ず確認したい 8 項目
- ブラウザーでログイン → 放置 → Access 失効(60–90 分)前後のリフレッシュ挙動を確認(サイレント更新の有無)。
- Cookie の
ExpireTimeSpanを Access より短くしない構成/Use token lifetime 有効時の上書き挙動を確認。 - OTP 主因/MFA 変更時の UX(メール遅延、SMS 料金、再試行回数)を負荷試験。
- Refresh 失効後の画面遷移(
/SignIn等)と入力保持(ReturnUrl)の有無を確認。 - スライディング更新オン/オフでの稼働時間分布を収集し、最適解を決める。
- ユーザーフロー変更(Email with password ⇔ OTP)時の移行手順(既存ユーザーの再サインイン影響)を検証。
- 管理センターのサインインログで AADSTS700082(非アクティブで失効)の発生を監視。
- 外部ユーザーを含む E2E(招待/登録/退会)で OTP オフ時の救済動線を確認(B2B)。
よくある落とし穴とアンチパターン
- Cookie だけ延ばす:IdP の Access/Refresh が短いと、サイト側だけ延ばしても結局サインインが走る。
- OTP 主因のまま長期ログインを想定:12–24 時間で再認証が必要になる報告が多く、顧客向けサービスでは離脱要因になりやすい。
- External ID でも CA のサインイン頻度で解決できるという思い込み:少なくとも現時点、外部テナントでは UI が無効化されるケースがあり、制御できない前提で設計する。
- Authenticator / FIDO を前提に設計:Customers/CIAM のサポート対象は OTP/SMS。仕様に沿った MFA 設計が必要。
実装スニペット(Power Pages に軽量追加)
以下は、フロントで活動時間をカウントダウンし、失効 2 分前にダイアログを出す素朴な例です(ビルド済みテーマに合わせて調整してください)。
<script>
(function () {
// サイト設定と合わせて残り時間を設定(例:10分)
var maxIdleMs = 10 * 60 * 1000;
var warnMs = 2 * 60 * 1000; // 2分前に警告
var last = Date.now();
function reset(){ last = Date.now(); }
['click','keydown','scroll','mousemove','touchstart'].forEach(function (e){
document.addEventListener(e, reset, {passive:true});
});
setInterval(function(){
var left = maxIdleMs - (Date.now() - last);
if (left <= warnMs && left > 0) {
if (!window.__ppWarned) {
window.__ppWarned = true;
alert('まもなくセッションが終了します。必要な操作を保存してください。');
}
}
if (left <= 0) {
window.location.href = '/SignIn?ReturnUrl=' + encodeURIComponent(window.location.pathname + window.location.search);
}
}, 1000);
})();
</script>
※ 実環境ではモーダル表示や API の ping でサーバー側のスライディング延長と同期させるなど、UI/UX を洗練させましょう。
チェックリスト(配布用)
- [ ] External ID のユーザーフロー:Email with password or OTP(要件に合わせて選択)
- [ ] MFA 方法:OTP と SMS のどちらを使うか(コスト・体験・セキュリティのトレードオフ)
- [ ] Power Pages:
ExpireTimeSpan/SlidingExpiration/Use token lifetime - [ ] 期待セッション長 <= Refresh 寿命(非 SPA 90 日)で矛盾がないこと
- [ ] OTP 主因の 12–24 時間現象を考慮(必要なら構成変更)
- [ ] B2B の場合は Email OTP を明示的に無効化するか判断(再招待手順も用意)
まとめ:設計原則
Power Pages × Entra External ID のセッションは「IdP のトークン寿命」と「サイトの Cookie 管理」の二層設計で最適化します。長期ログインを重視するなら OTP を主因にしない(Email with password + SMS)構成を基準にし、Power Pages では ExpireTimeSpan/SlidingExpiration を適切に調整。さらに Use token lifetime を活用して IdP と整合させれば、「セキュリティ」と「利便性」を両立できます。Access 60–90 分、Refresh 90 日という基本線に立ち戻り、実運用のログで検証・微調整していくのが最短経路です。
付録:FAQ(運用でよく聞かれるポイント)
Q. Cookie を 8 時間、Access を 60–90 分のままにすると?
Access が切れた時点でサイレント再認証が走りますが、Refresh が失効していればサインイン画面へ戻ります。Cookie 側だけ延長しても、IdP 側の短命さを覆すことはできません。
Q. CA(条件付きアクセス)で「サインイン頻度」を使えばすべて解決する?
現時点で External テナントでは UI が無効化されている報告があり、期待どおりに使えないケースがあります。Power Pages 側の設計で補完してください。
Q. OTP を完全に止めたい(B2B)
All identity providers → Email one-time passcode を Off。既存の OTP ユーザーは再招待が必要です。
Q. OTP を二要素で使えない場面がある?
一次要素が OTP の場合、二要素に OTP は使えません(External テナントの仕様)。SMS を用意しましょう。
構成テンプレート(コピペ用)
Portal Management の Site Settings に以下を登録(例)。
Authentication/ApplicationCookie/ExpireTimeSpan = 00:20:00
Authentication/ApplicationCookie/SlidingExpiration = true
Authentication/ApplicationCookie/LoginPath = /SignIn
Authentication/OpenIdConnect/MyEntra/UseTokenLifetime = true
External ID(Customers/CIAM)のユーザーフロー例:
- Local accounts: Email with password (主因を OTP にしない)
- MFA: SMS を有効化(必要に応じて Email OTP を対象グループから除外)
最後に、本番導入前に必ず長時間の放置テストと、ログ(AADSTS700082 など)の監視を行い、ユーザー体験を数値で確認してください。

コメント