アプリログインとWeb認証基盤をつなぐ ASWebAuthenticationSession 作法

Transcript

1. iOSDC Japan Day : ~ Track C アプリログインとWeb認証基盤をつなぐ ASWebAuthenticationSession 作法 0 3 3 1 3 2 1 / / 9 6 6 2 2 0 0 2 2 Go Takagi
2. ‣ ID • shimastripe / shimastriper ‣ Work • 本経済新聞社 ‣ Like • Swift / 動化 / 柴 ‣ 過去 fi fi 犬 • In App Purchase / UIContentCon guration / PencilKit / Background Noti cation 自 日 2 Me ( Go Takagi )
3. ‣ システムが提供する認証 ブラウザセッション 行 • アプリ内でWebサービスを介して ユーザーのログイン認証や OAuth 認可を 用 3 ASWebAuthenticationSession う
4. 4 安全な場所で認証し、callback してアプリへ ASWebAuthentication Login Successful 認可コードリダイレクト (callback) callback URL 例 myapp://callback?code=Sqplfeijeiwjig &state=xyz
5. ブラウザを介することで、秘密情報を保護 ‣ アプリが介在できない場所でログインさせる • 認証に いるユーザーの秘密情報を奪取させない • パスワード、One time password, etc • 特に rd party の IdP (Identity Provider) で認証をする場合に重要 • Google, Facebook, Microsoft, • 知らないアプリでログインする際もユーザーへ安全ですと伝えるサイン • WKWebView では JavaScript の実 や操作ログが取得できてしまう • ユーザーにリスクがあるフローになる 1. 認証URLを開く 行 … … 用 用 ASWebAuthenticationの callback へ渡る 3 5 認証 2. 認証リクエスト ( /authorize ) 3.リダイレクト (callback URL + code) 認可サーバー
6. : OAuth . for Native Apps ‣ ネイティブアプリの安全な authorization request を規定 • 実 時には外部ユーザーエージェントを介して • うこと 般的にはブラウザ • embedded user-agentを使ってはならない • いわゆる WebView • ブラウザからアプリに戻ってくる callback 法には https の URL を優先する • myapp:// のようなローカル(Private-use)URLScheme を避ける • st party ( 社のID)においても最 権限をアプリに与えられるため推奨、まで記載 行 方 0 2 小 2 5 2 8 2 5 2 自 8 https://www.rfc-editor.org/info/rfc 行 一 1 6 RFC /
7. 7 1. 認証URLを開く ASWebAuthenticationの callback へ渡る 2. 認証リクエスト ( /authorize ) 3.リダイレクト (callback URL + code) 認可サーバー
8. ‣ OAuth/OIDCで広く使われる認可フロー 外部ユーザーエージェント クライアント 認可サーバー 認可URLを開く 認可要求 Authorization Code Redirect: callbackURL?code=Sci 成 callbackURL+Authorization Code Authorization Code 取得完了 クライアントがタッチできないようにする Authorization Code を いてToken Request Token Response 成 Token Response（Access Token / ID Token※） … 用 生 ※IDTokenはOIDC認証の場合 生 8 Authorization Code Flow
9. : disallowed_useragent ‣ • Google can't sign you in safely inside this app. You can use Google sign-in by visiting this app's website in a browser like Safari or Chrome. • を読み取ることができる組み込み WebView 上の認証をブロックしてる https://developers-jp.googleblog.com/ / /modernizing-oauth-interactions-in-native-apps.html ff ff 9 0 6 1 0 2 3 力 https://developers.googleblog.com/guidance-to-developers-a ected-by-our-e ort-to-block-less-secure-browsers-and-applications 0 4 入 9 Google は WebView 上 OAuth request を block
10. 0 1 なので ASWebAuthenticationSession 使おうね！
11. 完
12. もうちょっとこう...
13. ‣ 本能的にはなるべくネイティブにしたい • ネイティブが常に正解とは限らない、でも何故 Web に寄せるのか？ • UXだけでなく、安全性 運 性 拡張性まで含めて考える • 認証 式ごとに「アプリに任せること / 外に任せること」が違う ‣ 認証はアプリだけでは完結しない • 登場 物が多い • 発表の都合上省略するところもあるので引 から正確な定義も参照してください • Native / Web、それぞれの役割とトレードオフ を理解して 用 ・ 用 分たちの要件に対してのアプローチをぜひ持ち帰ってください ・ 人 方 • 3 1 自 アプリエンジニアとしてもう少し線引きを学びたい
14. 用 改善と運
15. 認可の改善はとても頻繁にある ‣ ID, Password, Submit!完成!! • で済まない時代…!!! ‣ 3つの観点で てみる • 体験フローの改善 ( 当 認証 ・ ・ 人 身 まっている脅威、攻撃への対策 ・ 見 • 確実に 高 元確認 認可付与) rd party IdP (Identity Provider) 対応追加 ・ • 5 3 1 前提: 認証 終了
16. 式: Passkey ‣ パスワードに代わる認証 式 • FIDO (WebAuthn) に基づく公開鍵暗号 • 体認証や端末 PIN で Passkey の利 式を いた認証 を承認 • ログイン時は秘密鍵そのものではなく、サーバーからの Challengeに対する署名だけがサービスへ渡る • 秘密鍵そのものをサービスに渡さないからパスワードより安全 • 資格情報がサービスに紐づく強いフィッシング耐性 https://developer.apple.com/jp/passkeys/ 用 方 用 3 6 2 0 方 1 3 2 0 2 方 2 https://developer.apple.com/jp/videos/play/wwdc 6 生 1 次世代認証 / /
17. ‣ OTP (One time password) 認証の拡張、番号有効性チェックの洗練 • SMS を受信する代わりに、端末が契約してる携帯通信会社が検証して認証 • タップして待てば 動認証。番号を打つ”あの” 間がない • Firebase Number Veri cation は現在はいくつかの国でサポート • 現状は Android のみサポート • CAMARA というキャリアをまたいだモバイル通信の規格策定にも在る • 本の会社も検証を進めている • SMSメッセージを介した認証が減っていけば、フィッシング等の攻撃 を減らせる • そういう体験 体が無い物になっていくため https://developer.vonage.com/en/blog/frictionless-authentication-on-ios-silent-network-veri cation-with-vonage-verify 面 3 6 9 4 6 5 7 2 fi 手 fi fi fi 自 自 fi https:// rebase.google.com/docs/phone-number-veri cation / https://tech-note.kddi.com/n/n 7 日 1 SMS 認証の次世代改善例: Phone number veri cation f a e d
18. ‣ ブラウザを介して「メールの有効性チェック」を • アカウント登録 → Email • Magic Link の当 動化する → Magic Link を踏む → 有効アカウントと認証 検証をブラウザが仲介して確認の 動化 • ブラウザ上でログイン中の Email Provider と連携して確認する • 現在 Chrome で OriginTrial ステータス ‣ Android でも Digital Credentials API で近い機能が 意 • 端末にログインしている Google アカウントと連携 • Digital Credentials API が端末認証済みの Email かチェックしてくれる https://datatracker.ietf.org/doc/draft-hardt-email-veri cation 用 自 自 fi fi 力 入 fi 0 5 人 1 https://developer.android.com/identity/digital-credentials/email-veri cation 8 1 メールアドレス有効性の次世代改善例: Email Veri cation Protocol (Draft)
19. 観点では ‣ rd party IdP (Identity Provider) の変化 • ID連携先の新たな追加 削除 • 最近だとマイナンバーカードを いた認証も！ ‣ Security 対策 • Bot 対策 不正アクセス検知への継続的な対応 • reCAPTCHA 等 • AI Agent といった新しいアクセス元への対応 • 攻撃の敷居も下がっている リスクに応じて追加認証 不正検知等を柔軟に改善することがより求められる 用 ・ 3 2 2 ・ 0 用 8 0 4 0 ・ https://img.myna.go.jp/manual/ 9 3 1 継続的な運 - / .html
20. ‣ 新機能の追加 • 最新バージョンから使 ‣ セキュリティ強化 できる形は許容できそう 連携終了 • 古いバージョンは強制アップデートが必須になりうる...? • ビジネスサイドと内容で相談になる • アップデートしてない • Webで • や、サポートが切られた OS バージョンのユーザーは救えない れてる対策、ネイティブにも れてもらえる？ 重実装になってコストが上がる 用 方 入 用 ・ 人 入 常に最新でいてほしいため、アプリのバージョニングと相性が悪い → Webサイト側で管理する形で分けた が最初は運 しやすい 0 2 二 アプリの中で認証フローをサイト側に持たせる利点
21. ASWebAuthenticationSession 深掘り
22. ‣ システムが提供する認証 ブラウザセッション • 通常のブラウザよりも機能等制限されていてログイン専 • アプリ内に表 View を表 可能 されるが、アプリからは操作できない外部ユーザーエージェント ‣ 外部ユーザーエージェント認証のUXを改善 • アプリ内で埋め込みブラウザを表 • 較対象: ブラウザに することで体験を阻害しない んで認証してからアプリへ戻ってくる 式 ‣ 備考 示 用 方 示 用 飛 示 • ここからは”ASWeb”と省略して表記することがあります 2 比 2 ASWebAuthenticationSession
23. ‣ Safari ベースの簡易埋め込みブラウザ • 外部サイトやヘルプページに利 されることが多い • カスタマイズする場合は WKWebView を利 する ‣ Cookie を Safari とは共有しない • iOS から。それまでは共有していた • (後述) Ephemeral セッションの振る舞いが近いが別 • SFSafari 上で付与された Cookie は次回も継続される 用 細かい違い 用 1 1 • 3 2 SFSafariViewController
24. iOS + SFSafariViewController Web 閲覧 + Web 認証に利 SafariServices フレームワーク 4 0 2 8 1 0 2 用 9 https://developer.apple.com/videos/play/wwdc 4 2 系譜 / /
25. iOS + iOS + SFSafariViewController Web 閲覧 + Web 認証に利 SafariServices フレームワーク SFSafariViewController Web 閲覧 Safari との Cookie 共有を廃 認証 途を分離 SFAuthenticationSession 認証 Webセッション+callback URL 4 0 2 8 1 0 2 止 用 1 1 9 用 用 https://developer.apple.com/videos/play/wwdc 5 2 系譜 / /
26. iOS + iOS + iOS + SFSafariViewController Web 閲覧 + Web 認証に利 SafariServices フレームワーク SFSafariViewController Web 閲覧 Safari との Cookie 共有を廃 認証 継続 途を分離 SFAuthenticationSession 認証 Webセッション+callback URL ASWebAuthenticationSession 認証 Webセッション+callback URL AuthenticationServices フレームワークへ 4 0 2 8 1 0 2 止 用 1 2 1 9 1 用 用 用 https://developer.apple.com/videos/play/wwdc 6 2 系譜 / /
27. iOS + iOS + iOS + SFSafariViewController Web 閲覧 + Web 認証に利 SafariServices フレームワーク SFSafariViewController Web 閲覧 Safari との Cookie 共有を廃 認証 認証 継続 ASWebAuthenticationSession 認証 Webセッション+callback URL AuthenticationServices フレームワークへ 途を分離 SFAuthenticationSession Webセッション+callback URL iOS + マルチウィンドウ対応 Ephemeral Session の追加 iOS . + HTTPS URLをcallbackに指定可能 4 0 2 8 1 0 2 止 用 1 2 1 9 1 4 用 3 7 用 用 1 1 https://developer.apple.com/videos/play/wwdc 7 2 系譜 / /
28. Chrome CustomTabs Web 閲覧 + Web 認証に利 Chrome CustomTabs Web 閲覧 (+ Web 認証に利 認証 ) 途を分離 AuthTab 認証 Webセッション+callback URL 用 用 用 用 https://developer.chrome.com/docs/android/custom-tabs/guide-auth-tab 8 2 Android も同じ改善が進んでいる
29. ‣ Authorization Code: トークンを取得するための1度だけ有効な引換券 外部ユーザーエージェント クライアント 認可サーバー 認可URLを開く 認可要求 Redirect: callbackURL?code=Sci Authorization Code 成 callbackURL+Authorization Code Authorization Code 取得完了 ここまでが ASWebAuthenticationSession Authorization Code を いてToken Request Token Response 成 Token Response（Access Token / ID Token※） … 用 生 生 ※IDTokenはOIDC認証の場合 9 2 ASWebから Authorization Code を受け取る
30. ‣ アプリ側は closure で受け取る func signIn() { ASWebAuthenticationSession( url: “https://www.nikkei.com/authorize”, callback: .customScheme("myapp") ) { callbackURL, _ in guard let callbackURL else { return } // myapp://callback?code=Sqp let authorizationCode = callbackURL.getParam(“code”) ... } .start() … } 0 3 サイト側から callbackURL + code をつけて送信 認可URL callback scheme 外部ユーザーエージェントから戻ってきた callback をクロージャで受け取る ASWeb 上で起きた callback に限定される
31. 可能 ‣ WebAuthenticationSession ＠Environment // Get an instance of WebAuthenticationSession using SwiftUI's // @Environment property wrapper. @Environment(\.webAuthenticationSession) private var webAuthenticationSession ‣ watchOS にも対応 • iOS . + / iPadOS • SwiftUIの • (唯 はi . + / macOS . +/m Webページを表 . + / watchOS . + / visionOS . + . +/w . +/v . + できる 段かも) https://developer.apple.com/documentation/authenticationservices/webauthenticationsession 0 1 2 6 0 5 1 1 0 1 4 9 手 用 3 5 3 5 1 1 3 1 0 1 7 1 示 2 1 1 1 1 2 0 2 4 6 1 方 0 2 1 一 https://mntone.hateblo.jp/entry/ 1 3 SwiftUI でも利 / / /
32. Button("Sign in") { Task { do { // Perform the authentication and await the result. let callbackURL = try await webAuthenticationSession.authenticate( using: URL(“https://www.nikkei.com/authorize“)!, callback: .customScheme(”myapp”) ) let authorizationCode = callbackURL.getParam(“code”) } catch { // Respond to any authorization errors. } } } … https://developer.apple.com/documentation/authenticationservices/webauthenticationsession 2 3 シンプル ✨
33. ASWebAuthenticationSession の Session 設定
34. ASWebAuthentication Shared browser Session Safari と Cookie を共有する start() 実 前に選択 Ephemeral session InPrivate。Session を共有しない 行 https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/prefersephemeralwebbrowsersession 4 3 起動時に Browser Session を選択する
35. ‣ Shared Session • Safari の Cookie 領域を利 できる • Safari や別アプリでログイン済みなら再利 することも可能 • Single Sign On • 許諾プロンプトが出る • これが出てむしろ安 って思う利 者(開発者)は多いかも 毎回許諾が必要 用 用 用 心 https://developer.apple.com/documentation/authenticationservices/webauthenticationsession/browsersession/shared 5 3 Shared Browser Session
36. ‣ Private モード。Cookie をどことも共有せず毎 Session Clean • 許諾無しで動く • prefersEphemeralWebBrowserSession = true で設定 • Cookie 等をどことも共有してないので基本ログイン等何もしてない前提 • Password Auto ll や PassKey は問題なく動作する • Web 側でドメインを適切に紐づけて実 する 行 fi https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/prefersephemeralwebbrowsersession 6 3 Ephemeral Session
37. ‣ ログイン成功時に保存のリコメンド いずに直 力 入 用 • Auto Fill 等を 7 3 Shared Session は Password マネージャーへも連携 した場合に動作
38. 初期化 ‣ 設定アプリの Safari のデータを参照 • 「アプリ → Safari → 詳細 → Web サイトデータ」 ・ • Cookie 共有しているドメインを削除すればリセット 8 3 Shared Session の保存先
39. 安全に使っていくために アプリ特有の動きを追う
40. ‣ ASWebAuthenticationSession で認証 認可画 を開く 外部ユーザーエージェント クライアント 認可サーバー 認可URLを開く 認可要求 面 ・ ※IDTokenはOIDC認証の場合 0 4 Authorization Code Flow の流れ
41. ‣ AuthorizationCode の取得 外部ユーザーエージェント クライアント 認可サーバー 認可URLを開く 認可要求 Redirect: callbackURL?code=Sci Authorization Code 成 callbackURL+Authorization Code Authorization Code 取得完了 … 生 ※IDTokenはOIDC認証の場合 1 4 Authorization Code Flow の流れ
42. ‣ AuthorizationCode を いて Token Response を取得 外部ユーザーエージェント クライアント 認可サーバー 認可URLを開く 認可要求 Redirect: callbackURL?code=Sci Authorization Code 成 callbackURL+Authorization Code Authorization Code 取得完了 Authorization Code を いてToken Request Token Response 成 Token Response（Access Token / ID Token※） Resource Access できる状態に！ 用 … 用 生 生 ※IDTokenはOIDC認証の場合 2 4 Authorization Code Flow の流れ
43. ‣ フローの各ポイントを複数の仕組みで保護 • PKCE • Authorization Codeの横取り対策 • OAuth . Draft では MUST 扱い • claimed HTTPS scheme URI • Callback先の正規アプリへの紐付け 横取り対策 • State • Authorization Response の取り違え防 / CSRF対策 • Nonce (OIDC) • ID Tokenのリプレイ対策 止 ・ 2 5 2 8 1 2 https://datatracker.ietf.org/doc/html/rfc 3 4 Authorization Code Flow を安全にする仕組み
44. ‣ フローの各ポイントを複数の仕組みで保護 • PKCE • Authorization Codeの横取り対策 • OAuth . Draft では MUST 扱い • claimed HTTPS scheme URI • Callback先の正規アプリへの紐付け 横取り対策 • State • Authorization Response の取り違え防 / CSRF対策 • Nonce (OIDC) • ID Tokenのリプレイ対策 止 ・ 2 5 2 8 1 2 https://datatracker.ietf.org/doc/html/rfc 4 4 Authorization Code Flow を安全にする仕組み
45. 外部ユーザーエージェント クライアント 認可サーバー 認可URLを開く 認可要求 Redirect: callbackURL?code=Sci Authorization Code 成 callbackURL+Authorization Code Authorization Code 取得完了 Authorization Code を いてToken Request Token Response 成 Token Response（Access Token / ID Token※） Resource Access できる状態に！ … 用 生 生 ※IDTokenはOIDC認証の場合 5 4 callback で Authorization Code を受け取る
46. 法 ‣ Private-use URI Scheme (deep link) • myapp://callback?code=Sfhe • 同じ Scheme を他のアプリも登録できる • callback の宛先を正規アプリだと保証しにくい ‣ claimed HTTPS scheme URI • https://example.com/callback?code=Sfhe • ドメインとアプリの関連付けを OS が検証 … 方 … • 正規アプリへCallbackを結び付けられる 6 4 アプリに callback する 奪った Authorization Code から Token Response を取得される危険性
47. ‣ Authorization Codeの横取り対策 . Clientが認可開始前にランダムな code_veri er を 成 . code_veri er から code_challenge (ハッシュ)を . ハッシュは code_challenge_method (例: S 成し、認可要求に付与 ) を設定して 成 . Token 交換時に元の code_veri er を送信 . Authorization Server でも code_challenge を 成して同値であることを確認 生 生 生 生 fi 6 5 2 fi fi . Authorization Code が盗まれても Access Token へ交換されるのを防げる 7 1 2 1 3 4 4 5 PKCE (Proof Key for Code Exchange)
48. 外部ユーザーエージェント クライアント ① 認可サーバー 認可URLを開く code_veri er (乱数) 認可要求 ↓(code_challenge_method) で作成 code_challenge Redirect: callbackURL?code=Sci callbackURL+Authorization Code Authorization Code Authorization Code 成 ② code_challenge_method code_challenge を保持 取得完了 ③ code_veri er 送信 Authorization Code を いてToken Request Token Response（Access Token / ID Token※） Resource Access ④ Token Response 成 code_veri er から code_challenge を 成 → 保持していた値と できる状態に！ 致するか検証 fi 生 … 一 用 生 生 fi fi fi ※IDTokenはOIDC認証の場合 8 4 認可開始時のcode_veri erを持つClientだけが Codeを交換できる
49. ‣ Private-use URI Scheme で衝突しても • ASWeb で開いていた場合 ASWeb 元のアプリへの遷移を優先してくれる • 素のブラウザを使うよりもメリット • 同じ Scheme が登録されていても開始元が優先。callback を奪われない • 予期せぬ別アプリへの遷移事故を防 してくれる ‣ ただし、バックエンド側は ASWebを使っているか把握できない 止 • 依然として PKCE も実装することが基本 9 4 ASWeb も callback 奪取を防ぐ機構がある
50. ‣ 正規のフローを再現すれば正常に実 できてしまう • ログインまで正常にPassした本物っぽいアプリで、悪意のあるコードが仕込まれる • 通信先は本物のサイト、なのにパスワードが盗まれる • AI 時代。敷居は下がっている。対策はできないか？ ‣ のアプリを保証するには２通りの . プラットフォームとの連携を利 法 して正規アプリのリクエストを保証 • App Attest / Play Integrity / Firebase App Check . OAuth callback を正規アプリへ結び付ける • claimed HTTPS scheme URI • Universal Links / App Links (Android) 方 行 用 fi 身 https:// rebase.google.com/docs/app-check 0 自 1 5 2 PKCEだけでは防げない「コピーアプリ」
51. 法 ‣ Private-use URI Scheme • myapp://callback?code=Sfhe • 同じ Scheme を他のアプリも登録できる • callback の宛先を正規アプリだと保証しにくい ‣ claimed HTTPS scheme URI • https://example.com/callback?code=Sfhe • ドメインとアプリの関連付けを OS が検証 … 方 … • 正規アプリへCallbackを結び付けられる 1 5 アプリに callback する callback 先を正規アプリへ 強くバインドする！
52. ‣ ASWeb 上だと Universal Link の動作に問題が… • フレークな動きが報告されていた • 特にリダイレクト時、動作しない ‣ iOS . + から専 https URL callback を指定可能に • associated domains に指定しておく必要がある • webcredentials: auth.example.com • 通常のUniversal Link は applinks: に指定するので Universal Link とは別 用 4 7 1 https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/callback/https(host:path:) 2 5 ASWeb でだけ使える https callback が指定可能
53. apple-app-site-association 設定ファイル ‣ Associated domains { "webcredentials": { "apps": [ "ABCDE12345.com.example.app" ] App ID Pre xを指定するため、コピーアプリは使えない }, "applinks": { "details": [ { "appIDs": [ "ABCDE12345.com.example.app" ], "components": [ { "/": "/oauth/callback", "comment": "OAuth callback" } ] } ] } • App 側 • entitlements に対象のドメインを指定 • サイト側 • 設定ファイルを配置 • (App ID Pre x).Bundle ID を指定 • ドメインに関連づけられたアプリにのみ遷移を保証 fi fi } 3 5 Universal Link や https callback が安全な仕組み
54. その他 気をつけるポイント
55. ‣ アプリとIdPでは別々にセッションを持っている • App側： サービスのログイン状態 保持するトークン • Web側：IdPの認証 Session Cookie ‣ ログアウト実 時、Tokenを破棄してもCookieが残っている • 再ログイン時に ASWebAuthenticationSession が Cookie を共有 ・ 入 行 自 • 前回のアカウントでそのまま 5 5 ログアウトしても「ブラウザの認証状態」は残る れてしまう
56. ‣ IdP 側にもログアウトを要求 • IdPのLogout Endpoint / RP-Initiated Logout ‣ (サイト側が対応) クエリパラメータをつける • 再認証 • prompt=login • max_age= • アカウント選択 0 • prompt=select_account 6 5 意図に応じてWeb側も制御する
57. れれない) ‣ 案1) VPN • 端末本体に設定 ‣ 案2) 初回リクエストに認証情報を載せる (バイパス) • クエリパラメータ • iOS . + からは additionalHeaderFields も使 可能 ‣ ただし、最初のページにしか情報は付かない • Redirect / ページ遷移後にも維持するには • サイト側で検証後、Session Cookie へ交換する必要がある 入 fi 用 4 7 1 https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/additionalheader elds 7 5 開発環境のアクセス制限 (Debug Cookieを
58. ‣ ユーザーの環境によって表 が壊れるケース • 例えば Safari の設定で JavaScript をオフにすると影響する • 他にも広告ブロックで DNS ブロックが ON になっている等 • 気づかない間に知らない拡張機能が っていた • 意外といる 😭 ‣ ユーザーもなかなか気づけない • アプリ設定のみに原因を疑って改善しない 真っ になってしまう！等の 入 示 白 問い合わせが来る 8 5 動作しない報告ユーザーの救済が難しい
59. ‣ コンテンツ側の対策 • NOSCRIPT 等 JavaScript が実 できなくても エラーを伝えられるようにする ‣ 結果的に Shared Session が良かったり • 連携するポップアップが出るので ブラウザが動いていると気づいてくれる 見 行 • 「その端末上の Safari でログインできるか」で 問い合わせ時は原因を切り分けるといい 9 5 対策: Safari の設定を 直すコミュニケーション
60. 用 ASWebAuthenticationSession 上で Safari と連携した機能を利 する
61. ‣ パスキーを 動 成 登録できる機能 • ユーザーの設定上で許諾されていれば実 • iOS から利 ‣ パスキー移 可能 を促進 • パスワードマネージャーに ID / Password を保存している • AutoFill ログインをした場合に作動。追加許諾なしでパスキー登録ができる • パスワードマネージャー側で Upgrade の許可 許可ができる https://w c.github.io/webauthn/#sctn-createCredential 非 ・ 行 5 2 1 0 1 4 2 0 2 ・ 生 用 自 行 8 3 1 https://developer.apple.com/videos/play/wwdc 1 6 例: Automatic Passkey Upgrade /
62. Password Login Successful PassKey 自 登録 2 6 パスワードログイン時にパスキーを 動登録する
63. App Password Auto llで サインイン https://developer.apple.com/documentation/authenticationservices/supporting-passkeys 5 2 1 0 1 4 2 0 2 fi https://developer.apple.com/videos/play/wwdc 3 6 フロー /
64. App OS Password Auto llで サインイン PassKey Upgrade リクエスト 🔑 New PassKey or Error https://developer.apple.com/documentation/authenticationservices/supporting-passkeys 5 2 1 0 1 4 2 0 2 fi https://developer.apple.com/videos/play/wwdc 4 6 フロー /
65. App OS Password Auto llで Credential Manager Manager が使えるか サインイン PassKey Upgrade リクエスト その他条件を満たしてるか Upgrade 可能？ 🔑 New PassKey or Error https://developer.apple.com/documentation/authenticationservices/supporting-passkeys 5 2 1 0 1 4 2 0 2 fi https://developer.apple.com/videos/play/wwdc 5 6 フロー /
66. ユーザー側で許諾設定 パスワードマネージャー側 <key>ASCredentialProviderExtensionCapabilities</key> <dict> <key>ProvidesOneTimeCodes</key> <true/> <key>ProvidesPasskeys</key> <true/> <key>ProvidesPasswords</key> <true/> <key>SupportsConditionalPasskeyRegistration</key> <true/> </dict> パスワードアプリの設定でデフォルトON Extension の Info.plist にサポート可否が設定されている https://developer.apple.com/documentation/bundleresources/information-property-list/supportsconditionalpasskeyregistration 6 6 動作の許可設定 / 3rd がサポートするには
67. ‣ ブラウザで対応すれば基本 ASWeb でも動作！ • Web 側で navigator.credentials.create に mediation: conditional’ を設定 ‣ アプリ側の実装コストがかからない • Web で対応すれば iOS アプリでも Android アプリでも • 重複実装が発 しない ‣ ただし、開発環境特有の罠を踏むことがある ‘ 社の環境なのかAPIの振る舞いなのか区別がつかない…デバッグをうまく 生 • 7 6 自 Upgrade を対応する - ASWeb の場合 -
68. ‣ 責任分界点を明確にする • 登場 • 第 物が多くDebugもしづらいため、どこまで適切に動作したか切り分ける に Safari で動作することをチェック • ブラウザレイヤーまでの機能実装が適切にできていることを確認 • 次に ASWebAuthenticationSession 経由で • 開発環境特有の制約を る 逃しやすいため、注意する 方 見 見 人 一 • 例えば host が Dev は異なる場合 Dev 向けの entitlements に設定済みか...等 8 6 ASWeb 上の動作確認やデバッグの進め
69. ‣ apple-app-site-association ファイルで動作 • UniversalLink (applinks: { }) / ASWeb Redirect (webcredentials: { }) • 本番は AppleのCDNによってキャッシュされてから動作 … … • Dev で Debug 時は設定アプリの 「Developer」 から 強制 Refresh 指定できる 9 6 HTTPS RedirectURL は CDN の動きも注意
70. ‣ 2 種類の 式 • Ephemeral Session • Private モード。Cookie をどことも共有しない • Shared Session • PassKey AutoUpgrade はネイティブと Safari の機能としてサポートされてる • Safari と共有しないと動作しない • ブラウザのstateを利 • こう する機能ではShared Sessionが重要 った理由からも Shared セッションベースでログイン構築することを個 的には推奨 人 用 方 言 https://developer.apple.com/documentation/authenticationservices/webauthenticationsession/browsersession/shared 0 7 Browser Session で使える機能が変わる
71. ‣ 最新のセキュリティ機能をサポートしていける • ネイティブや Safari で対応していれば → ASWebでも可能！ • アプリ更新無しで、サイト側の対応コストが中 • ネイティブ側の実装コスト節約 • アプリのアップデートを必要としない • 最新の機能はブラウザと連携してはじまるものも多い • (Email Veri cation Protocol も仕組み上はそうなりうるかも...？) ‣ それなら全部 ASWebAuthenticationSession？ 心 fi • 体験を良くしたい、仕組み上リスクが低い、等のバランスでネイティブ対応を検討する 1 7 ASWebでも体験を損なわない機能提供が可能
72. 用 ASWebAuthenticationSession が 利 できない特殊ケース
73. ‣ 衛星通信 → できない や海で！ • Web 周りの機能に制限 • ASWebAuthenticationSession も現状利 「【iOSアプリの開発者向け】空が 不可 えれば、どこでもつながる。 au Starlink Directデータ通信対応アプリ開発ための参考情報」より https://tech-note.kddi.com/n/n d b 用 用 2 6 見 2 0 2 4 4 5 3 7 山 https://www.au.com/mobile/service/starlink-direct/app/ 3 7 衛星通信環境では外部ブラウザ型の認証が利
74. ‣ PassKey のネイティブ対応はUX等価値は い • パスワードを れないので、ブラウザを介さなくても認証情報の奪取には強い • 衛星通信でもログイン可能にできる • Auto ll が動くようになる: 1タップでログインを完了できる快適な体験に ‣ 最終的にはビジネス要件も加味して判断 • ネイティブ対応しても、ASWeb ログイン 体は残すことを推奨 • 古いバージョンでもFeatureFlag を いて Web ベースのログインのみに強制する • Web側のアプデで最新仕様の認証を要求できる 方 高 自 用 入 fi • 新しいバージョンからは改善されたネイティブのUXで再度提供、ができる 4 7 ネイティブ対応とのバランスの取り
75. ‣ Starlink Mobile V を各社準備中 • 今回の提携により、現在のテキストメッセージの送受信や 部アプリの利 に 加え、 声通話やブラウジング機能にも対応することで、より多様な通信ニー ズにお応えするとともに、お客さまが利 できるコミュニケーションや情報取 得の 段を拡 し、利便性のさらなる向上を実現してまいります。 Starlink Japan,GKと「docomo Starlink Direct」の機能拡充に向け「Starlink Mobile V 」の契約に合意 用 一 2 用 0 0 4 1 8 0 6 2 0 2 2 大 音 手 https://www.docomo.ne.jp/info/news_release/ 5 7 (余談) 2028年にはこの制約は無くなるかも / / _ .html
76. ‣ ブラウザ機能をユーザーが削除 無効化している可能性がある • Chrome Custom Tabs • Auth Tab 可否を検知してエスカレーションが必要 ・ 用 • インストール アップデートを促さないといけない ・ ‣利 6 7 Android の場合はブラウザが無いケースもある
77. ‣ Universal Link 利 者は挙動保証が必要 • ブラウザに遷移して認証してアプリに戻る場合 • ブラウザ側が適切に実装してないと動作しなくなる ‣ ASWebAuthenticationSession を使っていれば安全 • Embedded Safari に固定して動作 • 認証ページの別ブラウザ対応を考慮しなくていい • https callback なら上記の影響も関係ない • 注) Macアプリ の場合は対応している場合デフォルトブラウザを介して動く • Info.plist で明 • ASWebAuthenticationSessionWebBrowserSupportCapabilities • CallbackURLMatchingIsSupported https://zenn.dev/mtgto/articles/howto-use-macos-webauthenticationsession 用 示 https://developer.apple.com/documentation/bundleresources/information-property-list/aswebauthenticationsessionwebbrowsersupportcapabilities/callbackurlmatchingissupported 7 7 iOS もデフォルトブラウザの変更に注意
78. ‣ RFC では 1st party も依然推奨 • 必要最 権限を与える形を徹底できるため ‣ 取り巻く環境も加味 • 同 パスワードをUserが別サービスで使っているかもしれない • パスワードを扱うフローをアプリで扱っていないことを徹底したい • 万 の Logger や DB保存等の誤った実装にも繋がらないように 2 5 2 小 8 一 一 これらの観点を経て、1st party でも ASWebAuthenticationSession を選択してます 8 7 IdP が 1st party だけの場合もASWebは必要？
79. ‣ ASWebAuthenticationSession • アプリエンジニアの視点から、アプリの認証認可の仕組みを整理 • Browser Session によって振る舞いが違うため、違いや細かいTips も紹介 ‣ 安全性の仕組み • OAuth/OIDC のフローの中でアプリ側で攻撃を防ぐための 段をいくつか説明 ‣ Web と連携することでコストを抑えたままリッチな体験を • Passkey Upgrade や衛星通信の事例を紹介 ‣ の環境ではどうするか？ 手 身 • 必要な要件が何か整理できるきっかけを持ち帰れると幸いです 9 自 7 まとめ