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
MIXI Mと社内外のサービスを支える認証基盤を作るためにやってきたこと #MTDC2024
Search
ritou
March 18, 2024
Technology
3
470
MIXI Mと社内外のサービスを支える認証基盤を作るためにやってきたこと #MTDC2024
下記イベントの発表資料です。
https://techcon.mixi.co.jp/2024/d1-5.html
ritou
March 18, 2024
Tweet
Share
More Decks by ritou
See All by ritou
Password-less Journey - パスキーへの移行を見据えたユーザーの準備 @ AXIES 2024
ritou
3
1.4k
OIDF-J EIWG 振り返り
ritou
2
26
そのQRコード、安全ですか? / Cross Device Flow
ritou
4
380
Passkeys and Identity Federation @ OpenID Summit Tokyo 2024
ritou
2
700
Webアプリ開発者向け パスキー対応の始め方
ritou
4
6.1k
様々なユースケースに利用できる "パスキー" の 導入事例の紹介とUXの課題解説 @ DroidKaigi 2023
ritou
3
4.6k
パスキーはユーザー認証を どう変えるのか?その特徴と導入における課題 @ devsumi 2023 9-C-1
ritou
6
12k
Android/Chromeで体験できる 認証のための標準化仕様の 現在と未来 @ DroidKaigi 2022
ritou
2
6.9k
C向けサービスで 使われている認証方式と安全な使い方
ritou
12
3k
Other Decks in Technology
See All in Technology
フロントエンド設計にモブ設計を導入してみた / 20241212_cloudsign_TechFrontMeetup
bengo4com
0
1.9k
GitHub Copilot のテクニック集/GitHub Copilot Techniques
rayuron
24
11k
Snowflake女子会#3 Snowpipeの良さを5分で語るよ
lana2548
0
220
宇宙ベンチャーにおける最近の情シス取り組みについて
axelmizu
0
110
kargoの魅力について伝える
magisystem0408
0
200
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
150
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
12
3.4k
AI時代のデータセンターネットワーク
lycorptech_jp
PRO
1
280
バクラクのドキュメント解析技術と実データにおける課題 / layerx-ccc-winter-2024
shimacos
2
1k
[Ruby] Develop a Morse Code Learning Gem & Beep from Strings
oguressive
1
150
ハイテク休憩
sat
PRO
2
130
2024年にチャレンジしたことを振り返るぞ
mitchan
0
130
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Code Reviewing Like a Champion
maltzj
520
39k
The Invisible Side of Design
smashingmag
298
50k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
The Cult of Friendly URLs
andyhume
78
6.1k
A Philosophy of Restraint
colly
203
16k
Optimising Largest Contentful Paint
csswizardry
33
3k
GraphQLとの向き合い方2022年版
quramy
44
13k
Documentation Writing (for coders)
carmenintech
66
4.5k
4 Signs Your Business is Dying
shpigford
181
21k
Transcript
©MIXI MIXI Mと社内外のサービスを支える認 証基盤を作るためにやってきたこと 伊東 諒 開発本部 MIXI M 事業部
システムグループ オレンジチーム
©MIXI 2 内容 • MIXI Mと認証基盤の役割 • 認証基盤の設計において意識していること • 標準化仕様の積極的な利用
©MIXI 3 MIXI Mと認証基盤の役割
©MIXI 4 MIXI Mとは • 認証から決済までをワンストップで提供できる基盤システム & WALLETサービス • アカウントを登録することで「アカウントの属性情報」「決済情報」などを
MIXIの様々なサービス間で連携して利用可能
©MIXI 5 認証基盤の役割 • アカウント情報の管理 ◦ アカウントの新規登録から解約までのライフサイクル管理 ◦ 安全で便利なログイン、セッション管理 ◦
本人確認 • アクセス権限の管理 ◦ 社内外のサービスとの安全なデータ連携を実現
©MIXI 6 認証基盤の設計において 意識していること
©MIXI 7 実現したいこと • ユーザーが簡単に使える • 決済機能のような高いセキュリティ要件をもつユースケースにも対応 できる 様々なサービスから利用される認証基盤となるために、両者を実現する仕 組みを目指す
©MIXI 8 影響を受けた設計思想 The design philosophy behind OpenID Connect is
“make simple things simple and make complex things possible”. ref. https://self-issued.info/?p=619
©MIXI 9 意識していること • 利用するサービスの要件を基盤で汲み取る • ユーザー自身で確認、管理できる機能を適切に提供 • 様々な情報のライフサイクルを考慮 •
主要な機能についてのレベル分け
©MIXI 10 利用するサービスの要件を基盤で汲み取る • 電話番号/メールアドレスを必須属性として要求 • 身分証を用いた本人確認(eKYC)の採用 利用するサービスの要件に応じて機能を拡張することで、より使いやすい 基盤システムを目指す
©MIXI 11 ユーザー自身で確認、管理できる機能 • ログイン方法の管理 ◦ SMS/Email OTP、外部アカウントとのID連携、パスキー • セッション管理
◦ OS、ブラウザ、最新の利用日時の表示 ◦ セッション単位のログアウト • セキュリティイベントログ ◦ ログイン、ログアウト、アカウント情報の設定、設定解除 現状、履歴を見えるようにしておくことで、有事の際の状況確認やアカウン トリカバリーに繋げる
©MIXI 12 様々な情報のライフサイクルを考慮 • 電話番号、メールアドレス ◦ 変更、再割り当て ◦ SMSやメールが受信できない状況 •
ソーシャルログイン、パスキー ◦ 利用できない状況、環境 普遍的なものではないことを意識し、意図せぬ変更があっても対応可能に しておく
©MIXI 13 主要な機能についてのレベル分け • 認証基盤の主要な機能 ◦ 身元確認、本人確認 (Identity Proofing) ◦
ユーザー認証、当人認証 (Authentication) ◦ リソースアクセス あるアクションに対して必要なレベルを定義することで、様々なユースケー スに適用可能
©MIXI 14 身元確認、本人確認 (Identity Proofing) • メールアドレス確認 ◦ 連絡先の確保 •
SMSの確認 ◦ 連絡先の確保、botなどの大量アカウント登録対策 • 身分証を用いた本人確認 ◦ 成人であること、住所、氏名の確認 ◦ 犯罪収益移転防止法対応 身元確認のレベルは Identity Assurance Level (IAL) と呼ばれており、 特定機能の利用制限などに利用可能
©MIXI 15 当人認証 (Authentication) • Email / SMS OTP 認証
◦ 所持要素を利用する認証方式 • パスキー認証 ◦ 知識要素や生体要素のうちどれか一方と所持要素を組み合わせることで多 要素認証を実現 ユーザー認証のレベルは Authentication Assurance Level (AAL) と呼 ばれており、セッション管理や特定機能の利用制限などに利用可能
©MIXI 16 リソースアクセス • 誰でも利用可能なトークン(Bearer Token) ◦ トークンのみでリソースアクセスが可能 ◦ 漏洩時に第3者による利用が容易
• 送信者制限のあるトークン(Sender-Constrained Token) ◦ リソースアクセス時には他の情報と組み合わせる必要がある ◦ 漏洩時に第3者による利用が困難 リソースアクセスの特性に合わせて、適切なトークンの種類を選択して利 用することで様々なセキュリティレベルに対応可能
©MIXI 17 標準化仕様の積極的な利用
©MIXI 18 標準化仕様を利用するメリット • ユースケースに対応したプロファイルの活用 ◦ 想定するユースケースに対して、仕様の導入方法がプロファイルとしてまとめ られているものがある • セキュリティ、プライバシーリスクの回避
◦ 仕様策定の段階から脅威と対策が検討されており、別途ベストプラクティスが まとめられているものがある • 開発効率の向上 ◦ 各プログラミング言語のライブラリやプロダクトの利用 • 社外の開発者や利用サービスとの知見交換が可能
©MIXI 19 利用している標準化仕様 • アカウントの新規登録、ログイン ◦ WebOTP : SMSで送られた認証コードの自動入力 ◦
Passkeys : より安全で便利な認証方式 ◦ OpenID Connect Core 1.0 : モバイル端末との親和性と安全性が高いソー シャルログイン • ID連携 / リソースアクセス機能の提供 ◦ OpenID Connect Core 1.0 ◦ OAuth 2.0 ▪ MTLS : 決済関連のAPIなど ▪ Token Introspection : 利用サービス間の連携も考慮
©MIXI 20 まとめ • MIXI Mというサービスを提供しつつ、社内外のサービスに認証/決済 基盤を提供している • 幅広いサービスから利用される認証基盤となるための設計思想と考 慮している点を紹介した
• 積極的に標準化仕様を利用している ぼくのかんがえたさいきょうの認証基盤を目指してこれからもやって いきます
©MIXI