#iddance Lesson 2. Digital Identityの秋の発表資料です。 https://idance.connpass.com/event/146664/
新規登録機能の作り方@ritou#iddance Lesson.22019/11/01
View Slide
@ritou いとうりょう•(株)ミクシィ エンジニア•OpenIDファウンデーション・ジャパン エバンジェリスト•#idcon #iddance
なんで今回新規登録を扱うのか？•C向けサービスにおいては重要な機能•パスワード認証とともに成熟していて、今後大きな変化がありそう•設計等の議論があまりない
今日の内容•新規登録でやってることの振り返り•パスワードレスに向けた心の準備•Registration APIどう作る?
新規登録とは?•招待もしくは自発的に「新規登録」•ゲストプレイ状態からの「本登録」
新規登録でやること•利用規約/プラポリへの同意•サービスに必要な属性情報の登録•認証のためのクレデンシャル設定
サービスに必要な属性情報の登録•プロフィール情報•アイコン、ニックネーム、自己紹介•連絡先•email / SMS ←確認処理が必要
認証のためのクレデンシャル設定•ユーザー識別子•サービスが払い出す文字列•ユーザーが決めた文字列
認証のためのクレデンシャル設定•検証に必要な情報•アカウントリカバリーに必要な情報
認証のためのクレデンシャル設定• アカウントリカバリーとは• 検証不可能な状態を正常に戻す• 別の認証方式or複数設定+設定変更
認証同様、現状の新規登録フローはパスワード認証に最適化されている
シンプルな処理フロー1. 連絡先(SMS/Email)を要求• 登録の有無を判定し、未登録なら確認• 確認が済んだら設定2. パスワードを要求、設定3. ニックネームなどを要求、設定
連絡先(SMS/Email)の用途•サポート時の連絡•サービス内の通知
連絡先(SMS/Email)の用途•サポート時の連絡•サービス内の通知•認証時のユーザー識別子•アカウントリカバリーの所持(※)認証
認証•パスワード認証•ユーザー識別子に連絡先を指定
パスワードリセット•連絡先にURL/コード通知•秘密の質問、生年月日は単体の記憶認証として不十分•パスワードを再設定
連絡先の処理• ユーザーが入力した連絡先は本人のものではないかもしれない• 有効、登録済みの連絡先リストの精査の可能性もある(スクリーニング)• 登録の有無はエラーとして返すべきではない• 連絡先への通知には含んでも良い
ID連携/ソーシャルログインを用いる新規登録フロー
ID連携,ソーシャルログイン•サービスに必要な属性情報の登録•IdPが提供する値で補完•認証のためのクレデンシャル設定•IdPが提供するアサーションを利用
ID連携,ソーシャルログイン例:OpenID Connect•サービスに必要な属性情報の登録•ID Token/UserInfo API•認証のためのクレデンシャル設定•IdPの識別子+ユーザー識別子
ID連携の処理フロー1. IdPに認証要求2. IdPからの認証応答の処理• 連絡先の登録有無• その他属性情報の利用• IdP側のユーザーIDを紐付ける
連絡先の処理• ID連携でVerifiedでもらった値はユーザーの持ち物として扱って良い• 登録の有無はユーザーに見せても良さそう• 既に登録済みなのでログインさせたり、ユーザーに聞いたり
パスワードレス時代の新規登録フローとは？
の前に、あなたの言っているパスワードレスとは？
パスワードレスの定義•パスワードを使わなければOK？•所持 or 生体 or 記憶(ローカル?)•FIDO2 UserPresent許容？•FIDO2 UserVerified相当？•所持 + (記憶 or 生体)
パスワードさえ使わなければリスト攻撃は防げる！（他は…?）
通知を利用•SMS/Email/Push 所持のみ or 2要素•パスワードリセットでの実績•リカバリー?(通信状況が…)•複数経路用意 or 別の認証方式
FIDO2 UserPresent•所持 : フィッシングには強いが盗まれたら終わり•リカバリーどうする？(紛失、破壊)•複数Authenticator/他の認証方式
ID連携/ソーシャルログイン•自分たちでパスワード持たないのでパスワードレス•IpPはパスワード認証かも•リカバリー?(IdP死んだ、BAN)•IdPと心中 or 別の認証方式
パスワードを扱わずに複数要素でStrongの称号を！！！
FIDO2 UserVerified•所持 + (記憶 or 生体)•リカバリー？(紛失、破壊)•複数Authenticator•(複数要素が保証された)IdPと連携
ID連携を落とし所に•パスワード + U2F やってるところならFIDOと並べても良いのでは•2段階/要素であることを検証できれば使える•acr/amr @ OpenID Connect
Strongな登録フロー案1. StrongなIdPとの連携or連絡先確認• IdPから連絡先が取得できたらOK2. Authenticator設定• ID連携の場合も設定させたい3. 属性情報の設定
まだ見本となるサービスが出てきていない今がチャンスかも
新規登録APIの設計について
下記要件の新規登録API、どう設計しますか？連絡先: メールアドレス確認必須属性情報: ニックネーム、生年月日個別の画面で入力. 画面は戻ったりできる.認証方式: パスワード or Google/AppleアカウントSign-In with 何とかでよろ
標準化が進む認証に比べて 新規登録のAPIはサービス任せ•自由度が高いので考えないと…•考えたくなかったらAuth0/Firebase
必要な機能•ユーザー作成•メールアドレス設定、確認•ニックネーム設定•生年月日設定•パスワード設定•ID連携(Google/Apple)
必要な機能•ユーザー作成•メールアドレス設定、確認•ニックネーム設定•生年月日設定•パスワード設定•ID連携(Google/Apple)REST / RESTful?
必要な機能•ユーザー作成•メールアドレス設定、確認•ニックネーム設定•生年月日設定•パスワード設定•ID連携(Google/Apple)RPCor独自?
必要な機能•ユーザー作成•メールアドレス設定、確認•ニックネーム設定•生年月日設定•パスワード設定•ID連携(Google/Apple)個別?orトランザクション?
Legacy mBaaS Style?•(故)parse.com,ニフクラなんとか•淡々とAPIを叩いていく•REST/RESTful時々RPCみたいになる•ゴミデータできないか？
Transactional Style?•個別の処理後、ユーザー作成•データの持ち方はいくつか方法ありそう•一連の流れが標準化されると嬉しいかもしれない
今までに実装した例をちょっと紹介
Transactional Registration(JWT Base)•WebAppのCookie Sessionみたいな•Registration Token(JWT)にバックエンドサーバーがデータを詰めていく•フロー変更も割と柔軟にできるので個人的にはオススメ
Transactional Registration(TransactionID Base)•WebAppでCookieにセッションID入れるみたいな感じ•Registration Token(opaque)に紐づけてバックエンドサーバーがデータを保持(登録用テーブル的なの)
時間がない•他に新規登録のAPIこう作ったよみたいなのがあったら教えてください
まとめ•新規登録の流れは決まっている•KYCとか必要なのは追加が必要•パスワードレスも基本を抑えればこわくなさそう•今後はAPIの設計/実装も話していきたい(時間ぎれ)
ritou
takanorig
shunsukeono_am
coconala_engineer
yamamuteki
yutoy
h1kita
okamototakuyasr2
taichinakamura
minorun365
k1style
sat
nishiuma
garrettdimon
panda_program
trishagee
chriscoyier
chrisshort
aki_iinuma
mraible
phodgson
schacon
holman
62gerente
lara