認証・認可を自前実装しないためのAuth0導入 〜NTPの苦き思ひ出を添えて〜

ユーザーがログインして使うサービスにおいて認証・認可の仕組みを実装する際、セキュリティの観点を考慮して設計をする必要があります。設計に時間が掛かり、サービスの本質部分を開発する時間が十分に取れないこともあります。 自社開発プロダクト「SEARCH WRITE」でもログイン機能や管理機能を実装していますが、一から作る代わりに Auth0というIDaaSを導入し、セキュアな認証・認可の仕組みを比較的簡単に組み込むことで、サービス本来の価値づくりに集中できました。本番環境で1年以上運用してみた経験に基づき、Auth0のメリット・デメリット、そして導入する際の失敗談を紹介します。

Auth0とは

Webアプリやモバイルアプリ、WebAPIなどに対して認証・認可の機能を提供するIDaaS(Identity as a Service)です。

IDaaSとは

クラウド経由でログイン情報管理・シングルサインオン(SSO)・アクセス制御などの仕組みを提供するサービスです。

Auth0のメリット

大きく分けて2つあります。

認証・認可の仕組みを自前で実装しなくて済むため、工数が削減できる

Webやモバイルでユーザー認証・認可の機能を組み込む際、ログイン機能やAPI間の認可の仕組みなど、セキュリティの観点から様々なことを考慮して開発しないといけないため、時間がかかります。

しかしAuth0を導入することによって、セキュアな認証・認可の仕組みを比較的簡単に組み込むことができるようになり、サービス本来の価値を作り出すことに集中して使えるようになります。

ユーザー管理機能が標準でついている

Auth0を導入することで、ユーザー管理用のダッシュボードをWebから簡単に確認でき、さらなる工数削減に繋がります。また、API経由でユーザーのログイン履歴を取得することも可能です。 ログイン状況をダッシュボードで把握できるため、利用状況の可視化機能を新規で作る必要もありません。

自社プロダクトでのAuth0利用

SEARCH WRITEはフロントエンドとバックエンドを完全に分離したSPA + WebAPIで動いています。認証(あなたは誰ですか)に関わるログイン機能はフロントエンドとAuth0の連携のみで実現しており、バックエンドは認証部分に関わっていません。ユーザー管理と認証部分をAuth0に任せられるため、バックエンドでの自前実装によるリスクを避けることができます。

一方でフロントエンドからの認証・認可では、Auth0の仕組みを理解した上で実装する必要があります。SEARCH WRITEはBtoBのSaaSであり、ログインユーザーのみがWebAPIを使えます。リクエストをしてきた人が登録されたユーザーなのか(認証)、対象のWebAPIを使っていいのか(認可)をAuth0を使ってチェックします。

フロントエンドからIDとパスワードをAuth0に送るとTokenが発行されます。このTokenをサービスのWebAPIをコールする際に付与します。WebAPIでは認証は行わない代わりに、このTokenの検証を行います。Tokenは公開暗号方式で作成されており、復号できるか(=改ざんされていないか)・有効期限内か・権限などのサービス利用に必要なユーザー情報を持っているかなどを検証することで、不正なリクエストを防ぐことができます。

認証・認可はプロダクトの競争力に直接関わる部分ではないため、Auth0のようなIDaaSに任せることで、自前実装によるリスクや工数を減らせました。私自身、初めてこのような仕組みを取り入れましたが、今まで全部自前実装していたのに比べて、開発の進め方がここまで変わるのかと、良い意味で驚きがありました。

しかし、実は開発途中でやらかしていたことがあります。

Auth0を導入した時の失敗談

ユーザーがログインした時にAuth0が発行するTokenにはToken発行日の情報が含まれています。サービスのWebAPIはTokenの発行日時も含め検証し、WebAPIをコールして良いユーザーなのかを確認しています。

Auth0導入初期、WebAPI側の認可処理を担当していました。実装が完了し、フロントエンド とWebAPIの導通チェックをしていると、なぜか18秒必ず待ってからWebAPIをコールしないと認可が通らない問題が発生しました。

その原因を調べるために問い合わせや調査をしてみましたが、全く見当がつきません。ある日先輩のPCで試してみると、なんと18秒待たなくても認可が通るのです。判明してみれば単純な原因で、私のPCの時刻が日本標準時から18秒遅れており、認可処理でTokenの発行日時を検証したときにAPIコールされたPCの日時がまだTokenの発行日時ではないため、受け取ったTokenは不正扱いとなっていたのでした。

自分のPCの時刻がずれているだけで通らなかったという事実がとてもショックで、今では毎日時間がずれていないかのチェックを行うことをしています。Auth0に関わらず、日時に関わる処理などを行う際はPCの時刻にずれがないかの確認をおすすめします。

本番環境で開発・運用をして実感したAuth0のメリット・デメリット

最後に改めて、1年以上Auth0を本番環境で開発・運用してわかったメリットとデメリットをまとめます。

メリット

• 認証・認可処理の大部分を任せることができた
• Auth0のWebhookがとても便利だった
  • ユーザー側の操作をトリガーとして裏側で実行したい処理がありました(例: ユーザー登録時にSEARCH WRITEチームのチャットに通知する)。Auth0のWebhookを使えば、この設計も容易です。Webhookがあるおかげで、認証・認可処理をAuth0に任せたとしても、その後に走らせる処理と連携しやすくなっています。このように自由が効くため、導入時の設計もしやすかったです。
• 公式サンプルが豊富
  • AndroidやiOSなどのモバイルに加え、JavaやPHP、Rubyなど数多くのサンプルが公開されており、導入する際にとても助かりました。

デメリット

• 認証・認可周りの知識は当然必要 = Auth0を使えば考えなくていいわけではない
• OpenID Connectの仕組みを理解していないと、Auth0との責任分解の設計が難しい