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
バクラクの認証基盤の成長と現在地 / bakuraku-authn-platform
Search
convto
April 23, 2025
Technology
4
1.3k
バクラクの認証基盤の成長と現在地 / bakuraku-authn-platform
convto
April 23, 2025
Tweet
Share
More Decks by convto
See All by convto
MCPと認可まわりの話 / mcp_and_authorization
convto
2
600
gob バイナリが Go バージョンによって 出力が変わることについて調べてみた / Investigating How gob Binary Output Changes Across Go Versions
convto
0
130
Go 関連の個人的おもしろCVE 5選 / my favorite go cve
convto
3
470
バイナリを眺めてわかる gob encoding の仕様と性質、適切な使い方 / understanding gob encoding
convto
6
2.9k
みんなでたのしむ math/big / i love math big
convto
0
280
Go1.22からの疑似乱数生成器について/go-122-pseudo-random-generator
convto
2
820
Go1.20からサポートされるtree構造のerrの紹介と、treeを考慮した複数マッチができるライブラリを作った話/introduction of tree structure err added since go 1_20
convto
0
1.2k
byte列のbit表現を得るencodingライブラリ作った
convto
1
1.2k
Go runtimeの歩き方/how to follow go runtime function
convto
1
1k
Other Decks in Technology
See All in Technology
帳票Vibe Coding
terurou
0
110
LLM時代の検索とコンテキストエンジニアリング
shibuiwilliam
2
1k
AIと描く、未来のBacklog 〜プロジェクト管理の次の10年を想像し、創造するセッション〜
hrm_o25
0
120
AIは変更差分からユニットテスト_結合テスト_システムテストでテストすべきことが出せるのか?
mineo_matsuya
5
3k
メルカリIBIS:AIが拓く次世代インシデント対応
0gm
2
490
コミュニティと計画的偶発性理論 - 出会いが人生を変える / Life-Changing Encounters
soudai
PRO
7
1.2k
いかにして命令の入れ替わりについて心配するのをやめ、メモリモデルを愛するようになったか(改)
nullpo_head
7
2.8k
Android Studio の 新しいAI機能を試してみよう / Try out the new AI features in Android Studio
yanzm
0
170
Preferred Networks (PFN) とLLM Post-Training チームの紹介 / 第4回 関東Kaggler会 スポンサーセッション
pfn
PRO
1
110
結局QUICで通信は速くなるの?
kota_yata
9
7.5k
ECS モニタリング手法大整理
yendoooo
1
110
MCPサーバーを活用したAWSコスト管理
arie0703
0
140
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The World Runs on Bad Software
bkeepers
PRO
70
11k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Scaling GitHub
holman
462
140k
Being A Developer After 40
akosma
90
590k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
How GitHub (no longer) Works
holman
314
140k
Site-Speed That Sticks
csswizardry
10
780
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Transcript
バクラクの認証基盤の成長と現在地 2025/04/23 LayerX/kubellの実例から学ぶ プロダクトが大きくなっても壊れない 認証設計とは @convto
はじめに
自己紹介 © LayerX Inc. convto (よみは「こんぶと」です) LayerX (2023-03 -) バクラク事業部
Platform Engineering 部 ID チーム 2023-03 ~ 2023-09 まで申請/経費精算などのプロダクト担当 2023-09 くらいからID基盤の開発に関わっています 3
今日話すこと © LayerX Inc. プロダクトの成長に合わせて基盤への要求も増えるが、実際にどんな要求がくるかはサ ービス性質によって異なる サービスの成長に伴って増えた認証基盤への要求、の一例をこの場で紹介します! 基盤チームとして、どのように整合性を保ちつつ機能拡張していったか説明 4
バクラクシステムへの要求の拡大
前提: 初期のバクラク認証基盤について © LayerX Inc. バクラクでは初期から認証基盤が切り出されていた 上記よりもともとマルチプロダクト展開がしやすい構成 認証手段などについてはカバーしきれていない部分も多く、追加の対応が必要だった 6
プロダクト成長に伴う要求 最初はシンプルなパスワード認証のみをサポートしていました © LayerX Inc. 7
プロダクト成長に伴う要求 企業向けサービスとしての成長に伴い、SAML認証やGoogle認証の要求が増えていきました © LayerX Inc. 8
プロダクト成長に伴う要求 いまではもっとさまざまな要求が増えました!! © LayerX Inc. 9
めっちゃいろいろ増えた © LayerX Inc. いろいろ増えるたびにどう実現するか頭を悩ませました プロダクトの成長の一つのケースとして、弊チームの対応事例を紹介していきます! 10
ケース1: API platformのための OAuth2.0認可コードフロー
API platformのためのOAuth2.0認可コードフロー 背景と課題 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー バクラクのサービスに対するAPIアクセスを提供したいモチベーションがあった 将来的に外部サービスとの連携ニーズがあることも見越して、標準仕様に乗ることに!
標準仕様を自前で実装するのはコストやリスクがある 12
OAuth2.0 の実現手段を選定 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー Ory Hydra を採用
対抗馬として Auth0 や他ソフトウェアもあったが、以下理由から判断 社内メンバーの運用経験 ID管理のオーナーシップを移さず、既存の認証部分を利用しながら OAuth2.0 を用いた認可処理が実現ができる 13
Ory Hydra を使った OAuth2.0 認可コードフローの実現 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー
詳細なシーケンスはここでは扱いませんが、プロダクトとしては OAuth2.0 認可コード フローで発生する認証/認可処理を実装するのみでOKです OAuth2.0 の基本的なやり取りなどは全て Ory Hydra がサポートしています 14
Ory Hydra を使った OAuth2.0 認可コードフローの実現 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー
認証処理は既存のものを使いつつ、上から被せて OAuth2.0 認可部分を Ory Hydra で実 現 これによりID管理の主体を変更するなど大掛かりな対応をせず、最小限の変更で標準仕 様の対応を実現した 15
おまけ 全体的な構成も面白いのでぜひこちらもみてください! https://tech.layerx.co.jp/entry/2025/04/18/131034 © LayerX Inc. API platformのためのOAuth2.0認可コードフロー 16
ケース2: 非バクラクユーザーからの テンポラリな認証/認可要求
非バクラクユーザーからのテンポラリな認証/認可要求 背景と課題 © LayerX Inc. 非バクラクユーザーからのテンポラリな認証/認可要求 非バクラクユーザーの取引先などにリソース共有したいニーズがあった バクラクユーザーではないので、今までとは別の認証手段を考える必要があった 取得可能なリソースを制限することも必要だった 18
テンポラリな認証要求の実現 © LayerX Inc. 非バクラクユーザーからのテンポラリな認証/認可要求 可能な操作を限定したセッションの発行に対応 onetime pass から上記セッションを発行できるように 19
テンポラリな認証要求の実現 簡略化したシーケンスのイメージは以下 © LayerX Inc. 非バクラクユーザーからのテンポラリな認証/認可要求 20
ケース3: ICカード打刻むけの用途限定セッ ション
ICカード打刻のためのしくみ 背景と課題 © LayerX Inc. ICカード打刻むけの用途限定セッション PCにICカードリーダーを接続し、Suicaなどをかざして打刻機として利用したかった オフィスに置かれてさまざまなメンバーが操作可能なので、通常通りバクラクは操作さ せたくない ICカードリーダーを読み取るしかできない、用途を限定したセッションが必要
22
ICカード打刻むけ用途限定セッションの実現 © LayerX Inc. ICカード打刻むけの用途限定セッション すでにバクラクには「テンポラリな認証/認可要求」のときに作った、用途限定セッシ ョンの仕組みがあった 今回のセッションもこの一種とみなし、ユースケースにあったセッション発行方法をサ ポートすれば要求は満たせて、かつ今後のメンテナンスも容易になる 今回は用途限定セッションでは新しい発行手段を追加し、それを利用することとした
23
ICカード打刻むけ用途限定セッションの実現 © LayerX Inc. ICカード打刻むけの用途限定セッション 24
ケース4: メールアドレス以外の識別子を使 ったログイン
メールアドレス以外での認証 背景と課題 © LayerX Inc. メールアドレス以外の識別子を使ったログイン 業態や雇用形態によってメールアドレスを所持しない従業員がいるケースがある より広く価値提供するため、メールアドレスによらない識別子が必要 26
メールアドレス以外の識別子による認証の実現 © LayerX Inc. メールアドレス以外の識別子を使ったログイン ログインIDという新しい識別子を設計 ログインIDによる従業員登録、ログインをサポート 連絡先が存在せず、たとえばパスワード設定などのフローでメールを使ったケースのよ うな本人確認ができない。カバーが必要 27
ログインIDの形式を決定 © LayerX Inc. メールアドレス以外の識別子を使ったログイン ユーザーが記憶/入力しやすい パスワードマネージャなどとの相性のため、入力項目を一つにする 他社との採番体系の競合を避けるため、事業者を識別する要素も含める 28
ログインIDの設計 © LayerX Inc. メールアドレス以外の識別子を使ったログイン 29
メールを送って所有を確認するようなフローの見直し © LayerX Inc. メールアドレス以外の識別子を使ったログイン 30
おまけ こちらも背景まとまった記事あるのでよろしければご覧ください! https://tech.layerx.co.jp/entry/2025/02/14/163140 © LayerX Inc. メールアドレス以外の識別子を使ったログイン 31
まとめ
バクラク認証基盤の進化 初期構成から現在までで、さまざまな変化が起きています © LayerX Inc. さまざまな認証方式のサポート OAuth2.0 などの標準仕様のサポート 用途を限定したセッションの仕組みをサポート 複数種別の識別子をサポート
33
プロダクトの発展を支えるには © LayerX Inc. プロダクトの発展とともにさまざまな要求が出る それらをサポートするためには、認証基盤の成長が必要 場当たり的な対応ではなく、要望に応えつつメンテナンスしやすい形で実現していく Ory Hydra を使った、既存認証基盤に影響を与えない標準仕様のサポート
「用途限定セッション」という機能群を抽象的にとらえ、個別開発を避ける これらの意思決定のために、チームとしてプロダクトの現状を正確に把握し、長期を見 据えて周辺技術のキャッチアップに努める 34
ご清聴ありがとうございました!