Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
iddance2_ritou.pdf
Search
ritou
November 01, 2019
Technology
1
4.5k
iddance2_ritou.pdf
#iddance Lesson 2. Digital Identityの秋の発表資料です。
https://idance.connpass.com/event/146664/
ritou
November 01, 2019
Tweet
Share
More Decks by ritou
See All by ritou
OIDF-J EIWG 振り返り
ritou
2
15
そのQRコード、安全ですか? / Cross Device Flow
ritou
4
330
MIXI Mと社内外のサービスを支える認証基盤を作るためにやってきたこと #MTDC2024
ritou
2
420
Passkeys and Identity Federation @ OpenID Summit Tokyo 2024
ritou
2
660
Webアプリ開発者向け パスキー対応の始め方
ritou
4
6k
様々なユースケースに利用できる "パスキー" の 導入事例の紹介とUXの課題解説 @ DroidKaigi 2023
ritou
3
4.5k
パスキーはユーザー認証を どう変えるのか?その特徴と導入における課題 @ devsumi 2023 9-C-1
ritou
6
12k
Android/Chromeで体験できる 認証のための標準化仕様の 現在と未来 @ DroidKaigi 2022
ritou
2
6.7k
C向けサービスで 使われている認証方式と安全な使い方
ritou
12
2.9k
Other Decks in Technology
See All in Technology
신뢰할 수 있는 AI 검색 엔진을 만들기 위한 Liner의 여정
huffon
0
450
大規模データ基盤チームのオンプレTiDB運用への挑戦 / dpu-tidb
cyberagentdevelopers
PRO
1
110
【若手エンジニア応援LT会】AWSで繋がり、共に成長! ~コミュニティ活動と新人教育への挑戦~
kazushi_ohata
0
260
新卒1年目が向き合う生成AI事業の開発を加速させる技術選定 / ai-web-launcher
cyberagentdevelopers
PRO
8
1.6k
DatabricksにおけるLLMOpsのベストプラクティス
taka_aki
4
1.4k
家具家電付アパートの冷蔵庫をIoT化してみた!
scbc1167
0
140
AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book
iselegant
18
4.2k
LINEヤフー株式会社における音声言語情報処理AI研究開発@SP/SLP研究会 2024.10.22
lycorptech_jp
PRO
2
230
「視座」の上げ方が成人発達理論にわかりやすくまとまってた / think_ perspective_hidden_dimensions
shuzon
2
13k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
49k
ガチ勢によるPipeCD運用大全〜滑らかなCI/CDを添えて〜 / ai-pipecd-encyclopedia
cyberagentdevelopers
PRO
3
240
Forget efficiency – Become more productive without the stress
ufried
0
190
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
33
2.9k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
4
380
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Designing for humans not robots
tammielis
249
25k
YesSQL, Process and Tooling at Scale
rocio
167
14k
It's Worth the Effort
3n
183
27k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
How GitHub (no longer) Works
holman
310
140k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
330
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
7
160
Transcript
新規登録機能の作り方 @ritou #iddance Lesson.2 2019/11/01
@ritou いとうりょう •(株)ミクシィ エンジニア •OpenIDファウンデーション・ジャパン エバ ンジェリスト •#idcon #iddance
なんで今回 新規登録を扱うのか? •C向けサービスにおいては重要な機能 •パスワード認証とともに成熟してい て、今後大きな変化がありそう •設計等の議論があまりない
今日の内容 •新規登録でやってることの振り返り •パスワードレスに向けた心の準備 •Registration APIどう作る?
新規登録とは? •招待もしくは自発的に「新規登録」 •ゲストプレイ状態からの「本登録」
新規登録でやること •利用規約/プラポリへの同意 •サービスに必要な属性情報の登録 •認証のためのクレデンシャル設定
サービスに必要な 属性情報の登録 •プロフィール情報 •アイコン、ニックネーム、自己紹介 •連絡先 •email / SMS ←確認処理が必要
認証のための クレデンシャル設定 •ユーザー識別子 •サービスが払い出す文字列 •ユーザーが決めた文字列
認証のための クレデンシャル設定 •検証に必要な情報 •アカウントリカバリーに必要な情報
認証のための クレデンシャル設定 • アカウントリカバリーとは • 検証不可能な状態を正常に戻す • 別の認証方式or複数設定+設定変更
認証同様、現状の新規登録フローは パスワード認証に最適化されている
None
シンプルな処理フロー 1. 連絡先(SMS/Email)を要求 • 登録の有無を判定し、未登録なら 確認 • 確認が済んだら設定 2. パスワードを要求、設定
3. ニックネームなどを要求、設定
連絡先(SMS/Email)の 用途 •サポート時の連絡 •サービス内の通知
連絡先(SMS/Email)の 用途 •サポート時の連絡 •サービス内の通知 •認証時のユーザー識別子 •アカウントリカバリーの所持(※)認証
認証 •パスワード認証 •ユーザー識別子に連絡先を指定
パスワードリセット •連絡先にURL/コード通知 •秘密の質問、生年月日は単体の記憶 認証として不十分 •パスワードを再設定
連絡先の処理 • ユーザーが入力した連絡先は本人の ものではないかもしれない • 有効、登録済みの連絡先リストの精 査の可能性もある(スクリーニング) • 登録の有無はエラーとして返すべき ではない
• 連絡先への通知には含んでも良い
ID連携/ソーシャルログイン を用いる新規登録フロー
None
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から連絡先が取得できたらOK 2. 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) RPC or 独自?
必要な機能 •ユーザー作成 •メールアドレス設定、確認 •ニックネーム設定 •生年月日設定 •パスワード設定 •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の設計/実装も話していき たい(時間ぎれ)