先日からぼちぼちと作っているHerokuサンプルですが、新たにソーシャルログインのサンプルを追加しました。(ちなみにPDF出力のサンプルも追加されています。)
http://flect-heroku-sample.herokuapp.com/auth
このサンプル。Auth0というAddonを使っているんですが機能的にはかなりの優れモノです。。
どういうシロモノであるかはサンプルページを見ていただければわかるはず！(^^;
というか、全くわからないようなら説明の書き直しも考えなければならないのですが。。。詳しく説明しようとするならOAuthの説明からする羽目になりそうでなかなかバランスが難しいです。(--
知ってる人からすればそんな説明冗長でしかないわけですし。
OAuthはまだしも、JWT(Json Web Token)については知らない人の方が多そうですがこれも必要最小限の説明にとどめています。(実際のところ小西の理解もこの程度です。)
ご意見ご感想等あれば適当にTweetしてくれれば誰か(?)が拾います。(^^;
★ Auth0の良いところ
さて、ここではサンプルサイトでは書かなかったAuth0の評価について少し書いておきたいと思います。
Auth0の扱っている課題はソーシャルログインとシングルサインオンな訳ですがその課題に対するソリューションのセンスはとても良いです。
ざっと良いと思う点をあげると
- ユーザーのログイン履歴をダッシュボードで確認できるところ
- メールアドレス＋パスワードでのログインをAuth0側の管理DBでサポートしており、なおかつサインアップ時のメール確認フローまで備えているところ
- 対応ソーシャルアプリ30個以上
- テスト環境ではソーシャルアプリ側にOAuthアプリの登録不要
- 周辺機能(Loginダイアログ、LDAP Connector等)の多くがオープンソース
等があります。(実際に列挙してみると思ってたよりたくさんありました。)
コンシューマアプリではFacebookやTwitterでのログインはもはや当たり前になった感がありますが、これまで個別に実装・管理しなければならなかったソーシャル連携を一元化できるのは大きなメリットです。
ソーシャルのみならずAD/LDAP、Windows Azure AD、SAMLなどもサポートしており、認証関連の処理は全部まかせとけ！的な気概が感じられるところも良いです。(^^;
あと、地味に嬉しかったのはソーシャルアプリ側のOAuthアプリ登録について、こことここだけ設定すればOKという最低限の設定方法のヘルプがスナップショット付きで説明されているのがメチャメチャ助かりました。
FacebookやGoogleのOAuthアプリ設定、たまにしかやらないから見る度に画面変わっててとまどうんですよね。。。(^^;(ググっても古い画面の情報が引っ掛かることが多いし)
★ Auth0の課題
一方でこれどうなんよ？と思う点もいくつかあります。
設定系のドキュメントが充実している一方で参照系のダッシュボードの説明がほとんどないというのがまず一点ですが、一番どうかと思うのはユーザの詳細画面で見られるユーザ情報が詳しすぎるという点です。
ユーザ画面では一切説明なく色々な情報が列挙されているんですが、Salesforceアカウントでログインしたユーザ情報を眺めていた時に
あれ？これSalesforceのSessionIDじゃね？
という項目があったので、試しにそれをSessionIdとしてSalesforceのAPIにアクセスしてみたらできてしまったという。。。。(--
これはアカンだろ！！！
もちろん、これをするためにはSalesforce側のOAuthアプリの設定でAPIアクセスを許可しておく必要がありますが、逆に言えばAuth0を使う場合絶対にソーシャルアプリ側から提供する権限を最低限(ユーザ情報の参照のみ)にしておく必要があります。
特定のソーシャル連携を密に行うアプリの場合は複数ソーシャルをサポートする必要はないわけで、Auth0の目的からしたらこれでも問題ないのかもしれませんが、こんなSensitiveな情報は隠しておいて欲しい。。。(--
また、ユーザ画面に「Sign in as User」というボタンがあるのもかなり衝撃的です。
え、このユーザとしてログインする。ってことが一撃でできるってこと？？？
と思って、これまたアリえねーと思いつつ試してみたところ、
An error ocurred. "impersonator_id is a required parameter."
というエラーになりました。(そして、これに対する説明はどこを探してもありません。)
エラーメッセージから推測するに代理ログインする人(impersonator。他者になり済ます人の意)のIDを明示する必要があって誰が代理ログインしたかはわかるようにはなっているのかな？
であればギリギリ。。。
ん～、便利かもしれないけどやっぱりちょっとデンジャラスな気が。。。(--
□□□□
つらつらと書いてきましたが、まぁこんな感じです。(^^;
個人的な評価としては永続的なサービスではあんまり使いたくないけど、短期のキャンペーンサイトなどではむしろ積極的に使いたいと思いました。
ログインはそこがこけると全機能が停止するクリティカルポイントなので信頼性(事業の継続性や障害時の対応)の心配もあって永続的なサービスで使うのはちょっと怖い気がするんですよね。。。
★ 次回予告
今回はAuth0のソーシャルログイン機能を中心にお話ししましたが、LDAP連携についても試しているのでそのお話をしようかと。
(ローカルにLDAPまたはActive Directoryが必要になるのでサンプルサイトには載りません。)