ASWebAuthenticationSession のサインイン確認ダイアログを iOS 27 で確かめた話（2026年版）

はじめに

GMOコネクトの永田です。

アプリから Web のログイン画面を開く設計の相談で、「prefersEphemeralWebBrowserSession を false にすると、ログインのたびに確認のダイアログが出ます」と回答しました。ところが根拠を探しても、最新の iOS について書かれた Apple の一次情報が見つかりませんでした😇

そこで、ASWebAuthenticationSession を開くだけの最小のアプリを作り、iOS 27.0 のシミュレーターで最新の挙動を確かめました。この記事はその記録です。

先にまとめ

既存の情報	出典（時期）	iOS 27.0 のシミュレーターでの結果
true にするとダイアログが出ない	Apple の WWDC19 の動画（2019年）、Auth0.swift の FAQ（2021年作成）	同じ。13回中0回
false では同意のダイアログが出る	Auth0.swift の FAQ	同じ。17回中17回。一度「続ける」を押しても、次のセッションでまた出る
ログアウトでも同じダイアログが出る	Auth0.swift の FAQ	同じ。文言も「サインインのために」のまま
文言は変えられない	Auth0.swift の FAQ	同じ。変わるのはアプリ名とドメインだけ
アプリ名は CFBundleName	AppAuth-iOS の issue（2019年のコメント）	同じ。ホーム画面の表示名（CFBundleDisplayName）は出ない
Info.plist を変えても効かず、Product Name を変える必要があった	同じ issue（2024年のコメント）	Info.plist の自動生成が有効なら同じ。無効なら Info.plist の値が出る
false では Safari と Cookie などを共有する	Apple の WWDC19 の動画とリファレンス	シミュレーターでは、Safari アプリとは共有されなかった。別のアプリのセッションとは共有された

• 既存の情報は、Cookie の共有の範囲を除いて、iOS 27.0 でもそのままでした。ダイアログを消せるのは true だけで、変えられるのはアプリ名とドメインの2か所です
• アプリ名の出どころについて、食い違っていた2つの報告は、Info.plist の自動生成（GENERATE_INFOPLIST_FILE）の有無で両方とも再現できました
• Cookie の共有の範囲は、シミュレーターでは Apple の説明と違って見えました。実機では確かめていません

1. 確かめた条件と最小のアプリ

項目	値
観測日	2026-11-05
Mac	macOS 27.2、Xcode 27.1
シミュレーター	iPhone 18 Pro、iOS 27.0
アプリ	ASWebAuthenticationSession を開くだけの最小のアプリ
ログイン画面の代わり	手元で動かす小さな HTTP サーバー。Cookie を発行してからコールバックの URL に移り、受け取った Cookie を記録する

アプリは、起動時の引数で true と false を切り替えるだけです。

let s = ASWebAuthenticationSession(url: url, callback: .customScheme("dialogtest")) { callback, error in
    NSLog("DIALOGTEST done callback=\(String(describing: callback)) error=\(String(describing: error))")
}
s.presentationContextProvider = self
s.prefersEphemeralWebBrowserSession = ProcessInfo.processInfo.arguments.contains("-ephemeral")
s.start()

2. false では毎回出て、true では出ない

false で始めたセッションは、17回中17回ダイアログが出ました。「続ける」を押した後に同じ起動の中で開き直したセッション、アプリを終了して起動し直したとき、バンドル ID の違う別のアプリ、シミュレーターを再起動した後も、すべて出ています。一度許可しても、次のセッションではまた聞かれました。

ログアウト用の URL（/logout）で開いても、文言は「サインインのために」のままでした。ログアウトの画面を ASWebAuthenticationSession で開くと、利用者には「サインイン」と表示されることになります。

true では、13回中0回でした。タップしなくても、13回ともログイン画面の代わりのサーバーまで届きました。

Apple の現行のリファレンスは、ダイアログを条件なしで説明しています。

When the user starts the authentication session, the operating system shows a modal view telling them which domain the app is authenticating with and asking whether to proceed.
ASWebAuthenticationSession | Apple Developer Documentation

セッションを始めると、OS がモーダルを出して、どのドメインで認証しようとしているかを示し、続けるかを尋ねる、という説明です。true で出なくなることは、prefersEphemeralWebBrowserSession のリファレンスにも解説記事にも書かれていません。確かめた範囲の Apple の資料で、それを言っているのは2019年の WWDC の動画だけでした。

If your app asks for this experience, users won't see this dialog. Instead, they'll be taken directly to the identity provider in order to get signed in. To do this, set the prefersEphemeral WebBrowserSession property on the session to true before starting the session.
What's New in Authentication - WWDC19

true にすればダイアログは出ず、直接ログインの画面に進む、という説明です。iOS 27.0 でも、この説明どおりに動きました。

3. 変えられるのはアプリ名とドメインだけ

ダイアログは次のように表示されました。

文言は次のとおりです。

“DialogTest”がサインインのために“login.example.com”を使用しようとしています。
これを行うと、アプリとウェブサイトにあなたに関する情報を共有することを許可します。
［キャンセル］［続ける］

箇所	出るもの
アプリ名（DialogTest）	アプリの中の Info.plist の CFBundleName。ホーム画面の表示名（CFBundleDisplayName）は出ない
ドメイン（login.example.com）	開く URL のホスト名。サブドメインまでそのまま出る
それ以外の文言とボタン	OS が決めるもので、変えられない

CFBundleName を「DialogTest」、CFBundleDisplayName を「表示名テスト」と別々の値にして確かめました。出たのは「DialogTest」です。CFBundleName だけを書き換えると、ダイアログの名前も変わりました。

AppAuth-iOS の issue 343 では、2019年に「CFBundleName が出る」、2024年に「Info.plist の Bundle name を変えても効かず、Product Name を変える必要があった」と、食い違うコメントが付いていました。そこで、Xcode のプロジェクトで設定を変えてビルドし、アプリの中の値とダイアログの名前を見ました。

設定	アプリの中の CFBundleName	ダイアログの名前
Info.plist の自動生成が有効（新規プロジェクトの既定）、Info.plist のファイルに CFBundleName = PlistName を書く	DialogXc（Product Name）	DialogXc
Info.plist の自動生成を無効（GENERATE_INFOPLIST_FILE = NO）、同じファイルを使う	PlistName	PlistName
自動生成が有効、INFOPLIST_KEY_CFBundleDisplayName で表示名を設定	DialogXc	DialogXc

自動生成が有効だと、ファイルに書いた CFBundleName は Product Name の値で上書きされ、ビルドの警告も出ませんでした。2019年のコメントは自動生成を無効にした場合、2024年のコメントは有効にした場合と同じ結果です。どちらの報告も、設定しだいで再現できました。

Product Name を ProductNameX に変えると、アプリの中の CFBundleName も ProductNameX になりました。アプリのフォルダ名も ProductNameX.app に変わります。

4. false で共有される範囲と、true にしたときに失うもの

Apple は、true の意味を次のように説明しています。

Set prefersEphemeralWebBrowserSession to true to request that the browser doesn’t share cookies or other browsing data between the authentication session and the user’s normal browser session.
prefersEphemeralWebBrowserSession | Apple Developer Documentation

true にすると、認証のセッションと利用者の普段のブラウザの間で Cookie などを共有しない、という説明です。裏返すと、false では普段のブラウザと共有することになります。

そこで、false のときに Cookie がどこまで届くかを、サーバーの記録で確かめました。localhost のサーバーに加えて、外部の https のサイト（httpbin.org）でも試しています。

向き	結果（シミュレーター）
同じアプリの次のセッション	届いた
バンドル ID の違う別のアプリのセッション	届いた（2つのアプリは、どちらも ad-hoc で署名）
アプリのセッションから Safari アプリへ	届かなかった
Safari アプリからアプリのセッションへ	届かなかった
期限の無い Cookie（セッション Cookie）	アプリの間では、シミュレーターを再起動するまで届いた。再起動後は消えた

シミュレーターでは、false のセッションの Cookie は、アプリの間では共有され、Safari アプリとは両方向とも共有されませんでした。Apple の説明と違って見えますが、実機では確かめていません。実機の Safari とシミュレーターの Safari で扱いが違う可能性もあるので、ここは「シミュレーターではこうだった」までにとどめます。

true では、13回とも Cookie は届きませんでした。同じアプリの中で続けて開いたセッションにも、前のセッションの Cookie は届いていません。ダイアログが消える代わりに、前のログインの状態を使えなくなります。

Apple の解説記事は、このトレードオフを次のように書いています。

An ephemeral session may improve security but prevents reusing the result of a previously successful authentication, potentially forcing the user to reenter credentials. As a result, it’s typically best to let the user choose whether to request ephemeral browsing.
Authenticating a user through a web service | Apple Developer Documentation

true は安全性を高めうる一方で、前の認証の結果を使い回せず、資格情報の入れ直しを求めることがあるので、true にするかは利用者に選ばせるのがよい、という説明です。ログインの状態をアプリの間で使い回したいなら false でダイアログを受け入れ、ログインの画面が Cookie を使わない作りなら true にしてダイアログを減らす、という選び方になります。

まとめ

• false では、17回中17回ダイアログが出ました。「続ける」を押した後も、ログアウトの画面でも出ます
• true では13回中0回で、2019年の WWDC の説明どおりでした。ただし、前のログインの Cookie は使えなくなります
• 変えられるのは、アプリ名（CFBundleName）とドメインの2か所だけでした
• Info.plist の自動生成が有効なプロジェクトでは、Info.plist のファイルに CFBundleName を書いても Product Name で上書きされ、ビルドの警告も出ませんでした。ダイアログの名前を変えたいときは、ソースの Info.plist ではなく、ビルドしたアプリの中の Info.plist で値を確かめるのが確実です

---

最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ：https://gmo-connect.jp/contactus/