Microservices Advent Calendar 2016 の5日目です。
11月にFiNCさんのMeetupで発表させていただいた 「Auth0を使ってサインインを一括管理したりAzure Functionsをセキュアにしたりした話」 が中々の反響だったのでAuth0について詳しく書いてみようと思います。一応クラウドサービスを利用するという点でギリギリマイクロサービスの範疇なのでは…という解釈です。
(@qsona さんの記事とは全然違う方向性で恐縮です。)
読み方はオースゼロです。
Auth0を理解する
Why Auth0 の動画を観ます。2分くらいです。今すぐ観て下さい。英語がわからなくてもOKです、紙芝居をお楽しみください。
動画を最後まで観たら次に進みましょう。
What a cool service!!
なんて素晴らしいサービスなんだ！そうだ、俺が求めていたものはこれだったんだ！なんて日だ！
このように興奮したあなたの姿が目に浮かぶようです。
より詳細を知りたかったら How It Works も併せてどうぞ。
Webにはセキュリティーが必要である
僕にとってWebは遊びでやっているものでしかありませんが、例え遊びでもそこで何らかのデータを扱う限りそれは誰でにも公開して良いものではなくなってしまいます。
完全にパブリックなものしか扱わないならともかく、AngularのようなSPAをやっていると大体プライベートなデータを扱うようになる。
それにちょっと凝ったことをやろうとするとDBが登場して、そのDBへのアクセスを保護する認証が登場してという具合にタスクがどんどん積み上がっていく。
さてSPAではないアプリならExpress上でPassportライブラリとか使って認証を捌けるけど、SPAではどうしたらいいのでしょう？
とりあえず誰もが真っ先に思い浮かびそうなのは…
最もお手軽なマイクロサービス、Firebase
Googleが買収した Firebase 様が強力なマイクロサービスとして生まれ変わった2016年、皆様思う存分しゃぶりつくしていらっしゃるでしょうか。
無料だとプロジェクトが12個ぐらいしか作れないからクソだって？ ちゃんと申請フォームから英語で拡張を申し出てください。
僕は申請が通っているのでプロジェクトの作成個数制限は100個になっています。実際に100個作ってみたわけではないですがそのように申請したのでそうなっているはず。
申請するときは強気で行きましょう。俺は日本を代表するFirebase開発者だぐらいのことを書いて請願すると良いですよ。もちろん英語ですが。
FirebaseのDB機能については各自言いたいことが山ほどあるのは重々わかりますが、ここではとりあえずそのテーマは脇に置いておきましょう。
AuthとDBの融合、それは神
FirebaseがすごいのはAuthとDBの機能をワンパッケージとして持っていることです。それに加えてHostingとStorageまであって基本無料なのでもう何が何だかわかりません。お前はどれだけ市場を破壊したんだ。
そして Security Rules を書くことで"特定のユーザーだけがRead,Writeできるデータ"を簡単に定義できてしまう。
これ普通のDBでやろうとしたらすごい大変なことなんですよ。Security Rules偉大過ぎます。
他の事業者にとっての救いはFirebase DBが使いものにならないという点です。誰でもこう言いますね。
「趣味で使う分にはいいけど。。。」
そうは言っても認証機能をFirebaseにロックインされたくない
Firebase Authはすごく便利です。誰でも簡単にSPAに認証機能を組み込めます。一度やってみればわかります。Webアプリチュートリアル もよくできていますね。
ところがだ。
便利なのはあくまでFirebaseだけを使ってアプリを構築するという極めて限定的で排他的な環境においてのみ。
普通はむしろ逆です。一部の要件のためにFirebaseを使いたいのであってそれを中心に据えたいわけじゃない。
Authにしてもトークンを使い回して他のサイトにSSO(シングルサインオン)をやろうと思えばできなくはなさそうだけど、ドキュメントに書いてないしめんどくさそうな香りが漂っています。
かといって認証を自分で書きたくない
Why Auth0 の動画を観ましたよね？
僕が認証のことをまだ何もわかっていなかったとき、どうやって認証機能を組み込んだらいいのだろうと 調べてもわからなくて途方に暮れる×100 ぐらいの苦行を味わいました。人類に認証は難しすぎるのです。
そして出会ったAuth0、ちなみに ブログ も幅広く技術レベルが高そうな記事が多いです。フォントサイズが小さいのがつらいですが読む価値はあります。
例えばFirebase Authには2段階認証の機能はありませんが、Auth0にはあります。(有料プラン限定だったかも)
例えばFirebase AuthはGitHub,Twitter,Facebook,Googleのアカウントで認証できますが、Auth0はもっと多くのサイトと連携しています。詳しくは How It Works で。
例えばFirebase AuthはiPhoneの指紋認証は使えませんが、Auth0はできる。らしい。
Auth0にロックインされるのはいいのか
Auth0がダウンしたら認証できなくなってサービス全体が影響を受けるというリスクはもちろんあるので、本当にクリティカルで大規模なサービスなら体力もあるだろうし自前でやればいいと思います。
しかし企業で言えば中小零細企業が圧倒的に多いのと同様、Webサービスの世界でも小規模なサービスが圧倒的に多いですよね。
遊びでやってるものも含めたら99%ぐらいは多少Auth0で障害が発生しても影響ない規模レベルなんじゃないかと思います。
そのへんが気になる方向けに Availability & Trust というページがあります。
JWTなのでSSOできる
SEOではありません。
Auth0で認証するとクライアントは JWT(JsonWebToken) を受け取ります。ちなみにJWTはCrafted by Auth0です。
JWTは汎用性の高さが売りで、容易に他のサイトへのSSO(シングルサインオン)に利用できます。
「Auth0を使ってサインインを一括管理したりAzure Functionsをセキュアにしたりした話」 でもJWTを使ってFirebaseにもこっそりサインインするという話を紹介しました。
UXを考えるとSSOの重要性はかなり高いんじゃないかなと思います。
ドキュメントが豊富
Auth0 Single Page App Quickstarts を見るとSPAに関するドキュメントだけでも豊富に揃っていることがわかります。
英語が読めない方は英語を勉強するかGoogle翻訳を使ってください。
ところで最近見かけた利用例
AWS Lambdaってあるじゃないですか。あれの Serverlessフレームワーク っていうのがありますよね。
そこに入って右上の「Join Beta」をクリックしてみてください。これAuth0です。
以上です。
一通り僕がAuth0について思い当たることをだらだらと書き記してみました。マイクロサービスの一角を占めるのに中々有力ではないでしょうか。
明日も @qsona さんです。
(Auth0を実際にAngularアプリに組み込む例を Angular Advent Calendar 2016 5日目 で紹介しています。)