バクラクの認証基盤の成長と現在地 / bakuraku-authn-platform

Transcript

1. バクラクの認証基盤の成長と現在地 2025/04/23 LayerX／kubellの実例から学ぶ プロダクトが大きくなっても壊れない 認証設計とは @convto
2. はじめに
3. 自己紹介 © LayerX Inc. convto (よみは「こんぶと」です) LayerX (2023-03 -) バクラク事業部 Platform Engineering 部 ID チーム 2023-03 ~ 2023-09 まで申請/経費精算などのプロダクト担当 2023-09 くらいからID基盤の開発に関わっています 3
4. 今日話すこと © LayerX Inc. プロダクトの成長に合わせて基盤への要求も増えるが、実際にどんな要求がくるかはサ ービス性質によって異なる サービスの成長に伴って増えた認証基盤への要求、の一例をこの場で紹介します！ 基盤チームとして、どのように整合性を保ちつつ機能拡張していったか説明 4
5. バクラクシステムへの要求の拡大
6. 前提: 初期のバクラク認証基盤について © LayerX Inc. バクラクでは初期から認証基盤が切り出されていた 上記よりもともとマルチプロダクト展開がしやすい構成 認証手段などについてはカバーしきれていない部分も多く、追加の対応が必要だった 6
7. プロダクト成長に伴う要求 最初はシンプルなパスワード認証のみをサポートしていました © LayerX Inc. 7
8. プロダクト成長に伴う要求 企業向けサービスとしての成長に伴い、SAML認証やGoogle認証の要求が増えていきました © LayerX Inc. 8
9. プロダクト成長に伴う要求 いまではもっとさまざまな要求が増えました！！ © LayerX Inc. 9
10. めっちゃいろいろ増えた © LayerX Inc. いろいろ増えるたびにどう実現するか頭を悩ませました プロダクトの成長の一つのケースとして、弊チームの対応事例を紹介していきます！ 10
11. ケース1: API platformのための OAuth2.0認可コードフロー
12. API platformのためのOAuth2.0認可コードフロー 背景と課題 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー バクラクのサービスに対するAPIアクセスを提供したいモチベーションがあった 将来的に外部サービスとの連携ニーズがあることも見越して、標準仕様に乗ることに！ 標準仕様を自前で実装するのはコストやリスクがある 12
13. OAuth2.0 の実現手段を選定 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー Ory Hydra を採用 対抗馬として Auth0 や他ソフトウェアもあったが、以下理由から判断 社内メンバーの運用経験 ID管理のオーナーシップを移さず、既存の認証部分を利用しながら OAuth2.0 を用いた認可処理が実現ができる 13
14. Ory Hydra を使った OAuth2.0 認可コードフローの実現 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー 詳細なシーケンスはここでは扱いませんが、プロダクトとしては OAuth2.0 認可コード フローで発生する認証/認可処理を実装するのみでOKです OAuth2.0 の基本的なやり取りなどは全て Ory Hydra がサポートしています 14
15. Ory Hydra を使った OAuth2.0 認可コードフローの実現 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー 認証処理は既存のものを使いつつ、上から被せて OAuth2.0 認可部分を Ory Hydra で実 現 これによりID管理の主体を変更するなど大掛かりな対応をせず、最小限の変更で標準仕 様の対応を実現した 15
16. おまけ 全体的な構成も面白いのでぜひこちらもみてください！ https://tech.layerx.co.jp/entry/2025/04/18/131034 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー 16
17. ケース2: 非バクラクユーザーからの テンポラリな認証/認可要求
18. 非バクラクユーザーからのテンポラリな認証/認可要求 背景と課題 © LayerX Inc. 非バクラクユーザーからのテンポラリな認証/認可要求 非バクラクユーザーの取引先などにリソース共有したいニーズがあった バクラクユーザーではないので、今までとは別の認証手段を考える必要があった 取得可能なリソースを制限することも必要だった 18
19. テンポラリな認証要求の実現 © LayerX Inc. 非バクラクユーザーからのテンポラリな認証/認可要求 可能な操作を限定したセッションの発行に対応 onetime pass から上記セッションを発行できるように 19
20. テンポラリな認証要求の実現 簡略化したシーケンスのイメージは以下 © LayerX Inc. 非バクラクユーザーからのテンポラリな認証/認可要求 20
21. ケース3: ICカード打刻むけの用途限定セッ ション
22. ICカード打刻のためのしくみ 背景と課題 © LayerX Inc. ICカード打刻むけの用途限定セッション PCにICカードリーダーを接続し、Suicaなどをかざして打刻機として利用したかった オフィスに置かれてさまざまなメンバーが操作可能なので、通常通りバクラクは操作さ せたくない ICカードリーダーを読み取るしかできない、用途を限定したセッションが必要 22
23. ICカード打刻むけ用途限定セッションの実現 © LayerX Inc. ICカード打刻むけの用途限定セッション すでにバクラクには「テンポラリな認証/認可要求」のときに作った、用途限定セッシ ョンの仕組みがあった 今回のセッションもこの一種とみなし、ユースケースにあったセッション発行方法をサ ポートすれば要求は満たせて、かつ今後のメンテナンスも容易になる 今回は用途限定セッションでは新しい発行手段を追加し、それを利用することとした 23
24. ICカード打刻むけ用途限定セッションの実現 © LayerX Inc. ICカード打刻むけの用途限定セッション 24
25. ケース4: メールアドレス以外の識別子を使 ったログイン
26. メールアドレス以外での認証 背景と課題 © LayerX Inc. メールアドレス以外の識別子を使ったログイン 業態や雇用形態によってメールアドレスを所持しない従業員がいるケースがある より広く価値提供するため、メールアドレスによらない識別子が必要 26
27. メールアドレス以外の識別子による認証の実現 © LayerX Inc. メールアドレス以外の識別子を使ったログイン ログインIDという新しい識別子を設計 ログインIDによる従業員登録、ログインをサポート 連絡先が存在せず、たとえばパスワード設定などのフローでメールを使ったケースのよ うな本人確認ができない。カバーが必要 27
28. ログインIDの形式を決定 © LayerX Inc. メールアドレス以外の識別子を使ったログイン ユーザーが記憶/入力しやすい パスワードマネージャなどとの相性のため、入力項目を一つにする 他社との採番体系の競合を避けるため、事業者を識別する要素も含める 28
29. ログインIDの設計 © LayerX Inc. メールアドレス以外の識別子を使ったログイン 29
30. メールを送って所有を確認するようなフローの見直し © LayerX Inc. メールアドレス以外の識別子を使ったログイン 30
31. おまけ こちらも背景まとまった記事あるのでよろしければご覧ください！ https://tech.layerx.co.jp/entry/2025/02/14/163140 © LayerX Inc. メールアドレス以外の識別子を使ったログイン 31
32. まとめ
33. バクラク認証基盤の進化 初期構成から現在までで、さまざまな変化が起きています © LayerX Inc. さまざまな認証方式のサポート OAuth2.0 などの標準仕様のサポート 用途を限定したセッションの仕組みをサポート 複数種別の識別子をサポート 33
34. プロダクトの発展を支えるには © LayerX Inc. プロダクトの発展とともにさまざまな要求が出る それらをサポートするためには、認証基盤の成長が必要 場当たり的な対応ではなく、要望に応えつつメンテナンスしやすい形で実現していく Ory Hydra を使った、既存認証基盤に影響を与えない標準仕様のサポート 「用途限定セッション」という機能群を抽象的にとらえ、個別開発を避ける これらの意思決定のために、チームとしてプロダクトの現状を正確に把握し、長期を見 据えて周辺技術のキャッチアップに努める 34
35. ご清聴ありがとうございました！