こんにちは〜、ころちゃんです。
今週は沖縄から働いてます。ソーキそばうまい！

さて、普段はbosyu.meの開発とCASTER BIZ Recruitingの社内ツールを開発をしていますが、趣味でAuth0というIDaaS（Identity-as-a-Service）のアンバサダーをやっています。

今回はbosyu.meじゃなくて、社内ツールの開発環境にAuth0いれたよ〜という話を紹介します。

もっとレビューを楽にしたい

複数人開発をしていると、他人にレビューをしてもらう機会が多くなります。社内ツールに関わる人が増えてきてレビューが大変になってきました。

プロダクトはエンジニアだけで作っているわけではないので、レビューするために動作確認する環境をイチから整えるのも大変ですし、環境が整っているエンジニアでも、ブランチ切り替えて確認するのは若干ダルい。

もっと簡単にレビューできる仕組みがほしいよね！

Heroku Review Apps

そこで Heroku Review Apps を使うことにしました。

社内ツールにはHerokuを用いており、Heroku Review Appsと呼ばれるPRごとにレビュー環境が立ち上がる仕組みを利用することに決めました。

例えばGitHubで123番のPRを出すと、自動で以下のhoge-dev-123というURLの環境が立ち上がります。

・本番: https://hoge.herokuapp.com/
・開発: https://hoge-dev.herokuapp.com/
・レビュー: https://hoge-dev-123.herokuapp.com/

さっと社内で動作確認してもらうのに非常に便利です！

Google認証との相性の悪さ

しかしHeroku Review AppsはOAuth/OIDCを使った認証との相性が悪いのです。

GSuiteを使っているので社内ツールへのログインはGoogleアカウントを使用した認証で保護しています。Googleの管理画面からOAuth 2.0のクライアントを発行しています。

ここで問題なのですが、一度Google側で認証を通した後、許可されていないURIにはリダイレクトできません。GoogleのOAuth 2.0を直接触る場合、リダイレクトURIを固定値で指定しなければいけないので、今回のような動的にURLが生成される場合に対応できないのです。

これに対応すべくプロキシでやろうとしている方もいました。

　がんばる
→がんばりたくない

はい。

Auth0はリダイレクトURIにWildcardが指定できる

そこで検討したのが Auth0 です。

Auth0をバイパスとして、Google認証を行います。勿論他のProviderを使用することも簡単にできます。

そして今回の最大のポイントなんですが、Auth0はリダイレクトURIにwildcardが使用できるのですよ！wildcardが使えるのはサブドメインのみですが、以下の画像のように hoge-dev-* といった指定もできます。これで動的にURLが生成される環境にも対応できます。

もちろんwildcardを使うと、意図せず別のアプリケーションドメインを許可してしまう可能性があるので注意して使用してください。カスタムドメインと組み合わせると良いでしょう。

レビュー環境の判定

現在はレビュー環境のみでAuth0を使用しています。そのため、アプリケーションがレビュー環境で動作しているかどうか判定する仕組みが必要でした。

Heroku Review Appsには環境変数で判定する仕組みがちゃんと用意されていて、以下の変数がレビュー環境下のみセットされます。

HEROKU_APP_NAME

この変数は https://HEROKU_APP_NAME.herokuapp.com/ の大文字部分に該当する値が入っており、前述したURLの場合 hoge-dev-123 になります。

レビュー環境だけ特殊な動作にする場合は、この変数の有無を見て挙動を変えると良いでしょう。（あんまり分岐させるべきではないけどね）

なお、これらの環境変数を利用するためには、app.jsonで使用でアプリケーションに渡す環境変数の設定が必要です。

{ 
  "name":"Advanced App",
  "scripts":{
    "postdeploy":"rake db:setup && bin/bootstrap"
  },
  "env":{
    "HEROKU_APP_NAME": {
      "required": true
    }
  }
}

詳しくは以下のドキュメントを参考にしてください。

Ruby on Railsの場合

サーバーがあるので、Authorization Code Flowを前提として、omniauth と omniauth-auth0 を使って組み込むと良いと思います。

というかomniauth-auth0、Auth0オフィシャルのGemだったのか・・・ｗ（note書きながら気づいた）

もしAuth0 にガッツリ乗る場合はDeviseやSorceryを入れる必要はありませんし、モデルもスッキリしますね。

そういえばAuth0はHeroku Add-onでも追加できるようですが、私は別で契約して使ってます。

まずは開発環境から導入してみると良さそう

7000ユーザーまで無料で使用できるので、少人数しか開発環境にアクセスしない環境なら余裕で間に合います。

本番環境で運用した場合も、社内ツール程度であれば7000人に余裕で収まる想定なので、今後完全な置き換えを検討しています。

無料プランのユーザー数を超える状態になったら、それだけ事業が伸びてより強固なセキュリティの仕組みも必要となるはずですので、（弊社の場合）その際のコストを加味しても余裕でペイできるかなと。

まとめ

まずは社内ツールだったり開発環境の認証や保護に使っていくと導入しやすいですし、使用感もわかります！非常にかゆいところに手が届くサービスなので激推しくんです！

採用や認証の話をよく呟いているので良かったらフォローしてください！