請求管理ロボにAuth0を導入しました

請求管理ロボのエンジニアリングマネージャーの白坂です。

先月2022年2月に、請求管理ロボでは認証基盤としてAuth0を導入しました。

導入検討から4ヶ月ほどかけてリリースしたのですが、これまで独自で作り込んでいた認証の機構に対して認証基盤サービスを導入することになったため導入した経緯や当社でIDaaS選定に際してポイントになったことを紹介します。

現在稼働しているシステムへ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'];