ID:82906さん

※リリース済みなので公開情報になります。 dipIDは、ディップ株式会社が提供する全サービス（バイトル、バイトルPRO、バイトルNEXT、やさしい履歴書等）で利用可能な共通認証基盤です。各サービスが個別にログイン機能を持つ状態から脱却し、Google/Apple/LINE/Yahoo! JAPANのソーシャルログインに加え、メールアドレス・パスワード・ワンタイムパスワードによる認証を一元的に提供します。全社のログインはdipIDに任せ、各サービスはdipIDから受け取ったIDトークンで認可だけやればいいという設計思想です。 dipIDはWebとネイティブアプリの双方から利用でき、OAuth 2.0 / OIDCのAuthorization Code Flowに基づいた認証フローを提供します。利用サービスはiframeまたはWebViewでdipIDのログイン画面を埋め込み、ワンタイムコード→カスタムトークン→IDトークンという流れでユーザー認証を完了します。 自分の役割 dipIDの設計・開発・運用・展開のほぼ全てを担当しました。プロダクトオーナーという言い方が最も近いと思います。 具体的には、認証フローのアーキテクチャ設計、フロントエンド・バックエンドの実装、Firebase/Google Cloud Identity Platformの設定・運用、Terraform IaCによるインフラ構築、Sendgridを使ったメール送信基盤の整備、全社6サービスとの結合テスト・不具合対応、本番リリース作業、負荷試験の設計と実施、障害フロー訓練、そして全社の開発者が参照するAPI仕様書・シーケンス図・用語集の作成まで、一人で（途中から外部エンジニア1名と2人で）回しました。 さらに、開発リソースが足りない中で外部エンジニアの調達を自ら行い、CTOへの推薦、予算調整、NDA手続きまで完了させて2人体制を構築しています。技術だけでなく、プロジェクトを前に進めるために必要なことは何でもやりました。 技術選定とパートナー選び Firebase vs AWS Cognito dipIDは複数のサービスで共通認証を扱う必要があり、認証基盤の選定はプロジェクトの根幹に関わる判断でした。候補はAWS CognitoとFirebase Authentication。Cognitoは柔軟性が高い反面、User PoolとIdentity Poolの二重構造で構成が複雑になり、設計やTerraform管理が重く、設定変更時の影響範囲の確認に慎重さが求められる点で運用負荷が高いと判断しました。一方、Firebase AuthenticationはOIDCベースの単純なトークン構造で運用が軽く、トークン更新やセッション維持がSDK側で完結するため開発者が認証の詳細を意識せずに済みます。Flutter/React等の複数フロントエンド技術でSDKが統一されており、利用サービス側の導入コストも低い。開発スピードと保守性の両立を重視してFirebaseを選択しました。 Google Cloud TAP（Tech Acceleration Program）の活用 開発初期にGoogleのTAP（Tech Acceleration Program）を活用しました。Googleオフィスでのアジャイル型ワークショップを通じて、アーキテクチャの再設計からコーディングまでを集中的に進めています。 ただし、TAPはあくまで補助的な利用で、おんぶに抱っこでGoogleに開発してもらったわけではありません。目的は2つありました。1つは、Identity Platform周りのセキュリティやID管理の知見をGoogleのエンジニアから直接得ること。もう1つは、外部パートナーとしてGoogleを巻き込むことで、社内でのdipIDプロジェクトの説得力と推進力を強化すること。実際、社内で他のベンダーも検討しましたが、スピードと実行を約束してくれたGoogleと進めることを即決しています。 技術的に困難だった課題 iframeの制約との戦い dipIDは各サービスのページにiframeで埋め込まれる設計です。しかし、SafariのITP（Intelligent Tracking Prevention）がThird-Party Cookieを完全にブロックするため、iframe内でのCookieベースのセッション管理が使えません。当初検討していたiframe＋postMessage方式は、SafariのITPによるthird partyのストレージ制限を回避できず廃止しました。 最終的に、URLフラグメントにワンタイムコードを付与してコールバックする方式を採用し、First Party Cookieとしてbaitoru.comドメインに短時間（1分間）のみカスタムトークンを設定する二段構えの設計にしました。ネイティブアプリではASWebAuthenticationSession / Chrome Custom Tabsを経由したカスタムURLスキームによるディープリンク方式を採用しています。iframe内の表示速度も課題で、ビルドサイズの削減とフロントエンドのリファクタリングを並行して進めました。 FirebaseのIDトークンの限界とサービス間認証の設計 社内のAPI基盤チームから「どのクライアントからのリクエストか判断したい」という相談を受けた際、根本的な問題に気づきました。FirebaseのIDトークンはログインしたユーザー個人の認証しかできず、「どのサービスからのリクエストか」というサービス自身の認証が欠落していたのです。HTTPヘッダにクライアントIDを直接付与する方法ではなりすましが容易で、IDトークンにclient_idをカスタムクレームとして埋め込む方法も、トークン盗用時に同様のリスクが残ります。 この課題に対して、秘密鍵・公開鍵ペアによるclient_assertion（JWT署名）方式を設計しました。各サービスが自身の秘密鍵で署名したJWTをX-Client-Assertionヘッダに付与し、認証基盤側がJWKSエンドポイントから公開鍵を取得して署名を検証する二層認証アーキテクチャです。これにより、ユーザー認証（IDトークン）とサービス認証（client_assertion）を分離し、未ログインAPIにも対応可能な設計を実現しました。 LINEログインのemail_verified問題 LINE Login APIから返されるemail_verifiedの値が、他の認証プロバイダー（Google, Apple）と異なる挙動を示す問題に遭遇しました。LINEではメールアドレスを登録していないユーザーが多く、メールアドレスが取得できないケースへの対応も必要でした。各プロバイダーごとに認証フロー内のバリデーションロジックを分岐させ、メールアドレスが取得できない場合は手動入力を促すフローを設計しました。 バイトルIDとの既存認証基盤の並行運用 バイトルIDという既存の認証基盤がすでに複数プロダクトで利用されており、dipIDへの一括移行はユーザー影響が大きすぎて不可能でした。また、リリースの関係で複数のバイトルIDプロジェクトが同時並行で、異なる認証システムを使う期間が存在する課題もありました。その問題を解決するため、dipIDへのログイン時にバイトルIDのユーザー情報をdipID側に登録するとともに、dipIDからバイトルIDの登録処理を実行することで、認証フロー内部でのユーザー情報の移行を実現しています。メールアドレスのバリデーションルールもdipIDとバイトルIDで差異があり、RFC準拠のルールと既存会員の互換性のバランスを取る必要がありました。 工夫したこと 管理工数の最小化 2人体制で最速実装を目指すため、タスク管理のステータスを「進行中」「ブロック中」「完了」の3つだけに絞りました。優先度も「すぐやる」「あとでやる」「そのうち」「要判断」の4段階のみ。日付のトラッキングは時間軸ビューにだけ残し、リストビューからは非表示にして「見るべきものを減らして後工程でのリスクを低減したい」という方針で設計しました。 全社開発者向けドキュメントの体系的整備 dipIDの導入を各サービスチームに展開する際、口頭説明だけでは限界がありました。Notionに技術仕様書を体系的に作成し、用語集（ユビキタス言語）、認証フローの詳細説明、API仕様（エンドポイント・リクエスト/レスポンス・Node.js実装例付き）、クエリパラメータ仕様、Cookie設定、セキュリティガイダンス（REST API vs Firebase SDKの選定基準、リフレッシュトークンの安全な保存方法）を網羅しました。このドキュメントが6サービスの開発チームが実際に参照する全社標準ドキュメントとして機能し、個別の問い合わせ対応を大幅に削減しました。 開発へのAI活用 コード作成の100%でAIアシストを利用し、1月からはClaudeを導入してBacklogのAPIをskillsで叩いてチケット情報の自動取得・問題箇所の特定を行いました。チーム内にsubagentやskillを共有し、Firebaseのアカウント確認や問題調査を自動化しています。 認証基盤の統合的な視点 toC向けのdipIDだけでなく、toB向け認証基盤との連携も自ら推進しました。toB向け認証基盤が新規事業に入る予定がないことに課題を感じ、自らMTGを主催してのtoB向けの関係者、事業責任者、新規プロジェクトのPO/エンジニアを巻き込み、認証基盤統合の議論の場を作りました。 成果 全社6サービスへの展開完了: バイトル、バイトルPRO、バイトルNEXT（Web/App）、やさしい履歴書にdipIDを導入。既存会員も順次dipIDに移行し、バイトル本体へのリリースも完了 新規認証フロー4種の開発: Yahoo!ログイン、メールアドレス・パスワードログイン、ワンタイムパスワードログイン、パスワードリセットを全て新規実装 サービス間認証アーキテクチャの設計: 秘密鍵/公開鍵によるclient_assertion方式を設計し、シナプスチーム側でフロー図が作成されるレベルの具体的なアーキテクチャに落とし込み 全社標準ドキュメントの構築: Notion上にAPI仕様書・シーケンス図・用語集・導入手順を体系的に整備し、6サービスの開発チームが参照する標準ドキュメントとして運用 Terraform IaCの導入: 本番環境のapplyもIaCで完結する体制を構築