マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • WebAuthnを実装する前に理解を深める。
  • specレベルは上位項を参照のこと。

詳細

以下に、各種、調査結果をサマリーする(まだまだ理解不足です)。

登録フロー

(1) challengeの受信

(2) navigator.credentials.create() の param

#パラメタ必須 / 任意説明フォーマット
1rp必須Relying partyに関する情報JSON Object (下記メンバを持つ)
1-1idFQDN名String
1-2name任意のRPサイト名String
2user必須Credentialが紐づくユーザー情報JSON Object (下記メンバを持つ)
2-1idRP上のユーザIDArrayBuffer?
2-2nameRP上のユーザIDString
2-3displayNameRP上のユーザ表示名String
3challenge必須サーバーで生成した乱数ArrayBuffer?
4pubKeyCredParams?必須Credential情報JSON Objectの配列
4-1typeタイプ(public-key固定)String
4-2algアルゴリズムを表す数値Int
5timeout任意ユーザーの入力待機時間Int
6attestation任意Authenticator自体の検証JSON Object (AttestationConveyancePreference?)
7authenticatorSelection任意認証器への要求事項JSON Object (AuthenticatorSelectionCriteria?)
8excludeCredentials任意JSON Object (PublicKeyCredentialDescriptor?)

(3) navigator.credentials.create() の return

#パラメタ説明フォーマット
1id割り当てられたidrawIdの文字列表現
2rawIdidのArrayBuffer?ArrayBuffer?
3responseAuthenticatorAttestationResponse?JSON Object (AuthenticatorAttestationResponse?)
3-1attestationObject公開鍵などを含むCBOR形式
3-1-1fmtAttestation format"fmt": "packed"
3-1-2authDataRaw buffer struct containing user info"authData": "{rpIdHash?: "..." ,... }"
3-1-2-1rpIdHash?
3-1-2-2flags
3-1-2-3flagsBuf
3-1-2-4counter
3-1-2-5counterBuf
3-1-2-6aaguid
3-1-2-7credID
3-1-2-8credIDLen
3-1-2-9credIDLenBuf?
3-1-2-10COSEPublicKey?
3-1-3attStmtAttestation statement data"attStmt": {sig: "", x5c: ""}
3-1-3-1sigSignature"sig": "..."
3-1-3-2x5cX.509 Certificate Chain"x5c": ["..."]
3-2clientDataJSONクライアント・データCBOR形式
3-2-1challengeRandom number"challenge": "..."
3-2-2originOrigin of the website"origin": "http(s)://..."
3-2-3typeType of the call"type": "webauthn.create"
4typepubKeyCredParams? - typeと同じ"type": "public-key"

(4) challenge、origin、typeの検証

  • techblogyahoo
    clientDataJSONの...
    • challenge
      param.challenge = return.clientDataJSON.challenge みたいな話。
    • origin
      xxxx = return.clientDataJSON.origin みたいな話。
    • type
      "webauthn.create" = return.clientDataJSON.type みたいな話。

(5) flagsの検証

  • techblogyahoo
    • UP : User Presence
      ユーザーの存在確認(必須)
    • UV : User Verification
      ユーザーの認証(任意)

(6) signatureの検証

(7) 公開鍵の保存

認証フロー

(1) challengeの受信

(2) navigator.credentials.get() の param

#パラメタ必須 / 任意説明フォーマット
1challenge必須サーバーで生成した乱数ArrayBuffer?
2timeout任意ユーザーの入力待機時間Int
3rpId任意rpIdの指定(登録時と同じ値を指定)String
4allowCredentials任意ユーザに紐づくCredentialのリストArray (PublicKeyCredentialDescriptor?)
5userVerification任意ユーザ検証に関する要件String (enum UserVerificationRequirement?)

(3) navigator.credentials.get() の return

#パラメタ説明フォーマット
1id割り当てられたidrawIdの文字列表現
2rawIdidのArrayBuffer?ArrayBuffer?
3responseassertion dataJSON Object (AuthenticatorAssertionResponse?)
3-1authenticatorDatarpIdHash?, flagsBuf, flags, counter, counterBufArrayBuffer?
3-2clientDataJSONクライアント・データArrayBuffer?
3-2-1challengeRandom number"challenge": "..."
3-2-2originOrigin of the website"origin": "http(s)://..."
3-2-3typeType of the call"type": "webauthn.create"
3-3signature署名の値ArrayBuffer?
3-4userHandle認証器が返す値ArrayBuffer?
4typeタイプ(public-key固定)String
5getClientExtensionResults?extensions results struct

(4) challenge、origin、typeの検証

  • techblogyahoo
    clientDataJSONの...
    • challenge
      param.challenge = return.clientDataJSON.challenge みたいな話。
    • origin
      xxxx = return.clientDataJSON.origin みたいな話。
    • type
      "webauthn.create" = return.clientDataJSON.type みたいな話。

(5) flagsの検証

  • fido2-net-lib ... サーバー側で処理
  • techblogyahoo
    authenticatorData.flags
    • UP : User Presence
      ユーザーの存在確認(必須)
    • UV : User Verification
      ユーザーの認証(任意)

(6) signatureの検証

  • techblogyahoo
    • Authenticatorの検索
    • PublicKey?の取得
    • signatureを検証
    • counterの検証と更新

実装例

提案されたI/F

FIDO2サーバ標準は存在しないが、

  • FIDO2適合テストツールで使用する提案されたREST APIのI/Fは存在する。
  • このI/Fは必須で無いが、Serverが標準の方法でMessageを送受信することで
    適合テストツールによって使用され、機能が自動的に検証されるようにできる。
  • 問題点
  • 登録フローには、認証が必要だと思うのだケド、
    認証実装したらテストツールも通らないんじゃないか?と。

Credential Creation Options

Authenticator Attestation

Credential Get Options

Authenticator Assertion

サーバ実装パターン

OIDCのSTS/IdP(OP)、Client(RP)のどちらでも
WebAuthnのRelying Party(RP)になれる。

IdP/Stsが実装

  • IdP/Stsに集約可能で楽。
  • 提案されたI/Fの実装
    • 登録フロー
      認証アクセスが必要だが、サイト内なのでWebAPIよりポストバックがイイ
    • 認証フロー
      認証後に画面遷移が必要なのでWebAPIよりポストバックがイイ

RP & BaaSが実装

  • 折衷案
    • RPがWebAuthnを操作し、
    • バックエンドのIDaaS -> BaaSを使用して公開鍵を管理する。
  • 提案されたI/Fの実装
    • 登録フロー
      RPは、IdP/Stsと連携し、
      Resource Serverとして機能するBaaSに公開鍵を登録。
    • 認証フロー
      BaaSに登録した公開鍵を取得するために、
      Client認証のみのグラント種別を使用しRPの認証をする。

RPが実装

  • IdP/Sts
    • のコントロールが効かない場合。
    • を、そもそも、保有しない場合。

実現できるUX

2FAのUserExperience

PasswordlessのUserExperience

参考

fido2-net-lib

techblogyahoo

登録フロー

認証フロー

パラメタ

Web Authentication API

gist.github.com/daisukenishino2

https://gist.github.com/daisukenishino2/f09fb400fa2186aead4b6f8cad59ab38#gistcomment-2852202

Ackermann Yuriy – Medium

Mercari Engineering Blog

enjoy struggling

Qiita

ritou

r-weblife

Qiita


Tags: :IT国際標準, :認証基盤


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-06-05 (水) 17:38:34 (108d)