はじめてのOkta Workflows 第8回 アプリケーション連携を広く深く - API Connectorの活用 -

Okta Workflowsとアプリケーションとの連携を汎用的にサポートする「API Connector」について、その活用方法をご紹介します。API Connectorにより、Okta Workflowsに用意されたテンプレートの枠を越えて、多くのアプリケーションの機能をきめ細かくとりこむことが可能となります。

Okta Workflowsのアプリケーション連携

Okta Workflows の最大の特長は、アイデンティティ管理運用の枠を越えて多くのアプリケーションの機能をさまざまとりこめるところにあり、ノーコードでの設定を可能にするテンプレートであるコネクターが、個別アプリケーション毎に豊富に用意されています。例えば、以下のようなアプリケーション操作の自動実行が簡単に設定できます。

• Excel Online（Microsoft 365）やGoogleスプレッドシートの、ワークシート上で指定したセルの読み出し／書き込み
• Box、Googleドライブ、OneDriveにフォルダを新規作成し、指定したファイルをアップロード
• ServiceNowやJira上にインシデントを登録

また、あるアプリケーションから取得した値を加工し別のアプリケーションの操作の入力に用いることで、複数のアプリケーション間を結合することができます。このことから、Okta Workflowsはマルチアプリケーション自動化プラットフォームととらえることができます。

個別のテンプレートが用意されているOkta Workflows対応アプリケーションは以下から確認することができます。

https://www.okta.com/integrations/?capability=workflows-connectors

(Okta Integration Network、左側メニューより[Functionality]-[Workflows Connectors]を選択)

Okta Workflowsのアプリケーションのコネクターは以下で構成されます。

• アクションカード

アプリケーションへの操作を行うカードで、操作毎に個別のカードが用意されています。フロー上に複数のアクションカードが配置可能です。

• イベントカード

アプリケーションでの何らかの動作をフローの開始の契機とする場合に用いるカードで、対象となるアプリケーションの動作毎に個別のカードが用意されています。フロー上の冒頭部分にひとつだけ配置可能です。イベントカードは限られたアプリケーションにのみ用意されています。

• コネクション

アクションカードとイベントカードによりOkta Workflowsから当該のアプリケーションと接続・通信するための認証・認可情報、アクセス先ドメイン/URL等の情報を保持したエントリです。それぞれのアクションカードとイベントカード上では、定義済みのコネクションがひとつだけ選択されている状態である必要があります。

とくに活用の中心となるのはアクションカードです。アクションカードでは、個別のアプリケーションにおける典型的な操作が多数定義されており、自由度の大きいアプリケーション操作が可能になっています。

アプリケーション連携の幅を大きく広げるAPI Connector

さらにOkta Workflowsでは、用意されている個別テンプレート（アクションカード）の使い方の範囲を越え、より広範囲なアプリケーションに対応あるいは多様な使い方を可能にするアクションカード「API Connector」があります。

API Connectorは、各アプリケーションが備えるREST APIに直接アクセスする動作を定義し実行できます。昨今のアプリケーションはクラウドであれオンプレミス展開のパッケージであれ、REST APIを備えているものが多くを占めます。Okta WorkflowsはこのAPI Connectorによって直接それらのアプリケーションと連携をすることができ、連携の幅が格段に広がります。

次にAPI Connectorの代表的なユースケースを3つ挙げます。とくにアクションカードに着目すると、プリビルドのOkta Workflowsとあわせて以下の図のような関係となります。

ユースケース1: Okta Workflowsコネクターが用意されていないアプリケーションの操作

新しいクラウドサービスであったり、その他の理由でOkta Workflowsで個別に対応したアプリケーションのコネクターがない場合に、API Connectorで対応することができます。
また、独自に構築したアプリケーションや、オンプレミスで展開され運用されるパッケージアプリケーションなどに対して、アイデンティティ管理から一般的なアプリケーション操作まで含めて、対応できます。
アプリケーションは、REST APIに対応していること、インターネット上のOkta Workflowsからアクセス可能であることが条件となります。

ユースケース2: 
Okta WICプロビジョニング未対応アプリケーションのプロビジョニング

Okta WICが、個々のアプリケーションそれぞれにシングルサインオン認証（認証フェデレーション）をはじめとした連携対応する仕組みを用意するOkta Integration Network（OIN）では、プロビジョニングにおいてもすでにすでに700を越えるアプリケーションとの連携設定が用意されています。アプリケーション側にカスタムで追加したライセンスやプロファイル、ロール等を自動的に読み込み紐付けたユーザーの追加変更を自動的に行うなど、アプリケーションそれぞれの特性に応じた高度なプロビジョニングを容易に行うことができます（Lifecycle Management機能）。

それでもまだプロビジョニングの個別設定が用意されていないアプリケーションについては、Okta WICとシングルサインオン連携までは行えるもののユーザーをアプリケーション上に追加作成する作業が管理者の手作業として発生してしまうことがあります。

アプリケーションがREST APIを通じたユーザーの作成、読み出し、更新、削除/無効化に対応している場合に、Okta WorkflowsのAPI Connectorを通じてOkta WICのディレクトリ上のユーザーをアプリケーションに追加・変更などすることが可能です。Okta Workflowsフローとして定義し自動化することで、新たなアプリケーションへのプロビジョニング機能を追加することができます。

ユースケース3: 
Okta Workflowsコネクターの対応範囲を超えるようなアプリケーション操作

アクションカードで提供されている範囲外の操作をアプリケーションに対して行う場合には、前回の「はじめてのOkta Workflowsシリーズ第6回」で紹介したCustom API Actionによってあらたにアクションを定義することができます。

それでも、目的とするアプリケーション操作に対応できない場合があります。主な例として、Okta Workflowsコネクターのコネクションで定義されているOAuthの認可のスコープを越える範囲の権限が必要な操作があります。

コネクションではOAuthの認可のスコープのセットが決まっており、アプリケーションのAPI上でアクセス可能な認可範囲が固定されています。現状では任意にスコープを追加することができません。例えば、Google Workspace（全般）に対するコネクションであらかじめ組み入れられているのは以下の表の通りです。

「Google Workspace」コネクションで定義されているOAuthスコープ

• モバイル デバイスのメタデータの表示と管理

https://www.googleapis.com/auth/admin.directory.device.mobile

• ドメインのグループのプロビジョニングの表示と管理

https://www.googleapis.com/auth/admin.directory.group

• ドメインの組織部門の表示と管理

https://www.googleapis.com/auth/admin.directory.orgunit

• ドメインのユーザーのプロビジョニングの表示と管理

https://www.googleapis.com/auth/admin.directory.user

• ドメイン上のユーザーのデータ アクセス権の管理

https://www.googleapis.com/auth/admin.directory.user.security

• G Suite グループの設定を表示して管理

https://www.googleapis.com/auth/apps.groups.settings

• ドメインの G Suite ライセンスを表示して管理

https://www.googleapis.com/auth/apps.licensing

例えばユーザーに「特定の組織部門（OU）を管理範囲として指定する管理者ロールを割り当てる」という操作を行いたい場合には、以下のOAuthスコープが割り当てられている必要があります。

• ドメインの委任管理者の役割の管理

https://www.googleapis.com/auth/admin.directory.rolemanagement

このOAuthスコープは前述のGoogle Workspace（全般）のコネクションには含まれていません※。そのため、あらたにAPI Connectorで上記のOAuthスコープを含むGoogle Workspaceへの接続のためのコネクションを定義した上で、そのコネクションを用いるアクションカードによって実施することで実現します。

※註：2024年6月現在、上記OAuthスコープはGoogle Workspace（全般）のコネクションに含まれるように変更されています。

API Connectorを設定するには

アプリケーション毎に用意されたコネクターは、Okta Workflowsがアプリケーションと連携するにあたって必要な要素が用意されており、最小限の設定で容易に動作するようになっています。

対してAPI Connectorは、RESTful APIへのアクセスによる直接の操作を行うための構成・設定する作業を自ら行わないといけません。事前の情報収集、テストと修正の繰り返しなどがある程度必要になってきます。本項目の最後に、実際の情報収集の例を紹介します。

API Connectorでは、アクションカード、コネクションがありますが、イベントカードはありません。

API Connectorアクションカード

API Connectorアクションカードは、API Connector利用の中心で、カードひとつで1回のAPIアクセスを行います。RESTful APIへのアクセスを定義するために、以下の情報を必要とします。これらの情報は一般的にアプリケーションのドキュメントとして提供されているAPIリファレンスマニュアルで目的の動作に照らし合わせて特定します。

• HTTPメソッド

 GET、PUT、POST、PATCH、DELETEが定義できます。特殊な用途としてCLOSEメソッドも用意されています。

• URL

 APIエンドポイントで、通常「https://」で始まる文字列です。ただし、末尾の「?name=something-urgent&s=keyword」などは次のQueryで別途定義します。

• Query 

URLに付加するクエリ部分です。「{"name":"something-urgent"}」のように記述します。

• Headers

HTTPリクエストヘッダに含める要素です。「{"Content-type":"application/json"}」のように記述します。ただし、認証・認可に関わる要素（APIキーを格納するAuthorizationヘッダなど）は、API Connectorコネクションに設定します。

• Body

HTTPリクエストボディに含めるコンテンツです。GET以外のメソッドで含まれます。

以下がAPI Connectorアクションカードです。HTTPメソッドについてはカード作成開始時に指定する形になります。また、アクションカード上で設定済みのAPI Connectorコネクションを選択するか新たにコネクションを定義できるようになっています。

API Connectorコネクション

API Connectorのコネクションは、APIアクセスに必要な認証・認可情報を保持します。多くの場合用いられるのは以下の2つで、これらのいずれかで多くのアプリケーションのAPIに向けたコネクションの設定がカバーできます。

• OAuth

OAuth2.0をベースとした認可で、ほぼ全てにおいて認可設定の完了の前段階で特定のユーザー（管理者やサービスアカウント）の認証が求められます。

OAuthの認可を用いたコネクションの詳細については、次回「はじめてのOkta Workflowsシリーズ第9回」でカバーします。

• Custom

HTTPヘッダに特定のAPIキー（APIトークン）などを含める場合に用います。

アプリケーションコネクターのコネクションは対象のアプリケーションの認証・認可に必要な個別のURL対象アプリケーションのテナント／ドメイン毎に、さらには同一のテナント／ドメインに対しても認可の使い分けによって複数定義されます。

API Connector を設定するための情報収集

API Connectorの利用においては、「このアプリケーションからこの出力を得たい」、「このアプリケーションにこの入力をしたい」といった目的に沿うようにアクションカードを定義し実行できるように、RESTful APIアクセスについての情報収集が必要です。

アプリケーションの例としてOkta WICに向けてのAPI Connector作成のための情報収集をすることとします。Okta WorkflowsはOkta WICに付随する一機能ではありますが、Okta WICは他のアプリケーションと同じ、操作対象の外部アプリケーションであると整理することができます。Okta WICに対しては本来は専用のアプリケーションコネクターを用いるものであることにご留意ください。

まず、対象アプリケーションであるOkta WICのAPIリファレンス文書にあたるものを特定しましょう。調べた結果、以下であることがわかります。

https://developer.okta.com/docs/api/

目的の操作が「ある特定のデバイスをアクティブ化したい」であるとします。「device activate」などと考えられるキーワードをもとに、検索機能があれば検索し、あるいはリファレンスのメニューに見当をつけながらたどっていくなどします。

このAPIリファレンスで検索に「device activate」と入力すると即座に当該の項目がサジェストされます。

また、見当をつけてメニューをたどってみた結果、[> Okta Admin Management] - [Devices] - [Activate a Device]を見つけることができました。

https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Device/#tag/Device/operation/activateDevice

ドキュメントのコンテンツを読み進めることになりますが、もし簡単に済ませたい場合にはリクエスト生成のサンプルコードが利用できればそれを参考にします。サンプルコードにはAPIアクセスに必要なリクエストの構成の最低限の要素がわかりやすく含まれています。とくにcurlコマンドのサンプルであれば要素が把握しやすく有用です。

デバイスのアクティブ化のcurlコマンドサンプルコードは以下です。

ここから、HTTPメソッドは「POST」、URLは「https://subdomain.okta.com/api/v1/devices/{deviceId}/lifecycle/activate」、ヘッダは「Authorization: YOUR_API_KEY_HERE」であることがわかります。

ここで、URLの「subdomain」は自分のOkta WICのものに置き換えるとして、「{deviceId}」は未知であるので、あらためて [> Okta Admin Management] - [Devices] - [List all Devices] などでデバイスIDの情報を取得し抽出し用意するなどを別途検討します。

また、「Authorization: YOUR_API_KEY_HERE」は認証・認可の情報であるので、アクションカードのHeadersに配置するのではなくコネクションのCustomで設定します。

API Connectorによる連携：ChatGPT APIを用いたサンプルID生成
<前編>アプリケーションへの接続と取得データの検証

本項では、REST APIを提供する一般的なアプリケーションの機能をOkta Workflowsから利用し、Okta WIC本体やその他アプリケーションまで派生する連携を想定し、ChatGPT API （https://platform.openai.com/）を例に説明します。

ChatGPT APIでは、対話型AIを提供するアプリケーション ChatGPT（ https://chatgpt.com/）の機能をREST APIを通じて利用することができるアプリケーションです。

ChatGPT APIの機能をOkta Workflowsから活用するためのユースケースとして、ここでは「それらしい架空のユーザーをまとまった人数分生成し、Okta WICのディレクトリに登録する」こととします。実運用上は有用性はないですが、Proof of Conceptの実施や、Okta WICをデモンストレーションする際の環境作りといった場合に役立つかもしれません。

またChatGPT APIは、ベアラートークンを用いたREST APIへのアクセスの認可を行うアプリケーションの例となります。アプリケーションから取得したベアラートークンはHTTPヘッダに設定されることで、APIアクセスにおける認可を行います。

*ChatGPT APIは、API keyによるベアラートークンでの認可に加えて、OAuthによる認可も可能です。また、Okta WorkflowsにはすでにChatGPT APIのためのコネクションとして「OpenAI」が用意されています（API keyを利用）。

アプリケーションからのベアラートークンの取得とAPI Connectorコネクションの設定

Chat GPT APIのREST APIへのアクセス時の認可は、ベアラートークン（Bearer token）方式です。

1. Chat GPT APIのベアラートークン「API Key」の取得

Chat GPT APIの管理コンソールにログインします。

https://platform.openai.com/

Chat GPT APIでは「Project」の単位でAPI利用を管理します。初期設定ではすでに最初のProjectであるDefault Projectがつくられています。ここに、Okta Workflows連携の用途のProjectを追加します。

左上の[Default Project]から[Projects] -> [Create project] とたどりクリックします。

Projectに任意の名前をつけます。ここでは「Okta Workflows Test」とします。

画面左のメニュー[API Keys] -> 画面右上[+ Create new secret key] -> なにも変更せず[Create secret key]をクリックします。

API key（ベアラートークン）が生成されます。[Copy]をクリックしてクリップボードにコピーし、[Done]をクリックして完了します。この後、このAPI keyの値を再度取得することはできないので、ご注意ください。

2. Okta Workflows API Connectorコネクションへの設定

Okta Workflowsコンソールにログインします。

上のメニュー[Connections] -> [+New Connection]  -> [New Connection]の一覧から[API Connector]を選択します。

[Name]にこのコネクションの任意の名前 (ここでは「ChatGPT API」)を入力、[Auth Type]より[Custom]を選択します。

[Header Name]は「Authorization」、[Header Value]は前項で生成したChatpGPT APIのAPI Keyをペーストし、[Create] をクリックして完了します。

*API Connectorコネクションでベアラートークンを設定する場合、そのHTTPヘッダ設定のみが定義されます。アプリケーションの種類やドメイン、URLなどは定義されません。

アプリケーションからの取得データ取得の確定

まずAPI Connectorコネクションとアクションカードで接続・操作する対象であるChatGPT API から意図通りのデータを適切に取得するための手順を確立します。

ここでは、ChatGPT APIの最もポピュラーな機能である「Text generation」に対してプロンプトを送り込んで架空の複数のユーザーを生成し、以下のようなフォーマットのオブジェクトのリストを取得することをゴールとします。

”lastNameKanji”、”firstNameKanji”、”firstName”、”lastName”の4つのキーを持つJSONオブジェクトのリストで、これによりユーザーの姓名の日本語表記、英語表記をそれぞれ取得します。「lastNameKanji」、「firstNameKanji」というキーは、そのままカスタム属性としてOkta WICのディレクトリのProfile Editorで追加したStrings属性に対応させ、日本語の姓名として保持できるようにします。

はじめに、アプリケーションへのAPIでの入力について、しかるべきドキュメントを参照して把握します。

https://platform.openai.com/docs/api-reference/making-requests
https://platform.openai.com/docs/guides/text-generation

これを通じ、「Chat Completions API」エンドポイントである下記URL https://api.openai.com/v1/chat/completions に以下のようなフォーマットのオブジェクトを入力すればいいと分かります。

実際にOkta Workflowsのフローを利用して下記のようなChatGPT APIのChat Completions APIをテストし、どのような形でデータが返されるかをみてみます。

Chat Completions APIに入力するプロンプトをCompseカードに保持します。

Systemに渡すプロンプトは、望むデータ形式を取り出せるように指示します。

userに渡すプロンプトは、生成ユーザーの内容、JSONオブジェクトのフォーマットを指示します。

これらをフォーマットにまとめ、API Connectorアクションカードを通じてChatGPT APIのChat Completions APIに入力します。

API Connectorアクションカードでは、前項で作成したAPI Connectorコネクションを指定しています。

上記のフローを「Run」で実行した後、「Execution History」からAPI Connectorアクションカードのレスポンス部分をみると、以下のようなデータが返されていることが分かりました。

註：2024年6月時点、ChatGPT API に無料で利用可能なクレジット（時期により最大5米ドルまたは最大18米ドル）の範囲でモデルgpt-4oでAPIアクセスすると、HTTPステータスコード404のエラーが返されます。また、gpt-4o、gpt-3.5-turboなどのモデルにかかわらず、利用可能なクレジットがない状態でAPIアクセスすると、HTTPステータスコード429のエラーが返されます。またChatGPT APIのクレジットの購入とChatGPTの有料サブスクリプションとは関係がないことにご留意ください。

このデータを、Okta Workflowsで順次処理可能なようにオブジェクトのリストとしてのJSONフォーマットに成形する方針をたてます。そのようにして得たデータを元に、Okta WICのユーザーディレクトリにユーザーを作成していくフローをつくることとします。

API Connectorによる連携：ChatGPT APIを用いたサンプルID生成
<後編>フローの定義

前項において、ChatGPT APIからどのようなフォーマットでデータすなわちREST APIにおけるHTML Bodyが返されるか確認できました。

続いて本稿では実際にChatGPT APIで得た架空のユーザーがOkta WIC上にプロビジョニングされるようなフローを構築します。

大まかな流れは以下の通りです。

• ChatGPT APIに架空のユーザーの生成を要求するプロンプトを送り、結果を取得
• 取得したデータから有効な部分を抽出しオブジェクトのリストのJSONフォーマットに整形
• リストをもとにOkta WIC上にユーザーをプロビジョニング

全体のフローは1つの主フロー、1つのHelperフローから構成されます。

主フロー：前項で設定したコネクションをつかうAPI Connectorアクションカードを利用し、架空のユーザー群をChatGPT APIを通じて生成し取得したデータをJSONオブジェクトのリストに整形する。各オブジェクトを順繰りにHelperフローに処理させる。

Helperフロー：主フローから受け取ったユーザーのオブジェクトをもとに、Okta WICのユーザーディレクトリ上にユーザー作成する。

Okta WICにはOktaデフォルトユーザーのプロファイルにカスタム属性をあらかじめ定義しておきます。以下の属性を定義しておいてください。

管理コンソールより[ディレクトリ(Directory)] - [Profile Editor] - [ユーザー(Users)] - [ユーザー (デフォルト)(User(Default))]

主フロー：ChatGPT APIからのデータ取得からHelperフローの呼び出しまで

フローの構成の概観（Flow Chart）です。

イベントカードは特になんでも構わないので、ここではいったん「Delegated Flow」カードを置いています。

まず、ChatGPTにおけるSystemロールとUserロールに送るプロンプトをいったんComposeカードに記述します。これらのプロンプトはChatGPTを利用する上での特性を念頭におきながら前編にてテストをある程度繰り返し、調整した結果のものです。

次に、REST APIに送信するBodyを整形します。要素として、先のプロンプトを保持している「Compose」カード2つを組み込んでいます。そしてそのBodyをChatGPT APIのAPIエンドポイントにHTTP POSTで送信します。

ChatGPT APIのREST APIに対するAPI Connectorアクションカードの設定は、前編ですでにテストしたものをそのまま流用します。

ChatGPT APIから返されたデータから必要なデータを抽出し、オブジェクトのリストのJSONフォーマットに整形します。

前編のテストにて、どのような形でデータが返されるかを確認していますので、そのデータをしかるべき形になるように操作します。

まず元データのchoices.0.message.content階層に目的のデータが位置していますので、「Get」でその階層の値を抽出します。

抽出後のデータに対し、文字列の調整（文字列の置換・削除）を「Replace Patterns」カードで行っています。ChatGPT APIの出力には揺らぎがあるため、ここでは出力毎の差分を吸収するような形にしています。結果としてこのカードの操作が不要な場合もあります。

最後に、「Parse」カードにて、テキストデータであったものをJSONフォーマットのオブジェクトのリストに換えます。

これで、架空のユーザーのリストが得られましたので、最後にHelperフローが担当する順繰りの操作に回します。「(List)For Each」カードで、対象のリストとして生成したオブジェクトのリストを指定し、次項のHelperフローで処理するようにします。

Helperフロー：リストのユーザーデータをOkta WICにプロビジョニング

フローの構成の概観(Flow Chart)です。

主フローから渡されたデータの中の要素を「(Object)Get Multiple」カードで抽出します。対象となる英字の名、姓(firstName、lastName）、漢字の名、姓(firstNameKanji、lastNameKanji)は、ChatGPT APIへのプロンプトにて指定したとおりです。

lastName、firstNameを用いて、「(Text)Compose」および「(Text)To Lower Case」でメールアドレスを生成します。このメールアドレスはユーザー名(Username)としても用います。

最後に、「(Okta)Create User」カードで、このユーザーをOkta WIC上に作成します。初期設定の必要属性であるUsername、First name、Last name、Primary emailに加え、あらかじめFirst Name Kanji、Last Name Kanjiというカスタム属性がOkta WIC上に設定してある前提です。また、ChatGPT API由来の架空のユーザーであることが区別できるように、Generated with ChatGPTというブール値のカスタム属性にTrueを格納しています。これにより、Okta WIC上でのこれらのユーザーの一斉削除やグループ割り当てが容易になります。

フローの実行

それでは実際にフローを実行してみましょう。

主フロー、Helperフローともに「ON」の状態であることを確認し、主フローの画面で右上の「Run」をクリックします。自動的にExcecution Historyの画面に切り替わり、主フロー序の各アクションカードが順次実行されていくのがわかります。

Helperフローの実行結果は、Helperフローの画面でExcecution Historyから見ることができます。10オブジェクト（10人の架空ユーザー）の処理を行っているので、全て成功していれば10回分の処理が完了していることが画面右側のペイン上の各履歴からわかります。それらをクリックすることで事後的にそれぞれの処理内容を確認することができます。

Okta WICの管理コンソールを開いて、[ディレクトリ(Directory)] - [ユーザー(People)]よりユーザーが意図通り作成されていることを確認します。

ユーザー個別のプロファイルを開いて、さらに内容を確認します。各属性に正しく値がセットされていることがわかります。

サンプル・フローのダウンロード

今回解説したフローは、こちらからFlow folderファイルとしてダウンロードし、Okta Workflowsにインポートすることで試すことができます。ただし、あくまでサンプルですので、動作の保証をするものではなく、フロー全体としての動作やロジックはサポート対象にはなりませんのでご了承ください。

最後に

API Connectorにより、もともと数々のアプリケーションと便利な連携ができるOkta Workflowsに、さらに無限のアプリケーションに対応できる拡張性がもたらされます。前回ご紹介したCustom APIと合わせて、アイデンティティの世界を大きく飛び越え汎用的に利用できるアプリケーション連携プラットフォームとして、Okta Workflowsをご活用ください。

Okta Workflowsシリーズ

• はじめてのOkta Workflowsシリーズ 第１回 Okta Workflowsとは
• はじめてのOkta Workflowsシリーズ 第２回 Hello Workflows編
• はじめてのOkta Workflowsシリーズ 第３回 長期間利用されていないアカウントの洗い出し
• はじめてのOkta Workflowsシリーズ 第４回 日付を指定したユーザーの自動作成と削除
• はじめてのOkta Workflowsシリーズ 第５回 特定の条件に該当するユーザリストの作成とエクスポート
• はじめてのOkta Workflowsシリーズ 第６回 アクションリストにないAPIコマンドの実行
• はじめてのOkta Workflowsシリーズ 第７回 不審なプッシュチャレンジを検出する