ぴろログ

Output Driven

「Auth0」のRulesが便利機能だった!! / 『「Auth0」で作る!認証付きシングルページアプリケーション』でAuth0をさわってみた

最近Auth0という単語をチラホラ目にするようになりました。以前個人でアカウントを作ったきりノータッチになっていたので、久しぶりに触ってみながら機能を思いだすことにしました。
認証時の処理を定義できるRulesという機能がおもしろかったのでそこを中心に、他はさらっと情報を載せています。

ちなみに、Auth0のユーザコミュニティも誕生したみたいです。 dev.classmethod.jp

目次

Auth0とは

Auth0は、Web、モバイル、およびレガシーアプリケーション向けのユニバーサル認証・認可プラットフォーム です。 (ホームページより引用。)
認証・認可周りを自前で構築しないで済むよう、SaaSとして提供されている感じですね。 auth0.com

Gartner Magic Quadrant(2018年6月)では、Access ManagementVisionaryと位置付けられているようです。

auth0.com

機能

Auth0の方の記事がありましたので、抜粋させていただきました。

  • OAuth 1.0/2.0やOpenID Connectといったオープンな認証・認可方式に対応
  • Mobile Native AppやWeb API、Single Page Applicationにも対応
  • ユーザーストア(Connection)にはAuth0標準(ビルトイン)であるMongoDBはもちろんのこと、企業がすでに使用している各種DBやActive Direcotry,LDAPなど複数のユーザーストアを利用することができるだけでなく、様々なソーシャルネットワークのアカウントを利用したユーザ認証・認可を簡単に利用することが可能
  • 多要素認証にも対応しており、Auth0が提供しているAuth0 Guardian MFAだけでなく、Google AuthenticatorやDUO Securityなどの多要素認証(MFA)も利用でき、EmailやSMSを介してOTPを送信する、Passwordless認証にも対応

ソーシャルサービスのアカウント(Googleアカウント、Twitter、等)が利用できるので、「ユーザがAuth0(を使ったSaaS)用のアカウントを作成不要」である点がメリットになりそうです。

qiita.com

AWSのCognitoとの違いが気になります。自分で調べるのはしんどいなーと思っていたら、ちょうどいいイベントがあるようなので、資料が共有されることに期待です。(沖縄でも開催されないかなー)

コスト

4種類のプランが用意されています。 Pricing - Auth0

  • Free
    • 無料
    • 利用できるソーシャルアカウント数に制限あり(2種類まで)
  • DEVELOPER
    • $13/月
  • DEVELOPER PRO
    • $745/月
  • ENTERPRISE
    • 要問い合わせ

各プランで使える機能の情報も、資料として共有されることに期待!(他力本願)  

各機能をさわってみた

積読していた『「Auth0」で作る!認証付きシングルページアプリケーション』(以下、『「Auth0」で作る!〜』)を参考にして、ローカル環境にnuxtでSPAを構築しながらAuth0の機能を確認しました。

※本記事には環境の構築手順を載せていませんので、気になった方はご購入をどうぞ。kindle版が¥691です!!(2019/05/04現在)

Auth0のアカウント作成手順はこちらでも確認できます。
クラウド認証サービス Auth0 の無料トライアルを試してみよう - Qiita

Lock

Lockは埋め込み用のログインフォームです。yarn add auth0-lockでパッケージ追加してNuxtのプラグインとしてサクッと実装できました。

Lock - Auth0

f:id:pirox07:20190504150543p:plainf:id:pirox07:20190504150600p:plain
「ログイン」をクリックするとLock(ログインフォーム)が表示される

URLバーを見ると、ログイン画面はオリジナルのサイト内(http://localhost)で表示されていることがわかります。↓の通り、デフォルトでOverlayで表示されるようになっているみたいです。(Mobileは準備中?)

f:id:pirox07:20190504203921p:plain
"https://auth0.com/lock -Modes-

Social Connections

Googleはもちろん、これだけのソーシャルアカウントが利用できます。

f:id:pirox07:20190504195455p:plainf:id:pirox07:20190504195459p:plain
Dashboard > Connections > Social

なぜこの並びにdocomoが??と思い調べてみたところ、2017年にNTTドコモベンチャーズが出資してるんですね。(docomoのアカウントって何だろう?)
Auth0, Inc.への出資について | 株式会社NTTドコモ・ベンチャーズ

ソーシャルアカウントでログインすると、Usersにアカウントが追加されます。画像はGoogleGitHubTwitterでログインした後のダッシュボード画面です。複数アカウント扱いになっていますが、メールアドレスによる名寄せにより、同一メールアドレスの場合はアカウントを一つにまとめることが可能なようです。

f:id:pirox07:20190504212648p:plain
Dashboard > Users & Roles > Users

Universal Login

認証画面のUI設定、企業のロゴを埋め込めるようです。

f:id:pirox07:20190504214811p:plain
Dashboard > Universal Login
ブログのファビコンのURLを指定してみると、いい感じ?に表示されました。
f:id:pirox07:20190504222151p:plain
Auth0のロゴ → 「ぴ」 に変更

ダッシュボードのあちこちで「Guardian」という言葉が出てくるのですが、これはAuth0のMFAアプリのことでした。 auth0.com

Rules

定義したルールによって、認証時の処理を変えることが可能です。ルールはJavaScript(node.js)で記述し、裏ではWebtaskというAuth0が提供しているコンテナベースのFaaSが動いています。ルールのテンプレートが豊富に用意されており、いくつか気になったものを試してみました。(テンプレートの一覧を記事末尾に記載しておきます。)

Rules① MFAの強制

ソーシャルアカウント側がID・パスワードのみの認証でも、Auth0側でMFAを追加することができます。

準備として、Multi-factor AuthenticationのSMSを有効にしておきます。(FreeプランだとSMS送信の上限数が100件の模様)

f:id:pirox07:20190504153044p:plain
Dashboard > Multifactor Auth

次にルールを適用します。テンプレートの「Require MFA once per session」をそのまま適用します。

f:id:pirox07:20190504160836p:plain
Dashboard > Rules > CREATE USER をクリック

f:id:pirox07:20190504160843p:plain
テンプレート一覧から「Require MFA once per session」を選択

f:id:pirox07:20190504160847p:plain
内容はそのままでSAVE

その後、Auth0でGoogleアカウントを使った認証(ID/パスワード入力)を行うと、電話番号の登録フローが開始されます。(URLがlocalhostから切り替わりました。)

f:id:pirox07:20190504163307p:plainf:id:pirox07:20190504163315p:plain
電話番号の登録フロー 1/2
f:id:pirox07:20190504163323p:plainf:id:pirox07:20190504163330p:plain
電話番号の登録フロー 2/2

以降、認証時にはSMSに送信される認証コードの入力も求められるようになりました。

Rules② メールアドレスのドメインによる制限

Email domain whitelist」を利用することで、メールアドレスのドメインによる認証制御が可能です。 下の例は「hoge.com」ドメインのみ許可する認証を行うもので、この状態ではGoogleアカウント(@gmail.com)での認証が拒否されました。

//Email domain whitelist

function (user, context, callback) {

  // Access should only be granted to verified users.
  if (!user.email || !user.email_verified) {
    return callback(new UnauthorizedError('Access denied.'));
  }

  const whitelist = ['hoge.com']; //authorized domains
  const userHasAccess = whitelist.some(
      function (domain) {
        const emailSplit = user.email.split('@');
        return emailSplit[emailSplit.length - 1].toLowerCase() === domain;
      });

  if (!userHasAccess) {
    return callback(new UnauthorizedError('Access denied.'));
  }

  return callback(null, user, context);
}
Rules③ 特定時間帯のログインをSlack通知

社内システムでAuth0を利用することを想定して、深夜帯のログイン→アノマリー(異常)としてSlackに通知させることができないか試してみました。できました。

f:id:pirox07:20190504171148p:plain
Slackへの通知結果

// Slack Notification on User Login

function (user, context, callback) {

  // トークン再発行は通知しない
  if (context.protocol === 'oauth2-refresh-token') {
    return callback(null, user, context);
  }
  // get your slack's hook url from: https://slack.com/services/10525858050
  const SLACK_HOOK = configuration.SLACK_WEBHOOK_URL;  //環境変数を使用
  const slack = require('slack-notify')(SLACK_HOOK);
  const message = 'logind ' + (user.name || user.email) + ' (' + user.email + ')';
  const channel = '#notify-audit';

  // 時刻の取得
  var dt = new Date();
  var login_hour = dt.getHours();

  // テスト:16時台(JST)のログインのみ通知
  if (login_hour === 7) {
    slack.alert({
      text: message,
      channel: channel
    });
  }
  // don’t wait for the Slack API call to finish, return right away (the request will continue on the sandbox)`
  callback(null, user, context);
 }

WebhookのURLは環境変数として扱っています。環境変数を参照するには、process.envではなくconfigurationと記述する必要があるので注意です。 環境変数ダッシュボードで設定します。

f:id:pirox07:20190504171449p:plain
「Rules」画面下側の「Settings」で環境変数を設定

ここで気になったのが通知のタイミングです。
Googleアカウント情報の入力後、SMSの認証コード入力前のタイミングで通知を受信したので、厳密にはログイン前です。

ドキュメントに以下の記述があるので、認証プロセス完了時にRuleが実行されるものだと思っていました。

Rules are JavaScript functions that execute when a user authenticates to your application. They run once the authentication process is complete, and you can use them to customize and extend Auth0's capabilities. auth0.com

Rulesには処理の順番の概念がありそうだったので、MFA適用のルールを一番上に持ってきたのですが、それでも状況が変わらず。 f:id:pirox07:20190504223406p:plain Googleアカウントでユーザ識別ができた=認証プロセスは完了、(ログインはMFAでの確認後、)という扱いなのでしょうか。。この辺りは設定方法のコツがありそうです。

Logs

ダッシュボード上の操作、ユーザの操作(ログイン失敗、等)のログが参照できます。クエリもかけられます。

f:id:pirox07:20190504213438p:plain
Dashboard > Logs

Anomaly Detection

挙動を試せていませんが、ブルートフォースアタックを受けた際や、(サブスクリプションになりますが)漏洩したアカウントによるログインの制限できるようです。

f:id:pirox07:20190504193545p:plain
「Breached-password Detection」は嬉しい機能

アカウント情報の漏洩有無の情報元はHave I been pwnedと同じかな。(公開されているデータベースがあるのかな)

まとめ

Auth0で簡単に認証・認可機能が実装できることが確認できました。思っていたより多機能で、エコシステムも充実していきそうな印象を受けました。 社内システムのアカウントはAzureADを中心としたSSOを進めているのですが、補完的な使い方ができるかチェックしていきたいと思います。

ご参考:Auth0で用意されているRuleのテンプレート

2019/05/04現在で用意されているテンプレートです。名称をコピペしただけですが、実現できることはおおよそ推測できます。

よくよく見ると「Trigger A Zap〜」で始まるテンプレートがあって、これらはZapierをキックするトリガになっているようです。もう何でもできちゃいそう。

  • Access Control
    • Allow Access during weekdays for a specific App
    • Active Directory group membership
    • Check if user email domain
    • matches configured domain
    • Check last password reset
    • Disable the Resource Owner endpoint
    • Disable social signups
    • Whitelist on the cloud
    • Force email verification
    • IP Address whitelist
    • Link Accounts with Same Email Address while Merging Metadata
    • Link Accounts with Same Email Address
    • Set roles to a user
    • Email domain whitelist
    • Whitelist for a Specific App
    • Whitelist
    • Whitelist on Specific Connection
  • Enrich Profile
    • Add attributes to a user for specific connection
    • Add country to the user profile
    • Add persistent attributes to the user
    • Add user roles from a SQL Server database
    • Default picture for null avatars
    • Use a custom sized profile picture for Facebook connections
    • Enrich profile with FullContact
    • Enrich profile with the locations where the user logs in
    • Enrich profile with Towerdata (formerly RapLeaf)
    • Get email address from Twitter
    • Use the original sized profile picture for LinkedIn connections
    • Remove attributes from a user
    • SAML Attributes mapping
    • Roles from a SOAP Service
    • Detect Fraud Users
  • Webhook
    • Custom webhook with ASPNET WebApi2
    • Creates a new Lead in Salesforce on First Login
    • Record or update an Intercom User
    • Send emails through Mailgun
    • Send email with Mandrill
    • Tracks Logins in MixPanel
    • Obtains a Pusher token for subscribing/publishing to private channels
    • Send events to Keen
    • Send emails through SendGrid
    • Slack Notification on User Signup
    • Tracks Logins/SignUps with Splunk HEC
    • Update user profile identity in Firebase
    • Trigger a Zap on Every User Login
    • Trigger a Zap on New Users
  • Multifactor
    • Multifactor with Duo Security
    • Multifactor with Auth0 Guardian + Authorization Extension
    • Multifactor when request comes from outside an IP range
    • Multifactor with Auth0 Guardian
    • Multifactor Authentication
    • Require MFA once per session
  • Guardian
    • Multifactor with Auth0 Guardian + Authorization Extension
    • Multifactor when request comes from outside an IP range
    • Multifactor with Auth0 Guardian
  • Debugging
    • Dump rule variables to RequestBin
  • Saml
    • SAML Attributes mapping
    • Change SAML configuration

ご参考:認証 / 認可のかっこいい表現

『「Auth0」で作る!〜』内で、認証・認可のかっこいい表現が紹介されていました。

  • 認証:AuthoriZation / AuthZ
  • 認可:AutheNtication / AuthN

ドヤ顔で使っていきたいと思います。

また、認証方式(Cookie、Token、JWT)やOAuth(2.0)、OpenID Connectについての解説もあり、これまで知ったかぶっていた分野だったので大変勉強になりました。AuthZ・AuthNについては頭の整理のためにいずれ記事にまとめたいと思います。
以下、知識補完として参考させていただいた記事のリンクです。

qiita.com

qiita.com

www.buildinsider.net

d.hatena.ne.jp

この本が会社の本棚にあった気がする。GW明けに読まねば。

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

参考リンク(※追記)

Auth0のアカウント作成の手順をまとめてくれていますので、ご紹介。 qiita.com