Auth0 – 認証基盤の技術と発想

初めての方、初めまして。そうでもない方、お久しぶりです。

タケダノです。

 

技術は発想と一緒に進歩していくのです。

 

re:MARSに絡めて、ジェフ・ベゾスさんの暖炉に刻まれた話が取り上げられていましたね。

ドリーマーとビルダーが存在するという話

私は、この記事を読んで、二人のスティーブが立ち上げた会社を思い浮かべました。

企業研究をすると必ず出て来るリンゴの会社を作ったのはドリーマーのスティーブなのか、ビルダーのスティーブなのか。

技術の進歩には発想が必要で、逆に発想だけでも技術は進歩しません。

 

2013年新しい技術Auth0を立ち上げたのは1人のアルゼンチン人ユヘニオ・ペースさんとその仲間、当時マイクロソフトで認証基盤を作っていたチームメンバーです。ユヘニオさんは認証基盤に関する本も出版されています。

 

認証しないWeb環境は無い

これまで、認証基盤は、それぞれが保有するサーバー環境にデプロイされ、サーバー外からの他者からは隔離されるという仕組みを取ってきました。システム毎に認証基盤を構築し、メインテナンスを必要とするのです。

 

サーバーがあるからサーバーメインテナンスが必要、それならばサーバーを無くしてしまえ、ほととぎす。というのがサーバーレスの発想だと思いますが、認証基盤を丸っと外出しして１つの会社が一括管理したらいいんじゃない？という発想をAuth0はしています。

認証・認可に関する開発工数を0にするというコンセプトからAuth0となづけられました。

Never compromise on Identity

というキーフレーズも、なかなか格好よいと思います。

認証・認可サービスはIDaaS(アイダース)と呼ばれるSaaSの一種です。

 

基本的にAuth0サーバーは、お客様が持つ環境とは別のところに独立して存在します。パブリッククラウドでは米国、欧州、オーストラリアの3カ所とされています。プライベートクラウドとして、任意のリージョン（日本を含む）にデプロイすることも出来ますし、マネージドプライベートクラウドとして、自社の環境内にデプロイすることも可能です。

 

実はエンジニアは、0から新規に作るのではなく、Auth0サーバーの、どの機能を使うかという設定をするだけで認証基盤が使えるようになるため、早ければ数日、そして94%の顧客が1ヶ月内にデプロイが完了するというデータがあります。

 

例えば、Facebookログイン、Twitterログイン、多要素認証、Active Directory、Touch ID、パスワードレス認証などが、その設定画面に現れますが、それらは視覚的にスイッチのオン・オフで表示されており切り替えることが出来ます。

最近ではβ版ではありますが、Sign In with Appleをサポートしはじめました。

【速報】Auth0がSign In with Appleをサポートしました！（ベータ版）

 

スマートフォンや、PCなどの端末側は、まずAuth0サーバーに認証を求めるアクセスをします。するとAuth0サーバーはクレデンシャル情報に紐付いてアクセス権限や有効期限のあるトークンの発行をします。

海外のゲームセンターでゲームを遊ぶときに現金をトークンとしての疑似コインに交換して1ゲーム2トークン、1ゲーム4トークンとして遊ぶことがあります。トークンというのは大衆食堂の食券、もしくは人間ドックで持つカルテのようなイメージをすると分かりやすいと思います。

Auth0が発行するトークンには、そのユーザーがアクセス出来るプロジェクト、データベース、などなどなどが記載されているので、ユーザーはトークンを持ってサーバー環境にログイン出来ます。このとき、このプロジェクトは、SAML(サムル)、OAuth(オーオース)、JWT(ジョット)などに対応していれば、オンプレミスでも、AWSでも、他のクラウドにさえ適用できるのでマルチクラウド新時代に対応出来るということになるのです。

先にも触れましたが、主要な機能はAuth0サーバーにあり、その中でどの機能を使うかはユーザー側で設定するということは、機能面でアップデートがあった場合も、Auth0側で一括管理をしてしまうということになります。

 

冒頭にも触れましたが、技術と発想の話に関連して、新しい発想に優れた２つの点が挙げられます。

1つ目は、Auth0のコンセプトそのものですが、認証・認可に関する機能を外出しすることで、これまで煩わされてきたメインテナンス、セキュリティ対策、アップデートなどを気にしなくて良くなります。

どの事業会社も本業があるはずで、社内で数少ないエンジニアも本来するべき業務があるはずです。それが認証・認可に関するメインテナンスに煩わされることは不本意で、その人的リソースを本業に集中させることが出来ます。

2つ目は、外部で発行されたトークンによって認証・認可が行われるため、そのトークンに準拠するSAMLやJWTであればAWS環境に限らず、オンプレミスも含むマルチクラウドに対応出来ます。

 

システムが複雑になればなるほど、認証・認可も複雑になっていたのが、これまでのやり方かもしれませんが、一度発想を切り替えてみてはいかがでしょうか。

 

クラスメソッドはAuth0と契約代行・支払代行・構築支援のパートナーとして提携しています。

 

Auth0に関する定期的なセミナーも開催を予定しています。

興味があれば、まずはお問い合わせください。