freeeにおけるOAuth_OIDCの活用とAuthleteへの移行

　 freeeにおけるOAuth/OIDCの活⽤とAuthleteへの移⾏ 2024.12.11

　 2 ⾦融系SIer、SESを経て2021年にフリー株式会社（以降、freee）に⼊社。以降、IAM基盤開発部にてID連携開発に従事。期せずして Authlete⼈材としてfreeeが3社⽬。 freeeではエンジニアと兼務でDeveloper Relationship
を担当し、freee Tech Nightやfreee技術の⽇テックカンファレンスの運営などを⾏っていた。趣味はホラー映画と猫と兎⽥ぺこら。寺原歩（てらら） IAM基盤開発部エンジニア terahara ayumu

　 3 本⽇弊社から参加している愉快なメンバーたち 2024/10/30 OAuth & OpenID Connect 勉強会ー
認可サーバーの作りかた（AWS編）のYouTubeコメント欄より https://authlete.connpass.com/event/333513/

4 01 freeeを取り巻くOAuth/OIDC 02 Authlete採⽤の経緯 03 Authele環境への移⾏⽅式 04 認可サーバ移⾏ナレッジ 05 ご要望と改善点 06 今後の展望⽬次

6 　 freeeは「スモールビジネスを、世界の主役に。」をミッションに掲げ、統合型経営プラットフォームを開発‧提供し、だれもが⾃由に⾃然体で経営できる環境をつくっていきます。起業やビジネスを育てていくことを、もっと魅⼒的で気軽な⾏為に。個⼈事業や中⼩企業などのスモールビジネスに携わるすべての⼈が、じぶんらしく⾃信をもって経営できるように。⼤胆にスピード感をもってアイデアを具現化できるスモールビジネスは、今までにない多様な価値観や⽣き⽅、
新しいイノベーションを⽣み出す起爆剤だと私たちは考えています。スモールビジネスが⼤企業を刺激し、社会をさらにオモシロク、世の中全体をより良くする流れを後押ししていきます。 Mission スモールビジネスを、世界の主役に。

7 　電⼦稟議経費精算債権債務管理⼈事労務電⼦契約固定資産請求管理
会計⼯数管理販売管理会計‧⼈事労務‧販売管理を核とした統合型経営プラットフォーム

　 8 パブリックAPIによる拡張性/ freeeアプリストアアプリストア掲載数(1) 注1:2024年8⽉末時点 179件 freee機能拡張経営分析‧可視化購買‧⽀払
請求書‧証憑決済サービス⼈事マスタ‧勤怠業務システム POS‧EC リピート取引/外貨決算サポート/借⼊⾦

　 9 〜 freeeだけではできないことをアプリを使えば簡単に〜 • 様々な3rd partyアプリを簡易的に開発いただき、公開することができる •
ユーザーの選択肢の幅が広がるエコシステムの構築

　 10 〜いつでも‧どこでも利⽤できる機能の提供〜 • freee⼈事労務モバイル ◦ 位置情報による⾃動打刻、ウィジェットからの打刻などより利便性に特化した機能提供
• freee経費精算モバイル ◦ 証憑を撮影して申請する「魔法スキャン」機能や「複数枚同時撮影」機能の提供 ◦ 交通系ICカード読み取りなど多彩な申請機能の提供 • freee電⼦申告モバイル ◦ マイナンバーカード読み取りを使った電⼦申告の簡略化 • などなど freee モバイルアプリ

　 11 • OpenID Provider としてグループジョインプロダクトのスムーズなアカウント統合 • ユーザー体験の⼀貫性確保
グループプロダクトへのfreeeアカウントログイン

　 13 急成⻑するfreeeプラットフォームにおける認可基盤の課題事業成⻑による要件の拡⼤ 1. アプリストア - 100以上の連携アプリ - ⾮公開アプリも存在
- 各アプリごとの認可管理 - APIアクセス制御の複雑化 2. freeeモバイルアプリ群 - ⼈事労務 / 経費精算 / 電⼦申告 / etc - アプリ固有の認証要件 3. グループプロダクト統合 - OpenID Providerとしての役割 - 統合的アカウント体験 - 権限管理の複雑化現⾏の認可基盤の限界 1. 技術的課題 - RFC準拠の不完全性 - 新規格対応の困難さ - セキュリティ更新の負担 2. 運⽤⾯の課題 - 増⼤する保守コスト - 複雑化する監視要件 - 属⼈化するナレッジ 3. スケーラビリティの課題 - トラフィック増加への対応 - 新規サービス追加時の負担 - パフォーマンスボトルネック

　 14 急成⻑するfreeeプラットフォームにおける認可基盤の課題解決が必要な重要課題 ✓ エコシステムの持続的な成⻑ ✓ セキュリティ品質の確保 ✓ 運⽤効率の最適化
✓ 開発リソースの適切な配分

　 15 認可基盤の刷新

　 16 基盤移⾏の要件現⾏基盤の状態 • 現⾏はフルスクラッチによる実装 • 旧認証認可基盤から認証基盤のみを切り離した実績があり、現⾏基盤は認可機能のみ残存移⾏先必須要件 •
既存の認証基盤との親和性 • freee独⾃の事業所アカウントとの親和性移⾏コストの⽐較要件 • インフラにかかる初期コストおよびランニングコスト（Authlete利⽤費含む） • ミドルウェアアップデートにかかる運⽤コスト • セキュリティアップデート拡張仕様への対応コスト（PKCE、FAPI2.0など） • その他拡張仕様への対応コスト（CIBAなど）

　 17 移⾏先の選定既存の認証機能との親和性事業所アカウントとの親和性運⽤コスト費⽤(⽉額) フルスクラッチ Authlete IDaaS
A 拡張仕様開発コストその他必須要件未達のため対象外エンハンスに強い設計からサポート有ベンダーロックイン無 ID⼈材不⾜

　 18 事業成⻑に耐えうる基盤構築が可能 • 事業成⻑による要件の拡⼤に耐えうる基盤を作るためにはOAuthの拡張機能の開発がネックであるが、Authleteを採⽤することにより開発が⾮常に軽くなることが⾒込まれる。 • Authleteを採⽤することで認可基盤の設計/開発サポートも受けられるので、今後の開発においてそれら実装周りで困ることはなく、今後のセキュリティアップデートも素早く追従できる。 •
競合他社では5年以上の運⽤実績があり、他社SaaSも導⼊していることから信頼性も⾼い。競合他社とのセキュリティ、拡張仕様⾯でのビジネス機会を失うことがない。コスト要件を満たす • インフラ⽉額費⽤に関しては対フルスクラッチ⾃社サーバー費⽤ではAuthlete費⽤の⽅が⾼い。 • ⼀⽅、その差額はフルスクラッチのためにOAuthに熟達したエンジニアを⼀⼈雇うよりは安いと考えている。それら運⽤コスト / 体制維持へのコストまで含めるとフルスクラッチよりもAuthleteを採⽤した⽅が安価。 Authlete採⽤理由

　 19 freee 新認可基盤 x Authlete

21 レイヤ 2012 - 2013 現在バックエンド Ruby Rails Ruby
Go Rails Webフロントエンド CoﬀeeScript Backbone.js Sprockets TypeScript JavaScript (Flow) React Vite / webpack モバイルアプリ - - Swift / Kotlin SwiftUI / Jetpack Compose インフラ‧構成管理 Heroku -> AWS Chef AWS Kubernetes Terraform ML‧データ分析 - - Python TensorFlow BigQuery freeeの技術スタック全領域で技術⼊れ替えがほぼ⼀巡。

　 22 旧環境のシーケンス（例：Public APIリクエスト） freee プロダクト旧認可基盤 DB 認証認可ライブラリ AccessToken
Client Cache 認可判定問い合わせ Cache機構（以降割愛） Resource

　 23 新環境へ移⾏するシーケンス（例：Public APIリクエスト）問い合わせ新認可基盤 Authlete freee プロダクト旧認可基盤
DB 認証認可ライブラリ認可判定問い合わせ Resource AccessToken Client

　 24 • 認証認可ライブラリをストラングラーファサードとする • 移⾏戦略として、⼆重書き込みにてデータを揃え、⼆重読み込みにてデータ差分‧機能差分を検知する • プロダクト側は意識せず、新基盤に移⾏可能ストラングラーフィグパターン Authlete
freee   プロダクト   新基盤  旧基盤  DB  3. Read   認証認可ライブラリ   （Facade）   1. Read   2. Read   6. データの差分を確認   5. Read   4. Read   Authlete freee   プロダクト   新基盤  旧基盤  DB  3. Read   認証認可ライブラリ   （Facade）   1. Write   2. Write   6. データの差分を確認   5. Write   ⼆重読み込み⼆重書き込み 4. Write  

　 25 • Phase1: アプリケーション情報の移⾏ ◦ freeeアプリストアから作成されるデータを中⼼にまずはOAuth Clientの移⾏を⾏う ◦ アクセストークンとは異なりfreee独⾃ドメインを持つ機能が多く、再モデリングが必要
◦ レガシーコードも⼤量にあるため技術的負債の返済が主軸 • Phase2: アクセストークン情報の移⾏ ◦ 独⾃ドメインを持つ機能はないため、機能⾯は単純な移⾏が可能 ◦ アクセス量、データ量が多く、パフォーマンスチューニングが必要 ◦ Invalidなアクセストークンリクエストが⼤量にあるため、Client開発者との折衝が主軸各Phaseごとに、さらにストラングラーフィグを満たすための各タスクを順次実⾏していく • Secondary Write: ⼆重書き込みにより新基盤へデータを順次流し込む • Secondary Read: ⼆重読み込みにより新基盤のデータ‧I/Fが現新⼀致することを保証する • Primary Read: 読み込み機能の主系‧副系を⼊れ替えて新基盤のみで動作可能であることを保証する • Primary Write: 書き込み機能の主系‧副系を⼊れ替えて新基盤のみで動作可能であることを保証する移⾏フェーズの切り⽅

　 26 移⾏フェーズの切り⽅まとめ Secondary Write Secondary Read Primary Write Primary
Read Ph2 Ph1 ① OAuth Client情報の順次移⾏ ② OAuth Client情報の差分修正 ③ OAuth Client機能の主副切り替え ④ OAuth Client機能の主副切り替え ⑤ AccessToken情報の順次移⾏ ⑥ AccessToken情報の差分修正 ⑦ AccessToken機能の主副切り替え ⑧ AccessToken機能の主副切り替え技術的負債の返済フェーズ補⾜パフォーマンスチューニングフェーズ

　 27 freeeの仕様をブラッシュアップ • Authleteの特性として、RFC準拠の質と速さの両⽅を備えている • ストラングラーフィグにて機能差分が出た時に⼀般的には主系に合わせた改修を⾏う必要があるが、副系である Authleteを使った新基盤の⽅が機能⾯で優秀なケースが多かった • 副系に合わせてfreeeの仕様を更新することで今まで⾒えていなかったリスクを回避
• 実際の改善例: Relying Partyがトークンリフレッシュ時にid_tokenを再発⾏していたが、全てのRelying Partyはこれを利⽤していなかったので削除したメンバーのスキルアップ • Authlete API I/F と各種RFC を開発チームで読み合わせしながら進めることが習慣付き、設計品質も向上した • 川崎さんの解説記事をチーム内共有する時は :taka_god: というemojiリアクションが付くようにストラングラーフィグとAuthleteの相性の良さ

　 29 移⾏に利⽤したオプション • ClientID Alias ◦ 旧基盤のClientIDをそのまま利⽤可能 • Client
Attributes ◦ freeeのClientに関するドメイン情報の判定に使う値を設定することで機能の現新⼀致が可能 • /auth/token/create API ◦ 旧基盤で発⾏した AccessToken をそのまま利⽤可能 • AccessToken properties ◦ freee独⾃の事業所アカウントなどのドメイン情報を設定することで機能の現新⼀致が可能移⾏後に使いたいオプション • 冪等性リフレッシュトークン Authleteのオプション⼀覧

　 30 AccessTokenキャッシュの実装⽅法前提 • AuthleteではAccessTokenをハッシュ化して保持している（例: List Issued Tokens ）
• freeeではAccessToken/RefreshTokenを指定するRevocation以外に、Resource OwnerやOAuth Clientを指定して⼀括でRevocationを⾏う機能があるキャッシュ要件 • Token IntrospectionによるAuthleteへのリクエスト負荷を下げる • ⼀括でToken Revocationされた場合にAccessTokenキャッシュを無効化できるキャッシュ種別 • Active AccessToken キャッシュ: Token Introspectionで有効なキャッシュ情報を持つ • Inactive AccessToken キャッシュ: Token Introspectionで無効なキャッシュ情報を持つ • Revoked Time キャッシュ: ⼀括でRevocationを⾏った際のResource OwnerとOAuth Clientをkeyに持ち、 Revoked Time と Active AccessToken キャッシュの作成⽇時を⽐較し、有効 / 無効を判定する

　 31 AccessTokenキャッシュの実例（Token Introspection） Active Cache リクエスト Revoked Time Cache
Authlete Access レスポンス Cache Miss = Inactive = Active => Revoked Time < Revoked Time Active or Inactive Cache作成

　 32 ⾃社特有のドメインをパターン化することで設計の⾒通しが格段に向上さらに Authlete では Client Attributes にてパターンに使う識別⼦を管理することが可能という「OAuth/OIDCのClient管理を"型"で制する
- freee_client_typeの軌跡」という記事を書いたのでぜひB!ブックマークお願いします。⾃社特有のドメインの実装⽅法について

　 34 • OAuth Clientを⼀括操作するAPIがないため、アプリストアを提供するための機能に物⾜りなさ • Client Attributesを指定した検索機能など、List系の機能があると嬉しい OAuth Client管理機能の拡充

　 35 • 新基盤はgolangを使っているため、 authlete-go を利⽤していたところ新規commitが…！ We strongly recommend the
use of https://github.com/authlete/openapi-for-go instead of authlete-go 😇 • authlete-go から openapi-for-go へ移⾏する場合に型定義が破壊的変更になるため、移⾏が容易ではない • openapi-for-go の⽣成コードをそのまま利⽤するよりもOpenAPI定義ファイルからcodegenする⽅が⽣成コードの⾃由度が⾼い • authlete-goを弊社と共にcontributeしていきませんか…？ authlete-go のメンテナンス終了が悲しい

　 36 • Authlete 3.0リリースおめでとうございます！お待ちしておりました！管理コンソールのアクセス制御機能の強化

　 38 • 業務が、最も効率的に • 組織が、ストレスフリーに • 経営が、⾃由に経営を阻む３つの分断を解決する統合ﬂow
スモールビジネスに最⾼の体験を最速で提供するために。進化可能なアーキテクチャを。〜統合型経営プラットフォームの追及〜プロダクトのビジョン

　 39 toB SaaS 認可のベストプラクティスへ • Resource Ownerが複雑化するtoB SaaSで正しいResource Ownerへ認可を取ることは難易度が⾼い
◦ 事業所情報のOwnerは誰なのか。 • 認可機能に特化しているAuthleteと共にtoB SaaS認可のプラクティスを追及していく

スモールビジネスを、世界の主役に。

freeeにおけるOAuth_OIDCの活用とAuthleteへの移行

freeeにおけるOAuth_OIDCの活用とAuthleteへの移行

More Decks by てらら

Other Decks in Technology

Featured

Transcript