【資料公開】Auth0ハンズオンウェビナー – 拡張編
はじめに
2020年3月に、認証認可プラットフォーム「Auth0」のハンズオンウェビナーを社内向けと社外向け、それぞれ開催しました。特に社内向けではクラスメソッドではAuth0について興味を持つ社員が多く、ウェビナー参加者は2日あわせて70人前後となりました。
社外向けのAuth0ハンズオンセミナーは毎月開催していますが、今回はウェビナー用に新規に作り直しました。以前よりも少しハードルを上げた構成としましたが、ほとんどの方が付いてこれた様子で、結果としてはいい感じの難易度設定となりました。
オンサイトでのイベントが規制されている昨今ですので Auth0に興味のある方々が、本資料を元にウェビナーを開催できたらいいな と言う想いで、ウェビナー資料を解説付きで公開したいと思います。ぜひ参考にしてみてください。
ウェビナーは 基本編 と 拡張編 の2部構成（各1時間）にしました。ちょっとずつやるも良し、まとめて一気にやってみるのも良しです。段階的に学んでいける内容になっていますので、ぜひ手を動かしながらお読みいただけると幸いです。
本記事では、拡張編を解説していきます。基本編は以下を参照してください。
ウェビナー資料
ウェビナー資料はSpeaker Deckにアップロードしました。あわせてご覧ください。
6. User Account Linking
User Account LinkingはConnectionの異なるユーザー同士を名寄せすることができる機能です。
Webサービスを利用する上では 「はじめにGoogleでログインしたけど、2回目はFacebookでログインしてしまった」 みたいなケースはよくある話かと思います。または、あとからログイン手段を増やす目的で、ログイン方法の設定を追加するなども必要な場面も出てきます。そのような場合に有効なのがUser Account Linkingを使った名寄せです。
名寄せと一言で言っても、その方法は様々です。サーバー側で行うのか、またはユーザーに手作業で行わせるのかなど、いくつかの提供方法が考えられます。Auth0では様々な手段に対応しています。
- ユーザー自身に連携を設定してもらう
- Ruleを使ってメールアドレスで自動名寄せする
- 管理者側またはシステムで独自に名寄せする
これらを実現するのはAuth0 Management APIのLink a user account APIです。ユーザーの認証情報を使って呼び出す方法と、M2M認証情報を使って呼び出す方法、2種類の方法が用意されています。
このうち、2番目の Ruleを使ってメールアドレスで自動名寄せする はRuleのテンプレートを設定するだけで適用できるようになっています。Access Control の Link Accounts with Same Email Address を選び、Ruleを新規作成するだけで済みます。
基本編で作成したサンプルアプリケーションで試すことができます。以下の手順を踏みます。
- まずログイン中の場合はログアウトする
- Gmailのメールアドレスで新規登録、ログインする
- Gmail宛に「確認メール」が届いているので、本文内のリンクにアクセスして許可する
- ログアウトする
- 2のGoogleアカウントで「Sign in with Google」でログインする
- GmailでログインしたユーザーとGoogleアカウントでログインしたユーザーが名寄せされている
Auth0のDashboardの Users & Roles の Users で対象のユーザーの詳細を開き、 Identity Provider Attributes の identities を確認してみると名寄せされていることが分かります。
以下のような状態になります。
[
{
"provider": "google-oauth2",
"user_id": "xxxxxxxxxxxxxxxxxxxx",
"connection": "google-oauth2",
"isSocial": true
},
{
"profileData": {
"email": "xxxxxxxxxxxxxxxxxxxx@classmethod.jp",
"email_verified": true
},
"user_id": "xxxxxxxxxxxxxxxxxxxx",
"provider": "auth0",
"connection": "Username-Password-Authentication",
"isSocial": false
}
]
7. ロールごとのアクセス制御 (RBAC)
ロールごとのアクセス制御 (RBAC) は、Auth0上でロールおよび権限（パーミッション）を管理することができる機能です。Auth0にログインしたユーザーにロールを付け、そのロールに割り当てられた権限をアクセストークンに付与できます。
Auth0ではアクセストークンに権限を付与しますが、実際にユーザーのリクエストを弾くのはリソースサーバー側の実装で行う形になります。Auth0から得られたアクセストークンを使ってリソースサーバーにアクセスし、リソースサーバーがアクセストークン内の権限を確認する流れになります。
Auth0でロール・権限を管理し、リソースサーバーで活用する手順は以下の記事を参考に試してみてください。
jwt.io はJWTトークンの内容を調べるために必須ツールです。実装する際はこちらで確認するようにしましょう。
8. Custom Database
Custom Databaseは 実際のログイン処理などをJavaScriptで自由に記述できる機能 です。認証基盤の表側はOpenID ConnectやOAuth 2.0といった規格で受け付けつつ、実際のログイン処理は独自コードとすることができます。
この機能を使うと、例えば すでに稼働済みのレガシーなログイン機能を持つシステムでも、OpenID ConnectやOAuth 2.0にラップすることができます。
OpenID ConnectやOAuth 2.0が普及する前は、独自の仕様で実装されたモジュールを使って構築されたシステムも少なくないと思います。そのようなシステムでも、大きな改修をすることなく、Custom Databaseを使うことでAuth0で保護することができるというわけです。
Custom Databaseを試すには、Auth0 Dashboardから Connections の Database を選び、CREATE DB CONNECTION をクリックします。データベースの名前を決めるだけでかんたんに作成できます。
作成後、 Custom Database のタブを開き Use my own database のフリップをONにします。
ONにすると、コードを編集できるようになります。ここでは好きなAPIを呼び出すこともできますし、直接外部のデータベースにアクセスすることもできます。何れにせよ、接続先はパブリックにアクセス可能である必要があります。
例えば以下のようなコードにすると、ハードコーディングされたメールアドレスとパスワードでしかログインできなくなります。
function login(email, password, callback) {
if (email === 'example@example.com' && password === 'Passw0rd!') {
callback(null, {
user_id: email,
email
});
}
callback('メールアドレスまたはパスワードが違います');
}
なお Custom DatabaseはEnterprise Planでのみ運用が可能な機能 になっています。試すことはできますが、実運用を考えている場合はEnterprise Planの契約をお願いいたします（クラスメソッド経由でお得に契約できるサービスもありますよ！）。
9. YAML Import/Export
Auth0のテナント設定は YAMLファイルとしてインポート・エクスポートすることができます。
なお、全てがYAMLファイル内に書き出されるわけではなく、RuleやCustom Databaseに設定したJavaScriptコードはJavaScriptファイルとして書き出されますし、ユニバーサルログインやメールのテンプレートはHTMLファイルとして書き出されます。つまりそれぞれの言語に合わせたファイルとして書き出れるということです。デベロッパーにとっては嬉しい機能です。
インポート・エクスポートは Auth0 Deploy CLI という専用のCLIツールを使って行います。CLIから実行できますので、例えばCircleCIやCodeBuildなどといったCI/CDサービスとの連携もしやすいです。また、エクスポートによってAuth0のテナント情報が忠実に再現されるので、運用の途中からコード管理にすることも容易です。
テナント設定のインポート・エクスポートは以下の記事にまとめていますので、参考にしてみてください。
10. AD/LDAP Connector
Auth0はEnterprise向けの機能として、Active Directory連携を行うことができます。既存のActive DirectoryがインストールされたWindowsマシンに AD/LDAP Connector と呼ばれる専用のソフトをインストールすることで、バックエンドをActive Directoryとした認証基盤を構築できます。
AD/LDAP Connectorをインストール後はWebアプリ上でActive Directoryの設定を行います。設定を行うとAuth0のテナントと自動的に接続し、ログイン実行時にActive Directoryに照会しにいくようになります。
AD/LDAP Connectorのハンズオンは時間をかなり取ってしまうのでウェビナーでは構築済みのデモのみを紹介しました。Active DirectoryとAuth0の連携を試したい場合は、以下のドキュメントを参考にしてみてください。WindowsサーバーをEC2インスタンスで構築して試してみましたが、以下の手順で問題なく試すことができました。
まとめ
拡張編では、Auth0の特徴的な機能をそれぞれ個別に解説しました。逆引き的に、使いたい機能のところをチェックしていただければと思います。
Auth0の良いところは、基本的な機能はシンプルに洗練されつつも、様々な機能を追加することによって柔軟に拡張できるところです。Auth0が基本、あるいは標準として提供している機能のルールに要件を沿わせながら、足りないところを補強する形で機能を追加すると良いでしょう。サービスは日々進化していきますので、サービスの基本的な考え方やコンセプトのレールに沿って利用する形が最も恩恵を受けられると思います。
拡張編で紹介した機能は、Auth0の持つ数多くの機能の一部でしかありません。本資料で興味が湧きましたら、他にはどのような機能があるか、ぜひ調べてみていただければと思います。
本記事はウェビナーが開催できるような資料の公開が目的ですが、ウェビナーならずともぜひ試していただけると幸いです。
![2024年版「基本的なウェブアプリケーションを構築する」のチュートリアル手順まとめてみた[Amplify Gen2対応]](https://devio2023-media.developers.io/wp-content/uploads/2024/06/000_basic_web_app.png)
