MIXI Mと社内外のサービスを支える認証基盤を作るためにやってきたこと #MTDC2024

下記イベントの発表資料です。
https://techcon.mixi.co.jp/2024/d1-5.html

Transcript

1. ©MIXI MIXI Mと社内外のサービスを支える認 証基盤を作るためにやってきたこと 伊東 諒 開発本部 MIXI M 事業部 システムグループ オレンジチーム
2. ©MIXI 2 内容 • MIXI Mと認証基盤の役割 • 認証基盤の設計において意識していること • 標準化仕様の積極的な利用
3. ©MIXI 3 MIXI Mと認証基盤の役割
4. ©MIXI 4 MIXI Mとは • 認証から決済までをワンストップで提供できる基盤システム & WALLETサービス • アカウントを登録することで「アカウントの属性情報」「決済情報」などを MIXIの様々なサービス間で連携して利用可能
5. ©MIXI 5 認証基盤の役割 • アカウント情報の管理 ◦ アカウントの新規登録から解約までのライフサイクル管理 ◦ 安全で便利なログイン、セッション管理 ◦ 本人確認 • アクセス権限の管理 ◦ 社内外のサービスとの安全なデータ連携を実現
6. ©MIXI 6 認証基盤の設計において 意識していること
7. ©MIXI 7 実現したいこと • ユーザーが簡単に使える • 決済機能のような高いセキュリティ要件をもつユースケースにも対応 できる 様々なサービスから利用される認証基盤となるために、両者を実現する仕 組みを目指す
8. ©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
9. ©MIXI 9 意識していること • 利用するサービスの要件を基盤で汲み取る • ユーザー自身で確認、管理できる機能を適切に提供 • 様々な情報のライフサイクルを考慮 • 主要な機能についてのレベル分け
10. ©MIXI 10 利用するサービスの要件を基盤で汲み取る • 電話番号/メールアドレスを必須属性として要求 • 身分証を用いた本人確認(eKYC)の採用 利用するサービスの要件に応じて機能を拡張することで、より使いやすい 基盤システムを目指す
11. ©MIXI 11 ユーザー自身で確認、管理できる機能 • ログイン方法の管理 ◦ SMS/Email OTP、外部アカウントとのID連携、パスキー • セッション管理 ◦ OS、ブラウザ、最新の利用日時の表示 ◦ セッション単位のログアウト • セキュリティイベントログ ◦ ログイン、ログアウト、アカウント情報の設定、設定解除 現状、履歴を見えるようにしておくことで、有事の際の状況確認やアカウン トリカバリーに繋げる
12. ©MIXI 12 様々な情報のライフサイクルを考慮 • 電話番号、メールアドレス ◦ 変更、再割り当て ◦ SMSやメールが受信できない状況 • ソーシャルログイン、パスキー ◦ 利用できない状況、環境 普遍的なものではないことを意識し、意図せぬ変更があっても対応可能に しておく
13. ©MIXI 13 主要な機能についてのレベル分け • 認証基盤の主要な機能 ◦ 身元確認、本人確認 (Identity Proofing) ◦ ユーザー認証、当人認証 (Authentication) ◦ リソースアクセス あるアクションに対して必要なレベルを定義することで、様々なユースケー スに適用可能
14. ©MIXI 14 身元確認、本人確認 (Identity Proofing) • メールアドレス確認 ◦ 連絡先の確保 • SMSの確認 ◦ 連絡先の確保、botなどの大量アカウント登録対策 • 身分証を用いた本人確認 ◦ 成人であること、住所、氏名の確認 ◦ 犯罪収益移転防止法対応 身元確認のレベルは Identity Assurance Level (IAL) と呼ばれており、 特定機能の利用制限などに利用可能
15. ©MIXI 15 当人認証 (Authentication) • Email / SMS OTP 認証 ◦ 所持要素を利用する認証方式 • パスキー認証 ◦ 知識要素や生体要素のうちどれか一方と所持要素を組み合わせることで多 要素認証を実現 ユーザー認証のレベルは Authentication Assurance Level (AAL) と呼 ばれており、セッション管理や特定機能の利用制限などに利用可能
16. ©MIXI 16 リソースアクセス • 誰でも利用可能なトークン(Bearer Token) ◦ トークンのみでリソースアクセスが可能 ◦ 漏洩時に第３者による利用が容易 • 送信者制限のあるトークン(Sender-Constrained Token) ◦ リソースアクセス時には他の情報と組み合わせる必要がある ◦ 漏洩時に第３者による利用が困難 リソースアクセスの特性に合わせて、適切なトークンの種類を選択して利 用することで様々なセキュリティレベルに対応可能
17. ©MIXI 17 標準化仕様の積極的な利用
18. ©MIXI 18 標準化仕様を利用するメリット • ユースケースに対応したプロファイルの活用 ◦ 想定するユースケースに対して、仕様の導入方法がプロファイルとしてまとめ られているものがある • セキュリティ、プライバシーリスクの回避 ◦ 仕様策定の段階から脅威と対策が検討されており、別途ベストプラクティスが まとめられているものがある • 開発効率の向上 ◦ 各プログラミング言語のライブラリやプロダクトの利用 • 社外の開発者や利用サービスとの知見交換が可能
19. ©MIXI 19 利用している標準化仕様 • アカウントの新規登録、ログイン ◦ WebOTP : SMSで送られた認証コードの自動入力 ◦ Passkeys : より安全で便利な認証方式 ◦ OpenID Connect Core 1.0 : モバイル端末との親和性と安全性が高いソー シャルログイン • ID連携 / リソースアクセス機能の提供 ◦ OpenID Connect Core 1.0 ◦ OAuth 2.0 ▪ MTLS : 決済関連のAPIなど ▪ Token Introspection : 利用サービス間の連携も考慮
20. ©MIXI 20 まとめ • MIXI Mというサービスを提供しつつ、社内外のサービスに認証/決済 基盤を提供している • 幅広いサービスから利用される認証基盤となるための設計思想と考 慮している点を紹介した • 積極的に標準化仕様を利用している ぼくのかんがえたさいきょうの認証基盤を目指してこれからもやって いきます
21. ©MIXI