請求管理ロボのエンジニアリングマネージャーの白坂です。
先月2022年2月に、請求管理ロボでは認証基盤としてAuth0を導入しました。
導入検討から4ヶ月ほどかけてリリースしたのですが、これまで独自で作り込んでいた認証の機構に対して認証基盤サービスを導入することになったため導入した経緯や当社でIDaaS選定に際してポイントになったことを紹介します。
現在稼働しているシステムへIDaaS導入を検討している方の参考になればと思います。
どうしてIDaaSを導入したのか?
今回IDaaSを導入した請求管理ロボは毎月の請求業務を約80%削減するクラウドサービスです。いわゆるBtoB SaaSで、リリースしてから2022年4月18日現在で7年半ほどのプロダクトです。これまでフレームワークの認証機構を少しずつ拡張していましたが、事業規模の大きなお客様からの引き合いの増加や当社の会社規模の拡大で「セキュリティ」に対応するニーズが増えてきました。主には、多要素認証やシングルサインオン、パスワード漏洩対策といったことが挙げられます。この先も継続的にセキュリティレベルを上げていくことを考え、リードタイムや人的リソース、運用に負荷が大きくなることも加味しIDaaSを利用することとしました。
導入サービス決定のポイント
結論として当プロダクトではAuth0を導入しましたが、多要素認証やシングルサインオン、パスワード漏洩対策といったことは多くのサービスで対応しており当社で導入サービスを決定する上で主なポイントになったのは以下の3点でした。
- 導入のための実装コストが低い
- BOT検知などのセキュリティ強化が容易
- IDaaS利用コストは他のサービスと比べて高いが許容できた
1. 導入のための実装コストが低い
前提として、今回導入対象のシステムはPCのブラウザでのみでの利用を想定したLAMPスタックで作られているWebアプリケーションで、ログイン状態もセッションで管理していました。
そんななかAuth0では、「高いレベルで実装が隠蔽されたSDK」と「Auth0でホスティングされたログインページ(Universal Login)」が提供されており、ログイン状態の管理も含め当社で独自で実装するコードを少なくできるといった点にメリットを感じました。
一例ですが、RFC6749の認可コードフローでアクセストークンがJSON ウェブトークンで送られる場合、有効性を確認してユーザーのメタデータを取得するためには以下のような処理をそれぞれ実装する必要があります。
- アクセストークンをデコード
- 公開鍵で署名を検証
- アクセストークンの有効期限を検証
- JSONから対象のメタデータを抽出
一方で、Auth0のSDKではSDKを初期化した上で以下のようにコンパクトに書くことができます。
// アクセストークンをパース
$session = $auth0->getCredentials();
// トークンを検証
if ($session === null || $session->accessTokenExpired) return false;
// keyを指定してメタデータを取得
$session->user['key'];
2. BOT検知などのセキュリティ強化が容易
また、セキュリティ面でもBOT検知などのセキュリティ対策がコーディング不要で設定できるものも多いため多くの対策がプロダクト開発者でなくともセキュリティ対策を推進できるといった点もポイントとなりました。
3. IDaaS利用コストは他のサービスと比べて高いが許容できた
多くのIDaaSでのコストは主にMAUに依存しています。導入したAuth0は検討時点では他のサービスと比較してMAU単価が高かったのですが、請求管理ロボは自動化に重きをおいており、MAUに対する収益率が高いプロダクトであったことから、上記のポイントにより十分な費用対効果があると判断できました。
導入するためのとったアプローチ
また、IDaaSを決めるためにはざっくりとですが以下のようなアプローチをとりましたので紹介します。
- 要求のリストを作成
- 導入候補のIDaaSを選定
- 導入コストと拡張コストの見積もり
1. 要求のリストを作成
要求のリストは各部署から情報を収集し必須要求と歓迎要求に分類する形で作成しました。プロダクトチームやセールスからは主にターゲットとなる顧客からのニーズを収集し、システム部内では達成するべきセキュリティレベルに必要な機能や非機能要件を挙げていきました。
また、各IDaaSの営業担当やブログなどから一般的に導入時に比較対象となる項目を集めて当社基準で取捨選択するといったアプローチも取りました。
2. 導入候補のIDaaSを選定
基本的には評判の良いIDaaSから2つのプロダクトに絞りました。後続のアプローチで、導入コストの検証のために技術検証を行うことも考えていたため、まずは2つだけを候補にし、それらが要求に合わないようなら追加で検証しようといった考えでスピードを優先しました。
3. 導入コストと拡張コストの見積もり
頻繁に拡張を行う領域ではなかったため、実現可能性や見積もりの精度を上げるため実際に各要求を実現するための仮実装をしました。2週間程度の時間を使いましたが、見落としていた観点が見えてきたりと意思決定に大きな影響を与える結果となりました。
最後に
現在ROBOTPAYMENTではAuth0の活用を含めたセキュリティの強化や事業規模の大きなお客様に向けた開発など、一層プロダクト開発に力を入れています。事業規模拡大に伴い多くのポジションで募集していますので、少しでも興味を持ちましたら是非カジュアル面談ででもご連絡ください。
We are hiring!!
ROBOT PAYMENTでは一緒に働く仲間を募集しています!!!
speakerdeck.com
www.robotpayment.co.jp