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
950
バクラクの認証基盤の成長と現在地 / bakuraku-authn-platform
convto
April 23, 2025
Tweet
Share
More Decks by convto
See All by convto
gob バイナリが Go バージョンによって 出力が変わることについて調べてみた / Investigating How gob Binary Output Changes Across Go Versions
convto
0
100
Go 関連の個人的おもしろCVE 5選 / my favorite go cve
convto
3
410
バイナリを眺めてわかる gob encoding の仕様と性質、適切な使い方 / understanding gob encoding
convto
6
2.6k
みんなでたのしむ math/big / i love math big
convto
0
260
Go1.22からの疑似乱数生成器について/go-122-pseudo-random-generator
convto
2
740
Go1.20からサポートされるtree構造のerrの紹介と、treeを考慮した複数マッチができるライブラリを作った話/introduction of tree structure err added since go 1_20
convto
0
1.1k
byte列のbit表現を得るencodingライブラリ作った
convto
1
1.2k
Go runtimeの歩き方/how to follow go runtime function
convto
1
980
入出金ドメインの苦労話と解決へのアプローチ/funds in/out difficulties and solutions
convto
2
1.4k
Other Decks in Technology
See All in Technology
データベース04: SQL (1/3) 単純質問 & 集約演算
trycycle
PRO
0
730
RubyKaigi NOC 近況 2025
sorah
3
980
さくらのクラウド開発の裏側
metakoma
PRO
14
4.8k
LangfuseではじめるAIアプリのLLMトレーシング
codenote
0
170
Amplifyとゼロからはじめた AIコーディング。失敗と気づき
mkdev10
1
110
UIパフォーマンス最適化: AIを活用して100倍の速度向上を実現した事例
kinocoboy2
0
270
DynamoDB のデータを QuickSight で可視化する際につまづいたこと/stumbling-blocks-when-visualising-dynamodb-with-quicksight
emiki
0
160
AI 코딩 에이전트 더 똑똑하게 쓰기
nacyot
0
550
LINE 購物幕後推手
line_developers_tw
PRO
0
560
"発信文化"をどうやって計測する?技術広報のKPI探索記/How do we measure communication culture?
bitkey
3
310
計測による継続的なCI/CDの改善
sansantech
PRO
3
830
激動の一年を通じて見えてきた「技術でリードする」ということ
ktr_0731
7
6.4k
Featured
See All Featured
Fireside Chat
paigeccino
37
3.4k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
The Pragmatic Product Professional
lauravandoore
33
6.6k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Music & Morning Musume
bryan
47
6.5k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Designing Experiences People Love
moore
142
24k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Code Review Best Practice
trishagee
68
18k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
5
610
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
ご清聴ありがとうございました!