Auth0でEarly Accessとなった新機能、Forms for Actionsを試してみる
こんにちは、shibamです。
2024年05月07日、Forms for ActionsがEarly Accessとして追加されました。
ざっくりと言えばActionsの途中でフォーム画面を呼び出せるようになり、ユーザへの追加情報の入力依頼やプライバシーポリシーへの同意画面を表示させられるようになりました。
今回は機能の紹介と、Auth0が提供しているテンプレートパターンについて試してみました。
目次
1.TL;DR
- Forms for Actionsは、FormsとFlowsを組み合わせて画面(もしくは一定のフロー)を作成し、Actionsの途中で呼び出すことができるようになる機能
- Formsでは、画面と処理の遷移図をGUIで作成する。また、ここで画面構成を設定できる。
- Flowsでは、Formsで設定した処理の内容を作成する。PowerAutomateのような画面でAPIリクエストなどの処理が実現可能。
2.Forms for Actionsとは
どんなもの?
公式では以下のように解説しています。
Build customizable forms with our drag & drop editor and extend your identity flows with additional steps and business logic.
ざっくり日本語訳すれば、「カスタマイズ可能な画面をドラッグ&ドロップで編集・ビルドし、認証フローに追加のステップやビジネスロジックを拡張します」という感じでしょうか。
これまでは、認証フローに対して追加の情報入力を要求するためには、外部に資材を配置しそこで情報を入力させる必要がありました。
これをAuth0の内部で実現しよう、というのがForms for Actionsの考え方であり、これによってAuth0のみで実現できる内容が大幅に増加しました。
Forms for Actionsの持つ機能
Forms for Actionsは、”Forms”と”Flows”の2つの機能を持ち、これらを組み合わせることで認証フローに追加機能を実装していきます。
それぞれのもつ機能の詳細については後述しますが、”Forms”で画面を、”Flows”でビジネスロジックを作ると考えれば概ね間違いないです。
これらを組み合わせて完成したFormを、従来のActionsの過程で呼び出すことで処理を実施します。
注意点:いくつかの制約について
Auth0の公式に、以下のような制約が記載されています。
- You cannot redirect a user and render a form in the same Action. If you need to use both, consider using different Actions.
―同一Action内で、リダイレクトとフォームのレンダリングを行うことはできません。両方を行いたい場合は、異なるActionsを利用することを検討してください。- You can only render one form per Action. If you need to render more than one form, you need to render the forms in different Actions.
―1つのActionでレンダリング可能なフォームは1つのみです。もし複数のフォームをレンダリングしたいのであれば、異なるActionsを利用することを検討してください。- The same form can not be rendered more than once across the same trigger. For example, if you have a post-login trigger with two Actions, you can not render the same form in both Actions, you need to create different Forms for each Action.
―同一trigger内で、同じフォームを別のActionsで呼び出すことはできません。(例:Post-Loginトリガー内の2つのActionsで、同一のフォームをレンダリングすることはできない)。必要であれば、各Actionに異なるフォームを作成・レンダリングしてください。- The fields property size limit is 24 KB.
―フィールドプロパティの上限は24KBです。- The api.prompt.render() method is available in the post-login Action triggers.
―api.prompt.render()メソッドは、Post-Loginトリガーでのみ使用可能です。
3.Formsについて
Formsとは?
“Forms”は、画面や後述するFlowsなどを管理し、構築するための機能です。
認証後の追加のステップを、GUIで作成することができます。
NodeとComponent
Formsを理解するためには、まずはNodeとComponentを理解しましょう。
“Node”は、Forms上で処理フローを作成していく中の1つ1つの処理節のことです。以下のようなNodeが存在します。
Node名 | 概要 |
---|---|
Start | 開始節。処理フロー内で共通で使用する変数などを定義できる。 |
Router | 分岐節。条件を満たす処理フローに分岐する。 |
Step | 画面節。ユーザに追加の情報入力を要求するための画面を定義できる |
Flow | 処理節。後述するFlowの実行ポイントを定義できる。 |
Ending screen | 終了節。「そのまま認証フローを完了する」か、「追加で非同期のFlowを呼び出してから完了する」かを選択可能。 |
このうち、”Start”と”Ending screen”に関しては、Formsを作成した段階で初期配置されており、削除できないようになっています。
ですので、”Router”・”Step”・”Flow”の三種類のNodeを組み合わせて処理フローを作成していくのが基本的な流れになります。
Componentは、上記の”Step”Node上で利用する、画面構成用の部品になります。以下のComponentが提供されています。
Component名 | 概要 |
---|---|
Start | 開始節。処理フロー内で共通で使用する変数などを定義できる。 |
Router | 分岐節。条件を満たす処理フローに分岐する。 |
Step | 画面節。ユーザに追加の情報入力を要求するための画面を定義できる |
Flow | 処理節。後述するFlowの実行ポイントを定義できる。 |
Ending screen | 終了節。「そのまま認証フローを完了する」か、「追加で非同期のFlowを呼び出してから完了する」かを選択可能。 |
これらの”Node”と”Component”を組み合わせることによって、1つのFormを完成させていきます。
Formのつくりかた
- スクラッチ/テンプレートのどちらから作成するかを選択
- 作成したFormに対して、Nodeを追加し線でつないでいく
- Step Nodeに対してComponentを追加し、画面を作成する
- RenderタブからFormをレンダリングするためのコードをコピーし、Actionsを作成する
これでFormを呼び出すことができるようになります。
次はFlowを作成していってみましょう。
4.Flowsについて
Flowsとは?
“Flows”は、ビジネスロジック部分を作成するための機能であり、Microsoft PowerAutomateのような操作感で処理フローをGUIで作成することができるようになります。
Flowsのつくりかた
- 同期/非同期を選択する
- 作成されたFlowに処理を追加していく。
- 作成したFlowをForm上で呼び出せば完成!
呼び出し可能な処理について
Flowsにおいては、以下の処理の呼び出しが事前に定義されています。
※Forms for Actionsでは、いくつかの外部機能と連携したFlowの作成が可能となっていますが、ここでは割愛しています。
グループ | Flow名 | 概要 | プラン制約 |
---|---|---|---|
Logic | If/then condition | 条件分岐の作成 | |
Store shared variable | 共通変数への格納 | PRO以上のみ | |
Show error message | エラーメッセージの表示 | ||
Input value mapping | 入力に対してマッピングされた出力を返す | ||
HTTP | HTTP Request | HTTPリクエスト(GET/POST/PUT/PATCH/DELETE)を作成する。 | |
Data verification | Generate one-time password | OTPを生成し、指定された送信先へOTPを送信する | PRO以上のみ |
Verify one-time password | OTPの検証を行う | PRO以上のみ | |
Verify email address | Eメールの送達確認検証を実施する | ||
JWT | Verify JSON web token | JWTの検証を行う | PRO以上のみ |
Sign JSON web token | JWTの署名を行う | PRO以上のみ | |
Decode JSON web token | JWTのデコードを行う | PRO以上のみ | |
Auth0 | Create User | ユーザを作成する | |
Get User | ユーザを取得する | ||
Update User | ユーザを更新する | ||
JSON | Create JSON object | JSONを作成する | |
Parse JSON | JSONをパースする | ||
Convert JSON to String | JSONを文字列に変換する |
5.サンプルケース:プライバシーポリシーの同意画面を追加する
実際に、いくつかのサンプルケースの作成を通してForms for Actionsについて理解を深めていきましょう。
1つ目のサンプルケースでは、ユーザが新規登録後、プライバシーポリシーについて同意する画面を表示する方法について紹介します。
このケースは、既にAuth0がテンプレートを提供しているため、それを利用していきます。
テンプレートの作成
まず、Formsの画面からCreate Formを選択しフォームを作成していきます。
今回は、”Use a Template”を選択していきます。
選択後、いくつかのテンプレート候補が表示されるので、”Custom pollicies acceptance”を選択します
Form名とFlow名については、デフォルトで特に問題ありません。必要であれば好きな名前を入力してください。
Vault(シークレット情報の格納先)の設定を要求されますが、基本的には特に変更せず”Create”で問題ありません。
既にVaultを利用しており、Connectionを指定したい場合は以下のように設定を変更してください。
テンプレートの内容の確認
まずはFormの全体像について。
シンプルな構成ですね!次にFlowです。
こちらもシンプル。どうやら、プライバシーポリシーへの同意が確認できた場合にはuser_metadataを更新することで同意状態を確認する構築のようです。
VaultのReconnect
ここで注意が1つ。上記のFlowの”Update User”を選択すると、以下のようになっています。
Vaultには”REPLACE_WITH_M2M_CONNECTION”が設定されていますが、名前の通りこれはRECCONECTをする必要があります。
ですので、左上のテナント名を選択して表示される”Vault”からVault編集画面に移動し、VaultのRECCONECTを実施してください。
・テナント名をクリックしてVaultを選択
・Auth0を選択
・表示された”RECONNECT_WITH_M2M_CONNECT”の右側にある”…”をクリックして”Reconnect”を選択。
・Reconnect先のTenant domain,Client ID,Client secretを入力し、Reconnectを実施。
(テスト的な実施であれば、API Explorer Applicationで良いかと思います。)
Actionsの設定
FormsのRenderタブを確認し、作成されているコードを使ってActionsを呼び出しましょう。
・ダッシュボードから”Actions” > “Library”を選択し、”Create Action(Build From Scratch)”でActionを作成。
・FormsのRenderタブに表示されていたコードをコピー&ペースト、Deployを実施
・DeployされたActionをPost Login Flow(Actions > Flows > Login)に組み込み、Applyボタンを押下。
これで完了です。
動作確認
一旦動作確認をしてみましょう。
・デフォルトで存在しているDB(Username-Password-Authentication)に対してTry Connectionを実施します。
・適当なアカウントを作成します。
・Continueを押すと、Privacy Policyへの同意画面が表示されるのが確認できます。
良い感じですね。
6.最後に
今回の機能追加によって、Auth0単体での表現力は各段に上がりました
外部サービスに依存せず様々な機能を達成できること、またその実装手順が容易であるのが嬉しいですね。
まだまだやれることも多い機能なので、是非活用していきたいと思います。