iddance2_ritou.pdf - Speaker Deck

iddance2_ritou.pdf

by ritou

Slide 1

Slide 1 text

新規登録機能の作り方 @ritou #iddance Lesson.2 2019/11/01

Slide 2

Slide 2 text

@ritou いとうりょう •(株)ミクシィエンジニア •OpenIDファウンデーション・ジャパンエバンジェリスト •#idcon #iddance

Slide 3

Slide 3 text

なんで今回新規登録を扱うのか？ •C向けサービスにおいては重要な機能 •パスワード認証とともに成熟していて、今後大きな変化がありそう •設計等の議論があまりない

Slide 4

Slide 4 text

今日の内容 •新規登録でやってることの振り返り •パスワードレスに向けた心の準備 •Registration APIどう作る?

Slide 5

Slide 5 text

新規登録とは? •招待もしくは自発的に「新規登録」 •ゲストプレイ状態からの「本登録」

Slide 6

Slide 6 text

新規登録でやること •利用規約/プラポリへの同意 •サービスに必要な属性情報の登録 •認証のためのクレデンシャル設定

Slide 7

Slide 7 text

サービスに必要な属性情報の登録 •プロフィール情報 •アイコン、ニックネーム、自己紹介 •連絡先 •email / SMS ←確認処理が必要

Slide 8

Slide 8 text

認証のためのクレデンシャル設定 •ユーザー識別子 •サービスが払い出す文字列 •ユーザーが決めた文字列

Slide 9

Slide 9 text

認証のためのクレデンシャル設定 •検証に必要な情報 •アカウントリカバリーに必要な情報

Slide 10

Slide 10 text

認証のためのクレデンシャル設定 • アカウントリカバリーとは • 検証不可能な状態を正常に戻す • 別の認証方式or複数設定+設定変更

Slide 11

Slide 11 text

認証同様、現状の新規登録フローはパスワード認証に最適化されている

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

シンプルな処理フロー 1. 連絡先(SMS/Email)を要求 • 登録の有無を判定し、未登録なら確認 • 確認が済んだら設定 2. パスワードを要求、設定 3. ニックネームなどを要求、設定

Slide 14

Slide 14 text

連絡先(SMS/Email)の用途 •サポート時の連絡 •サービス内の通知

Slide 15

Slide 15 text

連絡先(SMS/Email)の用途 •サポート時の連絡 •サービス内の通知 •認証時のユーザー識別子 •アカウントリカバリーの所持(※)認証

Slide 16

Slide 16 text

認証 •パスワード認証 •ユーザー識別子に連絡先を指定

Slide 17

Slide 17 text

パスワードリセット •連絡先にURL/コード通知 •秘密の質問、生年月日は単体の記憶認証として不十分 •パスワードを再設定

Slide 18

Slide 18 text

連絡先の処理 • ユーザーが入力した連絡先は本人のものではないかもしれない • 有効、登録済みの連絡先リストの精査の可能性もある(スクリーニング) • 登録の有無はエラーとして返すべきではない • 連絡先への通知には含んでも良い

Slide 19

Slide 19 text

ID連携/ソーシャルログインを用いる新規登録フロー

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

ID連携,ソーシャルログイン •サービスに必要な属性情報の登録 •IdPが提供する値で補完 •認証のためのクレデンシャル設定 •IdPが提供するアサーションを利用

Slide 22

Slide 22 text

ID連携,ソーシャルログイン例:OpenID Connect •サービスに必要な属性情報の登録 •ID Token/UserInfo API •認証のためのクレデンシャル設定 •IdPの識別子+ユーザー識別子

Slide 23

Slide 23 text

ID連携の処理フロー 1. IdPに認証要求 2. IdPからの認証応答の処理 • 連絡先の登録有無 • その他属性情報の利用 • IdP側のユーザーIDを紐付ける

Slide 24

Slide 24 text

連絡先の処理 • ID連携でVerifiedでもらった値はユーザーの持ち物として扱って良い • 登録の有無はユーザーに見せても良さそう • 既に登録済みなのでログインさせたり、ユーザーに聞いたり

Slide 25

Slide 25 text

パスワードレス時代の新規登録フローとは？

Slide 26

Slide 26 text

の前に、あなたの言っているパスワードレスとは？

Slide 27

Slide 27 text

パスワードレスの定義 •パスワードを使わなければOK？ •所持 or 生体 or 記憶(ローカル?) •FIDO2 UserPresent許容？ •FIDO2 UserVerified相当？ •所持 + (記憶 or 生体)

Slide 28

Slide 28 text

パスワードさえ使わなければリスト攻撃は防げる！（他は…?）

Slide 29

Slide 29 text

通知を利用 •SMS/Email/Push 所持のみ or 2要素 •パスワードリセットでの実績 •リカバリー?(通信状況が…) •複数経路用意 or 別の認証方式

Slide 30

Slide 30 text

FIDO2 UserPresent •所持 : フィッシングには強いが盗まれたら終わり •リカバリーどうする？(紛失、破壊) •複数Authenticator/他の認証方式

Slide 31

Slide 31 text

ID連携/ソーシャルログイン •自分たちでパスワード持たないのでパスワードレス •IpPはパスワード認証かも •リカバリー?(IdP死んだ、BAN) •IdPと心中 or 別の認証方式

Slide 32

Slide 32 text

パスワードを扱わずに複数要素でStrongの称号を！！！

Slide 33

Slide 33 text

FIDO2 UserVerified •所持 + (記憶 or 生体) •リカバリー？(紛失、破壊) •複数Authenticator •(複数要素が保証された)IdPと連携

Slide 34

Slide 34 text

ID連携を落とし所に •パスワード + U2F やってるところならFIDOと並べても良いのでは •2段階/要素であることを検証できれば使える •acr/amr @ OpenID Connect

Slide 35

Slide 35 text

Strongな登録フロー案 1. StrongなIdPとの連携or連絡先確認 • IdPから連絡先が取得できたらOK 2. Authenticator設定 • ID連携の場合も設定させたい 3. 属性情報の設定

Slide 36

Slide 36 text

まだ見本となるサービスが出てきていない今がチャンスかも

Slide 37

Slide 37 text

新規登録APIの設計について

Slide 38

Slide 38 text

下記要件の新規登録API、どう設計しますか？連絡先: メールアドレス確認必須属性情報: ニックネーム、生年月日個別の画面で入力. 画面は戻ったりできる. 認証方式: パスワード or Google/Appleアカウント Sign-In with 何とかでよろ

Slide 39

Slide 39 text

標準化が進む認証に比べて  新規登録のAPIはサービス任せ •自由度が高いので考えないと… •考えたくなかったらAuth0/Firebase

Slide 40

Slide 40 text

必要な機能 •ユーザー作成 •メールアドレス設定、確認 •ニックネーム設定 •生年月日設定 •パスワード設定 •ID連携(Google/Apple)

Slide 41

Slide 41 text

必要な機能 •ユーザー作成 •メールアドレス設定、確認 •ニックネーム設定 •生年月日設定 •パスワード設定 •ID連携(Google/Apple) REST / RESTful?

Slide 42

Slide 42 text

必要な機能 •ユーザー作成 •メールアドレス設定、確認 •ニックネーム設定 •生年月日設定 •パスワード設定 •ID連携(Google/Apple) RPC or 独自?

Slide 43

Slide 43 text

必要な機能 •ユーザー作成 •メールアドレス設定、確認 •ニックネーム設定 •生年月日設定 •パスワード設定 •ID連携(Google/Apple) 個別? or トランザクション?

Slide 44

Slide 44 text

Legacy mBaaS Style? •(故)parse.com,ニフクラなんとか •淡々とAPIを叩いていく •REST/RESTful時々RPCみたいになる •ゴミデータできないか？

Slide 45

Slide 45 text

Transactional Style? •個別の処理後、ユーザー作成 •データの持ち方はいくつか方法ありそう •一連の流れが標準化されると嬉しいかもしれない

Slide 46

Slide 46 text

今までに実装した例をちょっと紹介

Slide 47

Slide 47 text

Transactional Registration (JWT Base) •WebAppのCookie Sessionみたいな •Registration Token(JWT)にバックエンドサーバーがデータを詰めていく •フロー変更も割と柔軟にできるので個人的にはオススメ

Slide 48

Slide 48 text

Transactional Registration (TransactionID Base) •WebAppでCookieにセッションID入れるみたいな感じ •Registration Token(opaque)に紐づけてバックエンドサーバーがデータを保持(登録用テーブル的なの)

Slide 49

Slide 49 text

時間がない •他に新規登録のAPIこう作ったよみたいなのがあったら教えてください

Slide 50

Slide 50 text

まとめ •新規登録の流れは決まっている •KYCとか必要なのは追加が必要 •パスワードレスも基本を抑えればこわくなさそう •今後はAPIの設計/実装も話していきたい(時間ぎれ)