Share
Embed
Slide 1
Slide 1 text
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
Slide 2
Slide 2 text
‣ ID
• shimastripe / shimastriper
‣ Work
•
本経済新聞社
‣ Like
• Swift /
動化 / 柴
‣ 過去
fi
fi
犬
• In App Purchase / UIContentCon guration / PencilKit / Background Noti cation
自
日
2
Me ( Go Takagi )
Slide 3
Slide 3 text
‣ システムが提供する認証
ブラウザセッション
行
• アプリ内でWebサービスを介して
ユーザーのログイン認証や OAuth 認可を
用
3
ASWebAuthenticationSession
う
Slide 4
Slide 4 text
4
安全な場所で認証し、callback してアプリへ
ASWebAuthentication
Login Successful
認可コードリダイレクト
(callback)
callback URL 例
myapp://callback?code=Sqplfeijeiwjig
&state=xyz
Slide 5
Slide 5 text
ブラウザを介することで、秘密情報を保護
‣ アプリが介在できない場所でログインさせる
• 認証に いるユーザーの秘密情報を奪取させない
• パスワード、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)
認可サーバー
Slide 6
Slide 6 text
: 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
/
Slide 7
Slide 7 text
7
1. 認証URLを開く
ASWebAuthenticationの callback へ渡る
2. 認証リクエスト
( /authorize )
3.リダイレクト
(callback URL + code)
認可サーバー
Slide 8
Slide 8 text
‣ 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
Slide 9
Slide 9 text
: 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
Slide 10
Slide 10 text
0
1
なので ASWebAuthenticationSession 使おうね！
Slide 11
Slide 11 text
完
Slide 12
Slide 12 text
もうちょっとこう...
Slide 13
Slide 13 text
‣ 本能的にはなるべくネイティブにしたい
• ネイティブが常に正解とは限らない、でも何故 Web に寄せるのか？
• UXだけでなく、安全性
運
性
拡張性まで含めて考える
• 認証 式ごとに「アプリに任せること / 外に任せること」が違う
‣ 認証はアプリだけでは完結しない
• 登場 物が多い
• 発表の都合上省略するところもあるので引
から正確な定義も参照してください
• Native / Web、それぞれの役割とトレードオフ を理解して
用
・
用
分たちの要件に対してのアプローチをぜひ持ち帰ってください
・
人
方
•
3
1
自
アプリエンジニアとしてもう少し線引きを学びたい
Slide 14
Slide 14 text
用
改善と運
Slide 15
Slide 15 text
認可の改善はとても頻繁にある
‣ ID, Password, Submit!完成!!
• で済まない時代…!!!
‣ 3つの観点で
てみる
• 体験フローの改善 (
当
認証
・
・
人
身
まっている脅威、攻撃への対策
・
見
• 確実に
高
元確認
認可付与)
rd party IdP (Identity Provider) 対応追加
・
•
5
3
1
前提: 認証
終了
Slide 16
Slide 16 text
式: 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
次世代認証
/
/
Slide 17
Slide 17 text
‣ 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
Slide 18
Slide 18 text
‣ ブラウザを介して「メールの有効性チェック」を
• アカウント登録 → 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)
Slide 19
Slide 19 text
観点では
‣ 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
Slide 20
Slide 20 text
‣ 新機能の追加
• 最新バージョンから使
‣ セキュリティ強化
できる形は許容できそう
連携終了
• 古いバージョンは強制アップデートが必須になりうる...?
• ビジネスサイドと内容で相談になる
• アップデートしてない
• Webで
•
や、サポートが切られた OS バージョンのユーザーは救えない
れてる対策、ネイティブにも
れてもらえる？
重実装になってコストが上がる
用
方
入
用
・
人
入
常に最新でいてほしいため、アプリのバージョニングと相性が悪い
→ Webサイト側で管理する形で分けた が最初は運 しやすい
0
2
二
アプリの中で認証フローをサイト側に持たせる利点
Slide 21
Slide 21 text
ASWebAuthenticationSession 深掘り
Slide 22
Slide 22 text
‣ システムが提供する認証
ブラウザセッション
• 通常のブラウザよりも機能等制限されていてログイン専
• アプリ内に表
View を表 可能
されるが、アプリからは操作できない外部ユーザーエージェント
‣ 外部ユーザーエージェント認証のUXを改善
• アプリ内で埋め込みブラウザを表
•
較対象: ブラウザに
することで体験を阻害しない
んで認証してからアプリへ戻ってくる 式
‣ 備考
示
用
方
示
用
飛
示
• ここからは”ASWeb”と省略して表記することがあります
2
比
2
ASWebAuthenticationSession
Slide 23
Slide 23 text
‣ Safari ベースの簡易埋め込みブラウザ
• 外部サイトやヘルプページに利
されることが多い
• カスタマイズする場合は WKWebView を利
する
‣ Cookie を Safari とは共有しない
• iOS
から。それまでは共有していた
• (後述) Ephemeral セッションの振る舞いが近いが別
• SFSafari 上で付与された Cookie は次回も継続される
用
細かい違い
用
1
1
•
3
2
SFSafariViewController
Slide 24
Slide 24 text
iOS +
SFSafariViewController
Web 閲覧 + Web 認証に利
SafariServices フレームワーク
4
0
2
8
1
0
2
用
9
https://developer.apple.com/videos/play/wwdc
4
2
系譜
/
/
Slide 25
Slide 25 text
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
系譜
/
/
Slide 26
Slide 26 text
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
系譜
/
/
Slide 27
Slide 27 text
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
系譜
/
/
Slide 28
Slide 28 text
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 も同じ改善が進んでいる
Slide 29
Slide 29 text
‣ 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 を受け取る
Slide 30
Slide 30 text
‣ アプリ側は 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 に限定される
Slide 31
Slide 31 text
可能
‣ 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 でも利
/
/
/
Slide 32
Slide 32 text
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
シンプル ✨
Slide 33
Slide 33 text
ASWebAuthenticationSession の
Session 設定
Slide 34
Slide 34 text
ASWebAuthentication
Shared browser Session
Safari と Cookie を共有する
start() 実 前に選択
Ephemeral session
InPrivate。Session を共有しない
行
https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/prefersephemeralwebbrowsersession
4
3
起動時に Browser Session を選択する
Slide 35
Slide 35 text
‣ Shared Session
• Safari の Cookie 領域を利 できる
• Safari や別アプリでログイン済みなら再利
することも可能
• Single Sign On
• 許諾プロンプトが出る
• これが出てむしろ安
って思う利
者(開発者)は多いかも
毎回許諾が必要
用
用
用
心
https://developer.apple.com/documentation/authenticationservices/webauthenticationsession/browsersession/shared
5
3
Shared Browser Session
Slide 36
Slide 36 text
‣ 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
Slide 37
Slide 37 text
‣ ログイン成功時に保存のリコメンド
いずに直
力
入
用
• Auto Fill 等を
7
3
Shared Session は
Password マネージャーへも連携
した場合に動作
Slide 38
Slide 38 text
初期化
‣ 設定アプリの Safari のデータを参照
• 「アプリ → Safari → 詳細 → Web サイトデータ」
・
• Cookie 共有しているドメインを削除すればリセット
8
3
Shared Session の保存先
Slide 39
Slide 39 text
安全に使っていくために
アプリ特有の動きを追う
Slide 40
Slide 40 text
‣ ASWebAuthenticationSession で認証
認可画 を開く
外部ユーザーエージェント
クライアント
認可サーバー
認可URLを開く
認可要求
面
・
※IDTokenはOIDC認証の場合
0
4
Authorization Code Flow の流れ
Slide 41
Slide 41 text
‣ AuthorizationCode の取得
外部ユーザーエージェント
クライアント
認可サーバー
認可URLを開く
認可要求
Redirect: callbackURL?code=Sci
Authorization Code
成
callbackURL+Authorization Code
Authorization Code
取得完了
…
生
※IDTokenはOIDC認証の場合
1
4
Authorization Code Flow の流れ
Slide 42
Slide 42 text
‣ 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 の流れ
Slide 43
Slide 43 text
‣ フローの各ポイントを複数の仕組みで保護
• 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 を安全にする仕組み
Slide 44
Slide 44 text
‣ フローの各ポイントを複数の仕組みで保護
• 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 を安全にする仕組み
Slide 45
Slide 45 text
外部ユーザーエージェント
クライアント
認可サーバー
認可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 を受け取る
Slide 46
Slide 46 text
法
‣ 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 を取得される危険性
Slide 47
Slide 47 text
‣ 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)
Slide 48
Slide 48 text
外部ユーザーエージェント
クライアント
①
認可サーバー
認可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を交換できる
Slide 49
Slide 49 text
‣ Private-use URI Scheme で衝突しても
• ASWeb で開いていた場合 ASWeb 元のアプリへの遷移を優先してくれる
• 素のブラウザを使うよりもメリット
• 同じ Scheme が登録されていても開始元が優先。callback を奪われない
• 予期せぬ別アプリへの遷移事故を防
してくれる
‣ ただし、バックエンド側は ASWebを使っているか把握できない
止
• 依然として PKCE も実装することが基本
9
4
ASWeb も callback 奪取を防ぐ機構がある
Slide 50
Slide 50 text
‣ 正規のフローを再現すれば正常に実
できてしまう
• ログインまで正常に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だけでは防げない「コピーアプリ」
Slide 51
Slide 51 text
法
‣ 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 先を正規アプリへ
強くバインドする！
Slide 52
Slide 52 text
‣ 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 が指定可能
Slide 53
Slide 53 text
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 が安全な仕組み
Slide 54
Slide 54 text
その他 気をつけるポイント
Slide 55
Slide 55 text
‣ アプリとIdPでは別々にセッションを持っている
• App側：
サービスのログイン状態
保持するトークン
• Web側：IdPの認証 Session Cookie
‣ ログアウト実
時、Tokenを破棄してもCookieが残っている
• 再ログイン時に ASWebAuthenticationSession が Cookie を共有
・
入
行
自
• 前回のアカウントでそのまま
5
5
ログアウトしても「ブラウザの認証状態」は残る
れてしまう
Slide 56
Slide 56 text
‣ IdP 側にもログアウトを要求
• IdPのLogout Endpoint / RP-Initiated Logout
‣ (サイト側が対応) クエリパラメータをつける
• 再認証
• prompt=login
• max_age=
• アカウント選択
0
• prompt=select_account
6
5
意図に応じてWeb側も制御する
Slide 57
Slide 57 text
れれない)
‣ 案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を
Slide 58
Slide 58 text
‣ ユーザーの環境によって表
が壊れるケース
• 例えば Safari の設定で JavaScript をオフにすると影響する
• 他にも広告ブロックで DNS ブロックが ON になっている等
• 気づかない間に知らない拡張機能が
っていた
• 意外といる 😭
‣ ユーザーもなかなか気づけない
• アプリ設定のみに原因を疑って改善しない
真っ
になってしまう！等の
入
示
白
問い合わせが来る
8
5
動作しない報告ユーザーの救済が難しい
Slide 59
Slide 59 text
‣ コンテンツ側の対策
• NOSCRIPT 等 JavaScript が実 できなくても
エラーを伝えられるようにする
‣ 結果的に Shared Session が良かったり
• 連携するポップアップが出るので
ブラウザが動いていると気づいてくれる
見
行
• 「その端末上の Safari でログインできるか」で
問い合わせ時は原因を切り分けるといい
9
5
対策: Safari の設定を 直すコミュニケーション
Slide 60
Slide 60 text
用
ASWebAuthenticationSession 上で
Safari と連携した機能を利 する
Slide 61
Slide 61 text
‣ パスキーを
動
成
登録できる機能
• ユーザーの設定上で許諾されていれば実
• 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
/
Slide 62
Slide 62 text
Password
Login Successful
PassKey
自
登録
2
6
パスワードログイン時にパスキーを 動登録する
Slide 63
Slide 63 text
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
フロー
/
Slide 64
Slide 64 text
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
フロー
/
Slide 65
Slide 65 text
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
フロー
/
Slide 66
Slide 66 text
ユーザー側で許諾設定
パスワードマネージャー側
ASCredentialProviderExtensionCapabilities
ProvidesOneTimeCodes
ProvidesPasskeys
ProvidesPasswords
SupportsConditionalPasskeyRegistration
パスワードアプリの設定でデフォルトON
Extension の Info.plist にサポート可否が設定されている
https://developer.apple.com/documentation/bundleresources/information-property-list/supportsconditionalpasskeyregistration
6
6
動作の許可設定 / 3rd がサポートするには
Slide 67
Slide 67 text
‣ ブラウザで対応すれば基本 ASWeb でも動作！
• Web 側で navigator.credentials.create に mediation: conditional’ を設定
‣ アプリ側の実装コストがかからない
• Web で対応すれば iOS アプリでも Android アプリでも
• 重複実装が発
しない
‣ ただし、開発環境特有の罠を踏むことがある
‘
社の環境なのかAPIの振る舞いなのか区別がつかない…デバッグをうまく
生
•
7
6
自
Upgrade を対応する - ASWeb の場合 -
Slide 68
Slide 68 text
‣ 責任分界点を明確にする
• 登場
• 第
物が多くDebugもしづらいため、どこまで適切に動作したか切り分ける
に Safari で動作することをチェック
• ブラウザレイヤーまでの機能実装が適切にできていることを確認
• 次に ASWebAuthenticationSession 経由で
• 開発環境特有の制約を
る
逃しやすいため、注意する
方
見
見
人
一
• 例えば host が Dev は異なる場合 Dev 向けの entitlements に設定済みか...等
8
6
ASWeb 上の動作確認やデバッグの進め
Slide 69
Slide 69 text
‣ apple-app-site-association ファイルで動作
• UniversalLink (applinks: {
}) / ASWeb Redirect (webcredentials: {
})
• 本番は AppleのCDNによってキャッシュされてから動作
…
…
• Dev で Debug 時は設定アプリの 「Developer」 から 強制 Refresh 指定できる
9
6
HTTPS RedirectURL は CDN の動きも注意
Slide 70
Slide 70 text
‣ 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 で使える機能が変わる
Slide 71
Slide 71 text
‣ 最新のセキュリティ機能をサポートしていける
• ネイティブや Safari で対応していれば → ASWebでも可能！
• アプリ更新無しで、サイト側の対応コストが中
• ネイティブ側の実装コスト節約
• アプリのアップデートを必要としない
• 最新の機能はブラウザと連携してはじまるものも多い
•
(Email Veri cation Protocol も仕組み上はそうなりうるかも...？)
‣ それなら全部 ASWebAuthenticationSession？
心
fi
• 体験を良くしたい、仕組み上リスクが低い、等のバランスでネイティブ対応を検討する
1
7
ASWebでも体験を損なわない機能提供が可能
Slide 72
Slide 72 text
用
ASWebAuthenticationSession が
利 できない特殊ケース
Slide 73
Slide 73 text
‣ 衛星通信 →
できない
や海で！
• 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
衛星通信環境では外部ブラウザ型の認証が利
Slide 74
Slide 74 text
‣ PassKey のネイティブ対応はUX等価値は い
• パスワードを れないので、ブラウザを介さなくても認証情報の奪取には強い
• 衛星通信でもログイン可能にできる
• Auto ll が動くようになる: 1タップでログインを完了できる快適な体験に
‣ 最終的にはビジネス要件も加味して判断
• ネイティブ対応しても、ASWeb ログイン 体は残すことを推奨
• 古いバージョンでもFeatureFlag を いて Web ベースのログインのみに強制する
•
Web側のアプデで最新仕様の認証を要求できる
方
高
自
用
入
fi
• 新しいバージョンからは改善されたネイティブのUXで再度提供、ができる
4
7
ネイティブ対応とのバランスの取り
Slide 75
Slide 75 text
‣ 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
Slide 76
Slide 76 text
‣ ブラウザ機能をユーザーが削除
無効化している可能性がある
• Chrome Custom Tabs
• Auth Tab
可否を検知してエスカレーションが必要
・
用
• インストール
アップデートを促さないといけない
・
‣利
6
7
Android の場合はブラウザが無いケースもある
Slide 77
Slide 77 text
‣ 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 もデフォルトブラウザの変更に注意
Slide 78
Slide 78 text
‣ RFC
では 1st party も依然推奨
• 必要最
権限を与える形を徹底できるため
‣ 取り巻く環境も加味
• 同
パスワードをUserが別サービスで使っているかもしれない
• パスワードを扱うフローをアプリで扱っていないことを徹底したい
• 万
の Logger や DB保存等の誤った実装にも繋がらないように
2
5
2
小
8
一
一
これらの観点を経て、1st party でも ASWebAuthenticationSession を選択してます
8
7
IdP が 1st party だけの場合もASWebは必要？
Slide 79
Slide 79 text
‣ ASWebAuthenticationSession
• アプリエンジニアの視点から、アプリの認証認可の仕組みを整理
• Browser Session によって振る舞いが違うため、違いや細かいTips も紹介
‣ 安全性の仕組み
• OAuth/OIDC のフローの中でアプリ側で攻撃を防ぐための
段をいくつか説明
‣ Web と連携することでコストを抑えたままリッチな体験を
• Passkey Upgrade や衛星通信の事例を紹介
‣
の環境ではどうするか？
手
身
• 必要な要件が何か整理できるきっかけを持ち帰れると幸いです
9
自
7
まとめ