フレクトのクラウドblog re:newal

http://blog.flect.co.jp/cloud/からさらに引っ越しています

トップ > Auth0の話

Auth0の話

こんにちは。としやさんじゃない方の齋藤です。Advent Calendar の季節がやってきました。

qiita.com

HerokuのDynoやアドオンの構成は、定番がありつつもプロジェクトごとの微妙な色彩の違いにフィットさせる必要があり、いつも座組みに頭を悩ませるところでありますが、個人的にはカードゲームのデッキ構築みたいなものだと思っています。Creditぎりぎりまで強いカードを少しでも多く入れたい。

ずっと前から存在は知っていたAuth0にようやく触れる機会が取れたので、検討している方に少しでもヒントになればと思ってAuth0の紹介をしてみたいと思います。

Auth0とは

f:id:shns:20191217224440p:plain https://auth0.com/jp/

IDaaS/CIAMとして最もポピュラーなサービスの一つで、たとえば認証・認可、セキュリティにまつわる 面倒な実装をせず、強力な認証基盤をすぐさま自身のアプリに取り込むことができます。

Documentationにある Overview を見ると、

Auth0 provides authentication and authorization as a service.（Auth0は認証と認可をサービスとして提供します）

https://auth0.com/docs/getting-started/overview

とありますが、のみならず

  • ログイン履歴をダッシュボードで見れたり
  • 会員機能にまつわるメール機能は一通り備えていたり
  • 既存の認証基盤とつなげやすかったり

といったように、使いやすさや拡張性、開発者目線の機能が豊富です。

特徴

特にSDK、サンプルコード、対応するソーシャルログインなど、品揃えが圧倒的。

f:id:shns:20191217224856p:plain f:id:shns:20191217231118p:plain

それと今年はLINEやSign in with Appleが標準で提供されたりしました。

auth0.com auth0.com

また、個人的な印象としては、管理者向けのダッシュボードがとにかく始めやすいように作られているので、従来のエンタープライズ系SSO製品と比べて、0を1にする部分の苦しみから開発者が圧倒的に解き放たれる感があります。OpenAMの複雑な管理者画面の遷移の仕方を覚えたり、ちょっと設定を変えたいだけなのに/var/lib/tomcat/webapps界隈に足を運ばないと行けなかったり・・といった手間はないので大事なコードに集中できる感は圧倒的に勝っています。

引き算の美学

いつもシステム構成の下敷きとして定期的に見直しているpostに以下があります。

https://engineering.videoblocks.com/web-architecture-101-a3224e126947

上のポンチ絵には出てこないのですが、初学を終えてこの絵が分かる頃に ちょうど認証認可の仕組みの理解が必要になるタイミングがあると思うのですよね。

Javaでいうと、スレッドプログラミングができたら中級者みたいなそんな感じかな・・（個人の意見です）

現代のWebアプリにはログイン機能は当たり前のようにありますが、自前で作る場合は思ったよりも機能が爆発したり、OpenAMなどのオープンソースを使うにしても非機能要件を考慮した結果それなりにインフラ面が大掛かりになってしまったりと、トータルで見たときに手間が大きくなってしまうことがあります。

一方で、ID基盤が提供するところのログインというユーザ体験そのものとしては、

  • かなりの頻度で通る（実装次第ですが）
  • 複数経路があり、エントリーポイントが多い
  • 比較的早い回遊タイミングで到達されることが多い

といった点があり、最初から入れるにはそこそこ大玉で、かといって後から入れるには 全体への基盤改修リスクが大きい、といった結果として跳ね返ってきます。

コンバージョンを継続的に改善したいB2C系サービスや、 顧客情報は集めたいけど顧客のストレスを増やしたくないと考えているサービスにとって、 導線検討やセキュリティ面の考慮というのは避けて通れない。

こういった手間がかかるが逃げられない、といったジレンマが 強力な標準提供サービス（SDK、テンプレートコードなど）によって 抽象化ないしスキップできてしまうのがAuth0の良いところかなと。

CRMとの親和性

CIAMとして見て、やはりCRMとの親和性の高さがポイントの1つかなと思っています。

ユースケースとしては、認証・認可の仕組みとして利用しつつ、 Auth0ログイン時などにログをイベントとして受け取れるので、KafkaやAmazon Eventbridgeを配管して function codeやバッチ処理からCRM・MAに取り込み、ネイティブにプッシュ配信、など。

auth0.com

Log driven なので、セキュリティオートメーションでも重宝しますね。

あるいはCRM上のビジネスユーザは別のテナントなりアプリケーションで SAML FederatedにSSOしてWebアプリ側にも行き来しやすくする、といったアプローチも取れます。

Auth0の良いところは、Rulesを使って認証時の様々なフック処理を書けるところです。 こんな感じで。

f:id:shns:20191217225549p:plain

管理者のコンソールでコード片のデバッグが出来るのは地味に強い。それはそれとして、Auth0標準のカスタムデータベースとソーシャルログインのユーザをマージする前提でWebアプリを組むときや、外のサービスを呼びつつid_tokenに必要な情報を詰め込みたいとかログインのうち何回かは外部DBからの最新情報を取ってきてキャッシュしたいとか、色々なユースケースで活躍します。

主要なイベントについてはテンプレートがあるので、流用開発ベースで進めることができ、どれくらい手間がかかるのかの見立てが立てやすいところがポイント。

収集・集約・アプローチのタッチポイントをAddonインストール一発で作れるのは非常にありがたいところなのではないでしょうか。

Add-onsとしての利用

今年、yonyonさんとSWTTでHerokuの話をしたとき※には認証周りの話題はしなかったのですが、当然Herokuのアプリで認証込みでサービスを作るときにはAuth0が第一の選択肢になってきます。

見積から開発・運用まで！Herokuの基本とTips - Qiita

当たり前ですがHerokuのユーザで各ステージのアプリにシングルサインオンできるし、テナントのユーザ権限もHerokuユーザに付与できるので、ちょっと管理者ユーザとして他の人に見てほしいときに、Collaboratorとして招待できますし。

Add-onプランとしては以下があります。

https://elements.heroku.com/addons/auth0

  • Free
  • Silver
  • Gold
  • Enterprise B2C

AD連携やマルチデータソース戦略を取るわけでなければ、意外とキャップは少なくFreeで出来ることが多いです。なのでステージ構成としては、development,stagingはFree/Silverで、productionから GoldもしくはB2C Enterpriseという構成などでも良いかなと思います。

Planを考えるときの閾値については、MAU（Monthly Active Users）がベースとなります。つまり、月1回でもログインすればそのユーザは1カウントとして計算され、プランごとの上限値はそのMAUで決まります。

f:id:shns:20191217230432p:plain

この例で言うと、Enterprise B2C の 10,000 Usersに対して先月は2,500ユーザ。まだまだ余裕があります。

一応 Dashboardのトップでもログインユーザのサマリが確認できるのですが、各月のアクティブユーザについては以下から当月のQuotaを参照できます。

User Dropdown > Account Usage > Home > Quota Utilization > Regular Active Users

なお、Auth0でユーザ登録する（Database User）とソーシャルログインを併用しており、両者をマージルールで1ユーザとしてマージした場合には、どちらのログインを利用してもMAUは1カウントになります。逆になると別カウントなので、マージ可否は要件として決めておいた方が良いです。

リミットを超えてきそうな場合にはプランの引き上げ（再検討）が必要になりますが、最初からGold以上で行くなら最初にキャパシティ設計をしっかりやっておきます。だいたいHerokuはスモールスタートもしくは3-5年くらいを目安に非機能設計しておくのが多いと思いますが、予想よりサービスがうまくいくと、それでも不足するケースもあります。

しかし、重要なのはビジネス成功に伴ってPlanを拡張するというポジティブな拡張。

とはいえ、RFMっぽくlast_loginが一定以上な「休眠ユーザ向け」にキャンペーンを打って月のログインがスパイクするようなケースなど、予期しきれないユーザ激増などもあると思うので、適度に流量と容量は見ておいた方が良いです。

モニタリングの選択肢としては、シンプルにダッシュボードを見るようにするのが手っ取り早いですが、

  • Log->Amazon Eventbridge IntegrationからSQSに貯めて、一定量キューが溜まったらMAU計算して通知するfunctionを書く
  • 1-off Dyno + Management APIで定期的に以下略

あたりができると良いと思います。思いついただけで作ったわけではないけど・・・

Freeで出来ることが非常に多いアドオンなので、とりあえず使ってみてから考えればよいかなと思います。

小西さんの書いた弊社過去ブログやサンプルサイトにも載っているので、ご参考までに。

ちょっとだけ気になるところ

ドキュメントやリファレンスはオープンかつそれなりに充実しているものの、使ってみて多少癖のあるところや認証基盤ならではの沼っぽいハマり方をするケースも時々あります。

よくあるトラブルシューティングやベストプラクティスがわかるようなナレッジベースが充実するとより良いな・・・と思ってます。

とはいえこれだけの機能をそれなりに小ささでも使うことができるのはやっぱりサービスとしての力があるのだと思いますし、こまめなアップデートも結構好きなので、たぶん来年も追っかけていくとは思います。それでは。