標準技術に携わる理由と標準化活動のやり方について 〜ID連携・認証領域の事例〜 #ヤフー名古屋

ヤフー名古屋 Tech Meetup #4 OSSコミッターNight 標準技術に携わる理由と標準化活動のやり方について 〜ID連携・認証領域の事例〜 2019年11月12日 ヤフー株式会社 倉林 雅 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

プロフィール 倉林 雅（くらはやし まさる） ヤフー株式会社 認証技術黒帯 / ID・セキュリティエンジニア OpenID ファウンデーション・ジャパン 理事 / エバンジェリスト 2

kura @kura_lab 2019/06/11 OAuth 2.0弁当できました 認可フロー を覚えてもらいたい旦那さんや息子さん に「このGrant Typeを答えよ」、または シーケンス図を未完成にしておくことで 「AuthZ Codeフローを完成させよ」など を出題してお昼ご飯を食べながら学んで いただくのはどうでしょうか #OAuth #エンジニア弁当 4 144 331 https://twitter.com/kura_lab 3

黒帯制度 該当分野について突出した知識とスキルを 持っている第一人者 KURO-OBI 黒帯制度 http://hr.yahoo.co.jp/workplace/culture.html 4

アジェンダ 1. 標準技術と普及・啓発活動について 2. 標準化活動への参加方法（OpenID・OAuth領域） 3. Yahoo! JAPAN IDにおける標準仕様の活用例 4. まとめ 5

標準技術と普及・啓発活動について

標準仕様を活用する理由 品質・安全性の担保 • 検討された機能要件やセキュリティ要件が盛り込まれている 相互接続性・互換性の確保 • 仕様が統一されるため相互接続が容易 生産コスト・導入コスト削減 • 0から設計する必要がなく工数が省ける • 標準仕様に対応したOSSなどが利用できる 7

標準化に携わる理由 インターネットの課題解決につながる • 変化し続けるインターネットの課題を最新技術で解決できる 自らの学びになる • 機能要件から自社サービスでの活用を検討できる • セキュリティ要件や英語が勉強ができる サービスへの利活用の起点となる • インターネットで起こっているトレンドを知ることができる • 仕様のユースケースから自社サービスでの利活用を検討できる 8

普及・啓発活動をする理由 多くの課題解決とサービス改善 • 多くの企業やサービスの抱える課題をより多く解決できる • よりよいサービスをユーザーに届け、ビジネスの成功につなげる 知見の共有とフィードバックの収集 • 情報共有することでフィードバックや気づきが得られる 恩返しとして次の世代につなげる • 自身の成長や自社の改善につながったコミュニティーに恩返し • 関係企業やエンジニアを増やしコミュニティーを活発にする • 部署や会社を超えて標準化活動をする後継者をつくりたい 9

標準化活動への参加方法 （OpenID・OAuth領域）

階層ごとに標準化団体があり標準技術が策定されている 2 標準化の歴史 -標準の分類- 「標準」は地理上，政治上または経済上の水準から四つの階層(hierarchy)に分類 できる。 地域標準，国家標準， 地方標準は国際標準と協 調することにより，規格開 発の重複を避けたり，下 位の標準を国際標準とし て採用されるような取リ組 みを行っている。 国際標準 地域標準 国家標準 団体標準 イギリス ドイツ フランス 日本 アメリカ 標準化機関の例 標準化の意義 19 https://www.jsa.or.jp/datas/media/10000/md_2416.pdf

ID・認証領域の標準化団体 認証・認可技術、ID管理やプライバシーの規格が策定されている I E T F OpenID fido ISO OAuthなどのIETFの標準仕様の探し方・読み方をご紹介 12

RFC・I-Dを探して読む IETFとは • The Internet Engineering Task Force • 個人で会合やMLの議論に参加可能なインターネット技術の標準化を推進する任意団体 RFCとは • Request For Comment（コメント求む） • IETFによって作成されるインターネット関連技術の仕様やポリシーを記述したもの I-Dとは • Internet-Draft • RFCになる前の下書き、草稿 • IETFのWorking Group内でレビューが繰り返されRFCになる 13

Datatracker I E T F Datatracker The IETF Datatracker is the day-to-day front-end to the IETF database for people who work on IETF standards. It contains data about the documents, working groups, meetings, agendas, minutes, presentations, and more, of the IETF. The primary public face of the IETF is at www.ietf.org. IETF Document Search Document name/title/RFC number Additional search criteria 全てのRFCは「Datatracker」に 集約されている https://datatracker.ietf.org 14

Datatracker I E T F The IETF Da It contains da Active WGs Active RGs Other Applications and Real-Time General Internet Ops & Mgmt Routing Security Transport IRTF rk ng groups Concluded groups Non-WG lists Additional search criteria 領域ごとにAREAが分かれている AREAの中でさらにWorking Group(WG)が分かれている oauth - Web Authorization Protocol 15

Web Authorization Protocol (oauth) 策定中のI-Dの一覧 Active Internet-Drafts (11 hits) draft-ietf-oauth-access-token-jwt-02 2019-07-24 I-D Exists JSON Web Token (JWT) Profile for OAuth 2.0 16 pages WG Document Access Tokens draft-ietf-oauth-browser-based-apps-04 2019-09-21 I-D Exists OAuth 2.0 for Browser-Based Apps 20 pages WG Document draft-ietf-oauth-incremental-authz-03 2019-11-04 I-D Exists OAuth 2.0 Incremental Authorization 9 pages WG Document 策定終了したRFCの一覧 RFCs (18 hits) RFC 6749 (was draft-ietf-oauth-v2) 2012-10 Proposed Standard RFC The OAuth 2.0 Authorization Framework 70 pages Updated by RFC8252 RFC 6750 (was draft-ietf-oauth-v2-bearer) 2012-10 The OAuth 2.0 Authorization Framework: Bearer 18 pages Token Usage 16

The OAuth 2.0 Authorization Framework RFC 6749 策定されたI-Dのバージョンが 時系列で整理されている IETFは「Rough Consensus」と 「Running Code」が特徴 ラフな仕様を作成し 相互接続実験や実運用を通じて 改善し仕様を決めていく 17

[Docs] [txt|pdf] [draft-ietf-oaut...] [Tracker] [Diff1] [Diff2] [IPR] [Errata] Updated by: 8252 PROPOSED STANDARD Errata Exist Internet Engineering Task Force (IETF) D. Hardt, Ed. Request for Comments: 6749 Microsoft Obsoletes: 5849 October 2012 Category: Standards Track ISSN: 2070-1721 The OAuth 2.0 Authorization Framework Abstract The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. OAuth 2.0のRFC 18

RFCの構成 構成は決まっているため 同じ要領で他のRFCも読める タイトル Abstract Status of This memo 定型文 Copyright Notice Table of Contents(目次) 1. Introduction 1.1 Conventions and Terminology 助動詞の使い方(RFC2119)を定義した定型文 2〜本文 X.Security Considerations Y.IANA Considerations セキュリティ上の懸念や番号資源へ影響があ るかどうか、について記載必須となっている。 Z.References (ただしI-Dでは記載が後回しにされることが多 い) Acknowledgements Author's Address さらに詳しい読み方は以下を参照 RFC/Internet-Draftの読み方 -第1回IETF報告会- 19

国内コミュニティーに参加する 認証・認可関連の情報共有や議論がなされているコミュニティー Internet Society Japan Chapter OpenID Japan #idcon #iddance 最新のI-Dの策定状況やRFCの活用情報を得るための 国内コミュニティーの参加方法のご紹介 20

IETF105Update IETF報告会（105th モントリオール）/ IETF105 Update Meeting IETFの参加者が会合後に 国内メンバー向けに報告会を実施 https://www.isoc.jp/ 21

OpenID Japan 会員企業向けのBizdayや 一般参加も可能なTechNightを開催 IETFの他にもOpenID Foundationや 関連の標準化団体で策定されている 技術について情報共有がなされる https://www.openid.or.jp 22

#idcon トレンドな認証・認可技術に 関しての勉強会 #idconとは？ #idcon - Identity Conference - は、「ID厨」と呼ばれるIdentity愛好家達が、オ 夜に集まって、世界および日本のIdentity技術やそれを取り巻く情勢について す。OpenID、OAuth、SAMLなどの技術動向だけでなく、国民ID、プライバシー いても議論したりします。 興味ある方は、idcon.org FB page をsubscribe したり、Twitter で #idcon という グを追いかけたりしていると、最新イベント情報などが流れてくると思います。 また、次回 #idcon で聞きたい/話したいテーマ等あれば、FB page へのポストな のmentionなりしていただければ対応できる、かも！ http://idcon.org https://idcon.connpass.com 23

Identity Dance School 初心者にオススメな OpenIDやOAuthの勉強会 https://idance.connpass.com 24

海外・国内カンファレンスに参加する IETFは定期的に年3回ほど開催 OpenID ファウンデーション・ジャパンは4年ぶりに開催 I E T F OpenID Japan 誰でも参加できる直近開催予定のカンファレンスをご紹介 25

2020年3月にバンクーバーで開催 参加費は必要だが 会員費用は不要で個人で参加可能 IETF 107 Vancouver 21 Mar 2020 - 27 Mar 2020 IETF 107 starts Saturday 21 March and runs through Friday afternoon, 27 March. The IETF Hackathon and IETF Codesprint take place on the weekend.Newcomers' training and technical tutorials take place on Sunday afternoon. Participants should plan their travel accordingly. The schedule may be updated very close to the start to the meeting. WGで策定中の仕様に対して 意見を述べることができる https://www.ietf.org/how/meetings/107/ 26

OpenID Summit Tokyo 2020 2020年1月に渋谷で開催 参加費無料 誰でも参加可能 IDや認証の技術だけでなく 金融やブロックチェーン関連の セッションもあり https://www.openid.or.jp/summit/2020/ 27

Yahoo! JAPAN IDにおける標準仕様の活用例 OpenID Connect

OpenID Connectの活用 「ユーザー認証」と「属性情報取得」を利用した パートナーサービスへのID連携提供と ヤフー公式アプリのログイン機能提供 29

所持しているIDのサービスを選択 ログインをする 30

同意をする 情報がプリセットされる 31

ヤフーのアプリ間で ログインを共有して 1タップログイン 初回起動時に 自動でログインする 0タップログイン 32

用語集 IdP (Identity Provider) • 認証を行ってID、属性情報を提供する RP (Relying Party) • IdPの認証を利用してEnd-Userにサービスを提供する Claim • IdPやEnd-Userなどの属性情報 33

用語集 IdP (Identity Provider) • 認証を行ってID、属性情報を提供する RP (Relying Party) • IdPの認証を利用してEnd-Userにサービスを提供する Claim • IdPやEnd-Userなどの属性情報 OpenID Connectでは IDを管理・認証する サーバーはRPではない 認証結果を受け取る側が RPと覚えとくとよい 34

OpenIDとは • OpenIDはユーザーの認証の技術 • (OpenID AXで属性を取得する拡張はある) 35

OpenID 2006年 • OpenID Authentication 1.1 • OpenID Simple Registration Extension 1.0 2007年 • OpenID Authentication 2.0 • OpenID Attribute Exchange 1.0 36

OAuth • OAuth 1.0とOAuth 2.0はユーザーの認可の技術 • ユーザーのリソースアクセス（Web API）が目的 37

OAuth 2009年 • OAuth 1.0a 2010年 • OAuth 1.0 Protocol 2012年 • OAuth 2.0 Authorization Framework 38

OpenID Connectとは • ユーザーの認証と認可を兼ね備えた技術 • OpenIDとは異なる技術でOAuth 2.0を拡張した プロトコル • 2014年2月にローンチ 39

OpenID Connect Protocol Suite 4 Feb 2014 http://openid.net/connect Core Minimal Discovery Dynamic Client Registration Dynamic Session Management Form Post Response Mode Complete Underpinnings OAuth 2.0 Core OAuth 2.0 Bearer OAuth 2.0 Assertions OAuth 2.0 JWT Profile OAuth 2.0 Responses JWT JWS JWE JWK JWA WebFinger 40

OpenID Connect Protocol Suite OpenID ConnectはOAuth 2.0や JSON Web Tokenなどの技術で構成されている Underpinnings OAuth 2.0 Core OAuth 2.0 Bearer OAuth 2.0 Assertions OAuth 2.0 JWT Profile OAuth 2.0 Responses JWT JWS JWE JWK JWA WebFinger 41

OpenID Connect Web API連携・ユーザー認証・ ユーザー属性情報取得に 必要な仕様が定義されている OAuth 2.0 認可 + JSON Web Token 認証 + 属性取得 42

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo Authorization Code Flowの場合 IdPの認証結果を受け取るのは Back-End Server 43

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 44

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 1.Authorizationリクエスト RPからIdPへ認証・認可を User Agentを利用して GETのリダイレクト（もしくはPOST） でリクエスト 45

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 1.Authorizationリクエスト 2.ログイン画面 3.クレデンシャル 情報入力 4.同意画面 5.同意 IdPがログイン・同意をユーザーに要求 46

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 1.Authorizationリクエスト 2.ログイン画面 3.クレデンシャル 情報入力 4.同意画面 5.同意 6.Authorization Code ユーザーが認可した情報が Authorization Codeとして User Agentを通じて Back-End Serverへ返却される Access Token等を 直接Clientサイドへ返却せず 有効期限の短い一時トークンとして Authorization Codeを 返却するためImplicit Flowよりも強固 47

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 1.Authorizationリクエスト 2.ログイン画面 3.クレデンシャル 情報入力 4.同意画面 5.同意 6.Authorization Code 7.Tokenリクエスト(Authorization Code) Authorization Codeに加えてサーバー間で Client IDとClient Secretによるクライアント認証を 行うためImplicit Flowよりも強固 48

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 1.Authorizationリクエスト 2.ログイン画面 3.クレデンシャル 情報入力 4.同意画面 5.同意 6.Authorization Code 7.Tokenリクエスト 8.Access Token/ID Token 認可のAccess Tokenと IdPが行ったユーザー認証の 情報を含むID Tokenを返却 49

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 1.Authorizationリクエスト 2.ログイン画面 3.クレデンシャル 情報入力 4.同意画面 5.同意 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 8.Access Token/ID Token 9.ログインセッション 発行 10.ログイン完了 ID Tokenを検証しClientで ログイン処理を完了 50

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 1.Authorizationリクエスト 2.ログイン画面 3.クレデンシャル 情報入力 4.同意画面 5.同意 6.Authorization Code 7.Token 8.Access Token/ID To 9.ログインセッション 発行 10.ログイン完了 11.Access Token 属性情報の取得が必要な場合は UserInfoエンドポイントへ Access Tokenを送信 51

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 1.Authorizationリクエスト 2.ログイン画面 3.クレデンシャル 情報入力 4.同意画面 5.同意 6.Authorization Code 7.Tokenリクエスト(Authorization Code) Token 11.Access Token 10.ログイン完了 12.Claims 13.属性情報取得完了 各属性情報がJSONで返却される 52

Authorization Code Flow End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 1.Authorizationリクエスト 2.ログイン画面 3.クレデンシャル 情報入力 4.同意画面 5.同意 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 9.ログインセッション 発行 8.Access Token/ID Token 10.ログイン完了 11.Access Token 12.Claims 13.属性情報取得完了 53

OpenID Connectを活用して得られた利点 • 品質やセキュリティが担保されているため、要件 検討のコストが削減できた • パートナーやグループ企業へのID連携導入コス トが削減された • パートナーだけでなくヤフーのアプリのログイン 機能も共通の認証基盤で提供できた 54

Yahoo! JAPAN IDにおける標準仕様の活用例 FIDO

FIDOの活用 「セキュリティとUXを両立したユーザー認証」を 活用してパスワードレスを実現 56

ヤフー、新たなウェブ認証の規格「FIDO2」のFIDO Certified (認定) を国内企業で唯一取得 パスワードを使わない安全なログイン環境の実現に前進 ヤフー株式会社（以下、ヤフー）は、生体認証などの次世代認証の標準化を提唱する業界団体FIDO（ファイド）アライアンスの 新たな規格「FIDO2」の認定を、2018年8月に世界で初めて開催された「FIDO2」認定テストにおいて、このたび取得したことを お知らせします。国内企業では唯一の認定取得となります。 fido CERTIFIED FIDO2 「FIDO2」は、生体認証デバイスなどを利用して、ウェブブラウザーを通じたオンラインサービスへの安全なログインを実現する 規格です。ヤフーは「FIDO2」の認定を取得したことにより、同じく「FIDO2」の認定を取得した他社の生体認証デバイスなどと の接続が担保されます。これにより、従来はログイン時にパスワードやSMS・メールで送られる確認コードの入力が必要でした が、今後はスマートフォンの指紋認証などの生体認証を利用してログインできるようになります。また、確認コードでのログイ ンと同様、パスワードを使わない（パスワードレス）ため、“リスト型攻撃”による不正アクセスのリスクを解消できます。 57

ログインが求められる 58

パスワードや確認コードを入力せずに 生体認証などでログイン 59

用語集 • クレデンシャル情報 • パスワードや生体情報などユーザー認証に必要な情報 • RP (Relying Party) • ユーザーのIDを登録、認証し管理するサーバー（FIDO2 Server） • Authenticator（認証器） • 秘密鍵・公開鍵のペアを生成し、RPへ送信する署名を生成する 60

用語集 • Client-Side • Authenticatorやユーザー端末などの総称 • WebAuthn Client • ブラウザーなどのUser Agent 61

FIDOとは • FIDO = Fast IDentity Online（高速なオンラインID認証） • 顔や指紋のクレデンシャル情報をサーバーへ送らず保存しない • 生体認証などのさまざまな認証方法に対応 fido 62

従来の認証モデル • IDとクレデンシャル情報（パスワードなど）を認証サーバーへ送信 • 認証サーバーはIDとクレデンシャル情報を検証し認証 • パスワードなどを入力する場合、通信経路での漏洩やフィッシングでの 窃取の懸念あり • クレデンシャル情報を認証サーバーで保存するため漏洩のリスクは大きい ユーザー LOGIN username クレデンシャル情報 (パスワード) 認証サーバー クレデンシャル 情報の検証 クレデンシャル情報 (パスワード) 63

FIDO認証モデル • デバイスの認証器(Authenticator)が本人性を検証 • 検証結果に秘密鍵で署名し認証サーバーに送信 • 認証サーバーで公開鍵を使って署名を検証しユーザーを認証 • クレデンシャル情報が流れないため、パスワードのフィッシング耐性あり ユーザー クレデンシャル 情報の入力 検証結果（署名） 認証サーバー 検証結果の 妥当性を確認 秘密鍵 公開鍵 64

FIDOで提供している仕様 FIDO Allianceでは パスワードレス型、パスワード補完型、 FIDO認証を拡大するための拡張仕様の3つを標準化している UAF U2F FIDO2 CTAP WebAuthn 65

FIDO UAF • UAF = Universal Authentication Framework • 主にスマートフォン（アプリ）を想定した パスワードレス型の認証 • 所持認証 + 生体認証など UAF 66

FIDO U2F • U2F = Universal 2nd Factor • 主にPCのWebブラウザーで二要素認証を 想定したパスワード補完型の認証 • 記憶認証 + 所持認証 U2F 67

FIDO2 • FIDO2の仕様は、FIDO AllianceのClient-to- Authenticator Protocol(CTAP)とW3Cの WebAuthnから構成される • スマートフォンとPCを想定し、一般的なデバイス （USB、BLE、NFCなどが利用 できる端末）を活用した認証 FIDO2 CTAP WebAuthn 68

CTAPとWebAuthn • CTAPはAuthenticator（認証器）とWebAuthn Clientの通信を 定義するプロトコル • WebAuthnはRelying Party（FIDO2認証サーバー）から WebAuthn Client経由でクレデンシャルを操作するプロトコル CTAP2 WebAuthn USB/BLE/NFC... Authenticator WebAuthn Client（ブラウザーなど） Relying Party 69

FIDO2登録フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) FIDOはサーバーがRP 70

FIDO2登録フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.登録開始 0-2.ログインID 既存のログインIDに対して FIDOの登録開始 ※ログインIDがない場合もある 71

FIDO2登録フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.登録開始 0-2.ログインID 1.navigator.credential.create() 2.認証要求 JavaScript API経由でユーザー認証と Authenticatorへ鍵ペアの生成を要求 72

FIDO2登録フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.登録開始 0-2.ログインID 1.navigator.credential.create() 2.認証要求 3.認証要求 4.認証 5.秘密鍵/公開鍵生成 秘密鍵格納 Authenticatorが指紋や顔などの 認証を要求し、認証を終えると鍵ペアを 生成し秘密鍵をAuthenticator内に保存 73

FIDO2登録フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.登録開始 0-2.ログインID 1.navigator.credential.create() 2.認証要求 3.認証要求 4.認証 5.秘密鍵/公開鍵生成 秘密鍵格納 6.公開鍵 7.公開鍵 8.ログインIDに 公開鍵を保存 公開鍵のみをRPへ送信し ログインIDへ紐付けて保存 74

FIDO2登録フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.登録開始 0-2.ログインID 1.navigator.credential.create() 2.認証要求 3.認証要求 4.認証 5.秘密鍵/公開鍵生成 秘密鍵格納 6.公開鍵 7.公開鍵 8.ログインIDに 公開鍵を保存 9.登録完了 10.登録完了 75

FIDO2認証フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) FIDOはサーバーがRP 76

FIDO2認証フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.ログイン開始 0-2.ログインID 登録しているログインIDを 指定して認証開始 77

FIDO2認証フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.ログイン開始 0-2.ログインID 1.challenge生成 2.navigator.credential.get() 3.認証要求 challengeを生成しWebAuthn Clientへ送信 JavaScript API経由で Authenticatorに保存してある秘密鍵を取得 78

FIDO2認証フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.ログイン開始 0-2.ログインID 1.challenge生成 2.navigator.credential.get() 3.認証要求 4.認証要求 5.認証 6.秘密鍵を検索 challengeを秘密鍵で署名 Authenticatorが認証を要求し 認証が完了すると 秘密鍵でchallengeに署名 79

FIDO2認証フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.ログイン開始 0-2.ログインID 1.challenge生成 2.navigator.credential.get() 3.認証要求 4.認証要求 5.認証 6.秘密鍵を検索 challengeを秘密鍵で署名 7.署名されたchallenge 8.署名されたchallenge 9.署名を 公開鍵で検証 署名されたchallengeを RPに保存している公開鍵で検証 80

FIDO2認証フロー End-User Client-Side Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) 0-1.ログイン開始 0-2.ログインID 1.challenge生成 2.navigator.credential.get() 3.認証要求 4.認証要求 5.認証 6.秘密鍵を検索 challengeを秘密鍵で署名 7.署名されたchallenge 8.署名されたchallenge 9.署名を 公開鍵で検証 10.認証完了 11.認証完了 81

FIDOを活用して得られた利点 • ネイティブアプリやブラウザーで生体認証が利用可能 • サーバーサイドに生体情報を保持することはないため 情報漏えいが発生してもリスクは少ない • SMS認証、メールアドレス認証の確認コードの入力も 不要になり再認証の手間がなくなりUXも向上 82

まとめ 1. 標準技術と普及・啓発活動について • 品質・セキュリティの担保やコスト削減が期待できる • 最新技術の学びやサービス改善につながる 2. 標準化活動への参加方法（OpenID・OAuth領域） • DatatrackerでRFCを探して読める • ISOC-JPやOpenIDなどの国内コミュニティーがある • IETFやOpenID Summitが近日開催される 3. Yahoo! JAPAN IDにおける標準仕様の活用例 • OpenID ConnectでパートナーとのID連携を容易できた • ヤフーのアプリでパスワードレスを実現しログイン体験を改善 83

興味を持たれた方は ぜひ標準化活動に参加してみませんか 84

ご清聴ありがとうございました 85