WebAuthn from the relying-party view

by Yoshikazu Nojima

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Copyright © Yoshikazu Nojima 2018 WebAuthnのRelying Partyライブラリ作ってます ■WebAuthn4J • https://github.com/webauthn4j/webauthn4j • WebAuthnのAssertion/Attestationを検証するためのライブラリ。Java製 ■Spring Security WebAuthn • https://github.com/ynojima/spring-security-webauthn • 上記のWebAuthn4JをSpringで使いやすくするためのライブラリ。 Spring SecurityのAuthenticationProvider実装を提供 • Spring Security本体への修正も必要な為、PullReq中 2

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright © Yoshikazu Nojima 2018 ※WebAuthnにおけるRelying Party ユーザーの登録、認証にWeb Authentication APIを使用するWebアプリケーション。 Client Platform（≒ブラウザ）や、Authenticator（認証デバイス）と対置されるエンティティ。 OICDのコンテキストのRelying Partyとは必ずしも一致しないので注意（ OICDのOPがWebAuthnではRelying Partyと呼ばれることは普通にある） WebAuthn認証における各エンティティの関係： 4 User Authenticator Client Platform Relying Party WebAuthn API FIDO CTAP2 FIDO U2F Proprietary API 顔認証指紋認証 etc. Windows Hello, Touch ID

Slide 6

Slide 6 text

Copyright © Yoshikazu Nojima 2018 WebAuthn APIとWebAuthnライブラリ間のギャップ WebAuthn APIは、ブラウザからRelying Partyに対しJavaScript APIとして提供 WebAuthn APIを呼び出すRelying Partyのフロントエンドと、 Assertion/Attestationの検証を行うバックエンド間の通信方式はWebAuthnのスコープ外 WebAuthnのRelying Party開発は、フロントエンド・バックエンド・両者の通信を開発する必要がある 5 Client Platform Relying Party WebAuthn API (JavaScript) フロントエンドバックエンドフロントエンド・バックエンド間通信は WebAuthnのスコープ外 WebAuthn ライブラリ ※Relying Partyによる実装が必要

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright © Yoshikazu Nojima 2018 オプションが多く、複雑です。次ページから各オプションを説明します Credentialの作成 7 let publicKeyCredentialCreationOptions = { rp: rp, user: user, challenge: challenge, pubKeyCredParams: pubKeyCredParams, timeout: timeout, excludeCredentials: excludeCredentials, authenticatorSelection: authenticatorSelection, attestation: attestation, extensions: extensions }; let credentialCreationOptions = { publicKey: publicKeyCredentialCreationOptions }; navigator.credentials.create(credentialCreationOptions) .then(function(credential){ // submit to Relying Party server });

Slide 9

Slide 9 text

Copyright © Yoshikazu Nojima 2018 Relying Partyに関するオプション例） rpメンバ（PublicKeyCredentialRpEntity ） 8 メンバ説明備考 id rpId。Credentialが有効なドメインのスコープを指定するオプション name Relying Partyの名称。画面付きのFIDO2 Authenticatorで表示に使用されると思われる icon Relying Partyのアイコン。画面付きのFIDO2 Authenticatorで表示に使用されると思われる let rp = { id: "http://localhost", name: "spring-security-webauthn sample", icon: "http://localhost/img/spring-security-webauthn.png" };

Slide 10

Slide 10 text

Copyright © Yoshikazu Nojima 2018 rpId：WebAuthnでサイトを区別するスコープの単位 rpIdで指定したドメイン自身、及びそのサブドメインでCredentialは共有例）以下のように、複数のサブドメインに跨って存在するサイトがあるとする ◆ rpIdが”example.com”の場合 Credentialは上記すべてのドメインで有効 ◆ rpIdが”admin.example.com”の場合 Credentialは”admin.example.com”のみで有効 9 id.example.com www.example.com admin.example.com

Slide 11

Slide 11 text

Copyright © Yoshikazu Nojima 2018 作成するCredentialが紐づくユーザーに関するオプション例） userメンバ（PublicKeyCredentialUserEntity） 10 メンバ説明備考 id userHandle。ユーザーを一意に特定するバイト列。Authenticatorが、あるRPのアカウント（userHandle）に対して複数のCredentialを持たないよう制御するのに利用 name ユーザーアカウントの入力用の表記（Human- palatable）。 displayName ユーザーアカウントの表示用の表記（Human- Readable）。 icon ユーザーアカウントのアイコン。 let user = { id: userHandle, name: "[email protected]", displayName: "Yoshikazu Nojima", icon: "http://localhost/user/ynojima/icon.png" };

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright © Yoshikazu Nojima 2018 RPが受け入れ可能なCredentialのタイプとアルゴリズムの指定オプション例） pubKeyCredParamsメンバ（PublicKeyCredentialParameters） 12 メンバ説明備考 alg Credentialのアルゴリズム。[IANA-COSE- ALGS-REG]に登録された値から選択 Relying Partyのバックエンド側も対応が必要 type “public-key”固定 let pubKeyCredParams = [ { alg: -7, //ES256 for FIDO U2F Key, etc. type: "public-key" }, { alg: -257, //RS256 for Windows Hello type: "public-key" } ];

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Copyright © Yoshikazu Nojima 2018 Authenticatorが、あるRPのアカウントに対して複数のCredentialを持たないよう制御する為のオプション例） excludeCredentialsメンバ（PublicKeyCredentialParameters配列） 14 メンバ説明備考 type “public-key”固定 id credentialId。 transports Authenticatorとの接続に使用できると思われる通信手段のヒント let excludeCredentials = [ { type: "public-key", id: id, transports: ["usb", "nfc", "ble", "internal"], } ];

Slide 16

Slide 16 text

Copyright © Yoshikazu Nojima 2018 RPが受け入れ可能なAuthenticatorを明示し、フィルタリングするためのオプション例） authenticatorSelectionメンバ（AuthenticatorSelectionCriteria） 15 メンバ説明備考 authenticator Attachment AuthenticatorのClient Platformに対する取り付け方の指定。内蔵の場合、”platform”。取り外し可能の場合、”cross-platform”。指定不要の場合、メンバを削除 require ResidentKey AuthenticatorにCredentialを保存するか指定。 falseの場合、Credentialをデバイスに保存しない Authenticator（FIDO-U2Fトークン等）も許可（その場合、ユーザーのID入力が必要） user Verification Authenticatorでユーザー識別を行うか指定。値域：”required”, “preferred”, “discouraged” let authenticatorSelection = { //authenticatorAttachment: "platform", requireResidentKey: false, userVerification: "preferred" };

Slide 17

Slide 17 text

Copyright © Yoshikazu Nojima 2018 要求するAttestationのタイプを指定するオプション例） “direct”を指定した場合、RPがAuthenticatorの出所を厳密に検証するための情報を取得できる一方、RPがユーザーをサイトを跨いでトラッキングするためにも使えてしまうというプライバシー上の懸念から、追加のダイアログが表示される。 RPが認定したAuthenticatorのみに利用を制限したいエンタープライズ用途以外では、”none”が適切 attestationメンバ（AttestationConveyancePreference） 16 メンバ説明備考 attestation 要求するattestationを指定。値域：”none”, “indirect”, “direct” let attestation = "none";

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyright © Yoshikazu Nojima 2018 Credentialの取得 18 let publicKeyCredentialRequestOptions = { challenge: challenge, timeout: timeout, rpId: rpId, allowCredentials: allowCredentials, userVerification: userVerification, extensions: extensions }; let credentialRequestOptions = { mediation: "required", //WebAuthn lv.1ではrequiredのみ publicKey: publicKeyCredentialRequestOptions }; return navigator.credentials.get(credentialRequestOptions) .then(function(credential){ // submit to Relying Party server });

Slide 20

Slide 20 text

Copyright © Yoshikazu Nojima 2018 リプレイ攻撃を防ぐためのオプション。CSRFトークンのようなもの。例） challengeメンバ（BufferSource） 19 メンバ説明備考 challenge Relying Partyのバックエンドから受信したチャレンジデータ。バイト列。 let challenge = base64url.toBuffer(challengeBase64);

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Copyright © Yoshikazu Nojima 2018 rpIdの指定オプション。 Credential作成時と同一値の指定が必要例） ※CredentialはrpIdと紐づけられている為、作成時と異なる値を指定した場合、指定したrpIdに紐づくCredentialが見つからないエラーが発生する。 rpIdメンバ（UVString） 21 メンバ説明備考 rpId Credentialが有効なドメインのスコープを指定。 Credential作成時のrp.id let rpId = "http://localhost";

Slide 23

Slide 23 text

Copyright © Yoshikazu Nojima 2018 FIDO-U2Fのようなnon-residentKey（Authenticatorにデータを保存しない種類のCredential）をサポートするために、ユーザーに紐づくCredentialのid のリストを指定するオプション例） allowCredentialsメンバ（PublicKeyCredentialDescriptor配列） 22 メンバ説明備考 id credentialId type public-key固定 transports Authenticatorとの接続に使用できると思われる通信手段のヒント let allowCredentials = [ { id: credentialId, type: "public-key", transports: ["usb", "nfc", "ble", "internal"] } ];

Slide 24

Slide 24 text

Copyright © Yoshikazu Nojima 2018 non-residentKeyの仕組み non-residentKeyの場合、サイト（rpId）毎に秘密鍵を保存しないデバイス固有のSecretと、サイト毎に異なるcredentialIdにエンコードしたNonceから認証時に（登録時に使用した）秘密鍵を導出して使用する特徴 • サイト毎に秘密鍵を保存しないで済む ⇒書き換え可能な領域が不要、低コスト、高信頼 • 認証時にcredentialIdが必須 ⇒認証時点でユーザーの特定が必須であり、二段階目の認証要素としてのみ使用可能 23 Yubico社のサイトから図を引用 https://developers.yubico.com/U2F/Protocol_details/Key_generation.html

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Copyright © Yoshikazu Nojima 2018 まとめ • Relying PartyとしてWebAuthnを導入する場合、WebAuthnのJavaScriptのAPIを呼び出すフロントエンドと、Assertion、Attestationを検証するバックエンドの緊密な連携が必要 • バックエンドはライブラリが出始めているが、 WebAuthnのJavaScriptのAPIを呼び出してバックエンドに繋ぎこむ部分は自分で実装が必要 • WebAuthnのJavaScript APIのオプションは複雑なので、本資料ではCredentialの作成、認証の各オプション項目を網羅的に解説した 25

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Copyright © Yoshikazu Nojima 2018 パスワードの限界パスワードには以下の問題があります。 • フィッシング攻撃耐性 • 本物そっくりの偽物サイトを作成し、ユーザーを誤認させたうえでID/Passwordを入力させ詐取 • 精巧に作成されたフィッシングサイトは45%のユーザーが騙されるという研究結果も • リスト型攻撃耐性 • 脆弱な他サービスで流出したID/Passwordを用いた攻撃 • 自サービスは堅牢でも、ユーザーがパスワードを使いまわした場合、巻き添え被害の可能性 • モバイルデバイス対応 • モバイルデバイスでは複雑なパスワードの入力が不便パスワード要求はユーザーの離脱率に顕著な悪影響パスワード認証に代わる認証手段が必要 28

Slide 30

Slide 30 text

Copyright © Yoshikazu Nojima 2018 Web Authentication仕様とは最近W3Cで勧告候補になった、パスワード認証の問題点を克服したセキュアな認証を実現するためのWeb標準。セキュリティキーによる二段階認証や生体認証を実現。 ■主な特徴 • 指紋認証や顔認証など認証方式を差し替え可能 • 生体情報をサーバーで保存せず、安全性が高い • フィッシング攻撃、 CSRF攻撃対策の組込 29

Slide 31

Slide 31 text

Copyright © Yoshikazu Nojima 2018 Web Authenticationの認証フロー（概略） • ユーザー登録ユーザー認証デバイスブラウザサーバー DB RP固有公開鍵の保存承認ジェスチャ（指紋スキャン等）の実施 • RP固有公開鍵 • Credential Id • ドメイン（RP Id）のハッシュ • その他を送信 • RP固有公開鍵 • Credential Id • ドメイン（RP Id）のハッシュ • その他を送信耐タンパ領域 RP固有秘密鍵を保存 RP固有公開鍵・秘密鍵ペアを生成 • チャレンジ • チャレンジ、ドメイン(RpId）その他のハッシュクライアントデータのハッシュ、 RP Idに対する署名を生成ドメイン（RP Id）チャレンジその他の検証耐タンパ領域 • ローカル認証情報（生体情報等）を検証ユーザー検証機能付き認証デバイスの場合

Slide 32

Slide 32 text

Copyright © Yoshikazu Nojima 2018 Web Authenticationの認証フロー（概略） • ユーザー認証ユーザー認証デバイスブラウザサーバー承認ジェスチャ（指紋スキャン等）の実施 • Credential Id • 認証デバイスデータ • RP Idのハッシュ • フラグ • カウンタ • 資格情報データ • 署名を送信 • Credential Id • チャレンジ、ドメイン (RpId）その他 • 認証デバイスデータ • RP Idのハッシュ • フラグ • カウンタ • 資格情報データ • 署名を送信 • RP Idのハッシュ • チャレンジ、ドメイン(RpId）その他のハッシュ RP固有秘密鍵でRpIdのハッシュ、フラグ、カウンタ、クライアントデータのハッシュを署名ドメイン（RP Id）、署名チャレンジ、その他の検証 • チャレンジを送信ユーザー検証機能付き認証デバイスの場合耐タンパ領域 • ローカル認証情報（生体情報等）を検証 RP固有秘密鍵を読込ローカル認証公開鍵認証 DB RP固有公開鍵の読込

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright © Yoshikazu Nojima 2018 生体認証をローカル認証とするメリット生体認証をリモート認証とした場合のリスク • 生体情報は変更不可能なことから究極のプライバシー情報。取扱は慎重さが求められる • サーバーに生体情報を保存する生体認証では、生体情報は経路上で様々な攻撃に晒される • WebAuthnでは生体情報が認証デバイスから外に流通せず、安全性が高い（ローカル認証） • クライアント（ブラウザ）とサーバーは公開鍵と、公開鍵で検証できる署名を受け取るのみ • 生体情報と秘密鍵は認証デバイスのTPMやセキュアエレメントのような耐タンパ領域に保存 • デメリット • 登録時に使用した認証デバイスがないと認証できない 33 ユーザー認証デバイスブラウザサーバー DB 生体情報の検証承認ジェスチャ（生体情報）の提供 • 生体情報 • 生体情報

Slide 35

Slide 35 text

Copyright © Yoshikazu Nojima 2018 フィッシング攻撃に対する効果 • ユーザー認証ユーザー認証デバイスブラウザサーバー承認ジェスチャ（指紋スキャン等）の実施 • Credential Id • 認証デバイスデータ • RP Idのハッシュ • フラグ • カウンタ • 資格情報データ • 署名を送信 • Credential Id • チャレンジ、ドメイン (RpId）その他 • 認証デバイスデータ • RP Idのハッシュ • フラグ • カウンタ • 資格情報データ • 署名を送信 • RP Idのハッシュ • チャレンジ、ドメイン(RpId）その他のハッシュ RP固有秘密鍵でRpIdのハッシュ、フラグ、カウンタ、クライアントデータのハッシュを署名 • チャレンジを送信ユーザー検証機能付き認証デバイスの場合耐タンパ領域 • ローカル認証情報（生体情報等）を検証 RP固有秘密鍵を読込ドメイン（RP Id）、署名その他の検証 DB RP固有公開鍵の読込秘密鍵はRpId（≒ドメイン）毎に保存されており、フィッシング攻撃で他ドメインから認証要求を受けても秘密鍵は不正利用されない

Slide 36

Slide 36 text

Copyright © Yoshikazu Nojima 2018 リスト型攻撃に対する効果 • ユーザー認証ユーザー認証デバイスブラウザサーバー承認ジェスチャ（指紋スキャン等）の実施 • Credential Id • 認証デバイスデータ • RP Idのハッシュ • フラグ • カウンタ • 資格情報データ • 署名を送信 • Credential Id • チャレンジ、ドメイン (RpId）その他 • 認証デバイスデータ • RP Idのハッシュ • フラグ • カウンタ • 資格情報データ • 署名を送信 • RP Idのハッシュ • チャレンジ、ドメイン(RpId）その他のハッシュ RP固有秘密鍵でRpIdのハッシュ、フラグ、カウンタ、クライアントデータのハッシュを署名 • チャレンジを送信ユーザー検証機能付き認証デバイスの場合耐タンパ領域 • ローカル認証情報（生体情報等）を検証 RP固有秘密鍵を読込ドメイン（RP Id）、署名その他の検証 DB RP固有公開鍵の読込サーバー側に保存されるのはRP固有の公開鍵であり、他サイトで漏洩してもリスト型攻撃を受ける心配は不要

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Copyright © Yoshikazu Nojima 2018 導入のハードル（1/2）ブラウザ FIDO-U2F （＝HWトークンによる二要素認証） FIDO 2.0 （≒生体認証）備考 Chrome(Desktop) 67以降 Canaryで実装中 Chrome(Android) Canaryで実装中 Canaryで実装中 Firefox 60以降未サポート Safari 未サポート未サポート最近、正式に開発開始 Edge Edge 18 Preview以降今秋正式リリース見込 Windows Hello対応認証デバイスもサポート IE 未サポート未サポート 37 ■ブラウザの対応状況 Safariを除く主要ブラウザでは動く実装が揃いつつある。Safariも最近、開発開始 2018年8月現在

Slide 39

Slide 39 text

Copyright © Yoshikazu Nojima 2018 導入のハードル（2/2） ■認証デバイス • 認証デバイスが必要（組込、USB、NFC、BLE） • FIDO U2Fの認証デバイスも利用可能、2000円台後半～ • Windows Hello対応認証デバイスを使用可能（Edge） • Android標準の認証デバイスも利用可能（Android版Chrome） • Touch IDが利用可能予定（Mac版Chrome） ■サーバーサイド • 各言語でOSSライブラリが出始めている • 手前味噌ながら自分もJava/Springで実装 • https://github.com/webauthn4j/webauthn4j • https://github.com/ynojima/spring-security-webauthn 38

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Copyright © Yoshikazu Nojima 2018 Web Authenticationの認証フロー（詳細） • ユーザー登録ユーザー認証デバイスブラウザサーバー DB RP固有公開鍵の保存承認ジェスチャ（ローカル認証情報）の提供 • RP固有公開鍵 • Credential Id • 構成証明公開鍵証明書 • 署名 • カウンタを送信 • クライアントデータ • 構成証明 • RP Idのハッシュ • カウンタ • Credential Id • RP固有公開鍵 • 構成証明公開鍵証明書を送信耐タンパ領域 RP固有秘密鍵を保存 RP固有公開鍵・秘密鍵ペアを生成構成証明証明書を読込 • チャレンジ • RP Id • 他 • RP Idのハッシュ • クライアントデータのハッシュクライアントデータのハッシュ、 RP Idに対する署名を生成クライアントデータ、構成証明、署名、認証パス他の検証 • クライアントデータ • チャレンジ • オリジン • TokenBinding ID • 他を生成耐タンパ領域 • ローカル認証情報（生体情報等）を検証ユーザー検証機能付き認証デバイスの場合

Slide 42

Slide 42 text

Copyright © Yoshikazu Nojima 2018 Web Authenticationの認証フロー（詳細） • ユーザー認証ユーザー認証デバイスブラウザサーバー承認ジェスチャ（ローカル認証情報）の提供 • Credential Id • 認証デバイスデータ • RP Idのハッシュ • フラグ • カウンタ • 資格情報データ • 署名を送信 • Credential Id • クライアントデータ • 認証デバイスデータ • RP Idのハッシュ • フラグ • カウンタ • 資格情報データ • 署名を送信 • RP Idのハッシュ • クライアントデータのハッシュを送信 RP固有秘密鍵でRP Idのハッシュ、フラグ、カウンタ、クライアントデータのハッシュを署名クライアントデータ、認証デバイスデータ、署名他の検証 • チャレンジを送信 • クライアントデータ • チャレンジ • オリジン • TokenBinding ID • 他を生成ユーザー検証機能付き認証デバイスの場合耐タンパ領域 • ローカル認証情報（生体情報等）を検証 RP固有秘密鍵を読込

Slide 43

Slide 43 text

Copyright © Yoshikazu Nojima 2018 Web Authenticationの認証フロー（詳細） • ユーザー登録（二要素認証への適用）ユーザー認証デバイスブラウザサーバー DB RP固有公開鍵の保存承認ジェスチャ（ボタン押下）の提供 • RP固有公開鍵 • Credential Id（NonceとMAC） • 構成証明公開鍵証明書 • 署名 • カウンタを送信 • クライアントデータ • 構成証明 • RP Idのハッシュ • カウンタ • Credential Id • RP固有公開鍵 • 構成証明公開鍵証明書を送信耐タンパ領域デバイスシークレットをキーに NonceとRP Idのハッシュから RP固有公開鍵・秘密鍵ペアを導出構成証明秘密鍵、構成証明公開鍵証明書、デバイスシークレットを読込 • チャレンジ • RP Id • 他 • RP Idのハッシュ • クライアントデータのハッシュを送信構成証明秘密鍵でRP Id、クライアントデータのハッシュ、 Credential Id、RP固有公開鍵を署名クライアントデータ、構成証明、署名、認証パス他の検証 • クライアントデータ • チャレンジ • オリジン • TokenBinding ID • 他を生成 Yubico社のFIDO-U2F認証デバイスの場合 RNGでNonce を生成デバイスシークレットをキーに RP固有秘密鍵とRP IdからMACを生成

Slide 44

Slide 44 text

Copyright © Yoshikazu Nojima 2018 Web Authenticationの認証フロー（詳細） • ユーザー認証（二要素認証への適用）ユーザー認証デバイスブラウザサーバー DB Credential Id リストの取得承認ジェスチャ（ボタン押下）の提供 • フラグ • カウンタ • 署名を送信 • Credential Id • クライアントデータ • 認証デバイスデータ • RP Idのハッシュ • フラグ • カウンタ • 資格情報データ • 署名を送信耐タンパ領域デバイスシークレットをキーに NonceとRP Idのハッシュから RP固有公開鍵・秘密鍵ペアを導出デバイスシークレットを読込 • RP Idのハッシュ • クライアントデータのハッシュ • Credential Id（NonceとMAC）を送信 RP固有秘密鍵でRP Idのハッシュ、フラグ、カウンタ、クライアントデータのハッシュを署名クライアントデータ、認証デバイスデータ、署名他の検証 • Credential Idリスト • チャレンジ、RP Id、他を送信 Yubico社のFIDO-U2F認証デバイスの場合 ID/Passの入力 ID/Passの送信 • クライアントデータ • チャレンジ • オリジン • TokenBinding ID • 他を生成 DB RP固有公開鍵の読込

Slide 45

Slide 45 text

Copyright © Yoshikazu Nojima 2018 rpId：WebAuthnでサイトを区別するスコープの単位 rpIdで指定したドメイン自身、及びそのサブドメインで資格情報（鍵ペア）は共有例）以下のように、複数のサブドメインに跨って存在するサイトがあるとする ◆ rpIdが”example.com”の場合資格情報は上記すべてのドメインで有効 ◆ rpIdが”admin.example.com”の場合資格情報は”admin.example.com”のみで有効 44 id.example.com www.example.com admin.example.com

Slide 46

Slide 46 text

Copyright © Yoshikazu Nojima 2018 以下のように、複数のTLD（トップレベルドメイン）に跨って存在するサイトがあるとするこのようなドメイン自体が異なる場合でも、パスワード認証では認証用DBさえ共有していれば、同一ID/Passでログインさせることが出来ていた。 WebAuthn仕様では同一サイトとして扱えず、登録時のドメインと同一のドメインでのみ認証可異なるドメイン間での資格情報の共有（1/2） 45 example.co.jp example.com example.co.uk

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Copyright © Yoshikazu Nojima 2018 WebAuthnで異ドメイン間で資格情報を共有出来ない問題は、異ドメイン間をOpenID ConnectやSAMLでシングルサインオンさせることで緩和可能緩和策：異ドメイン間でのシングルサインオン 47 example.co.jp example.com example.co.uk ログイン後、 SSOによるリダイレクトログイン後、 SSOによるリダイレクト代表ドメインに WebAuthnでログイン