OpenID Connect ​

IDプロバイダーは、複数のアプリケーションへの検証済みアクセスを維持するプロセスを効率化します。 エンドユーザーは、IDプロバイダー（IdP）で認証するだけで済みます。 その後、エンドユーザーは追加の認証情報セットを覚える必要なく、複数のアプリケーションやサービスにアクセスできます。 たとえば、IDプロバイダーはJSON Web Tokens（JWT）を発行し、エンドユーザーがWorkato API platformで認証済みリクエストを実行できるようにします。

API platformは、OpenID Connect仕様を使用してIdPと完全に統合し、クロスドメイン認証を管理します。

IDプロバイダーがエンドユーザーにJWTを発行し、エンドユーザーはそれを使用してWorkato API platformへの検証済みアクセスを取得します

アクセスプロファイルキーのクレーム ​

Workatoが受信リクエストを受け取ると、JWTに有効なトークンが含まれているかどうかが確認されます。 これは、リクエストが有効なアクセスプロファイルから送信されていることを判断するために行われます。 有効なトークン値が見つからない場合、APIリクエストは401 Unauthorizedエラーを返します。

このトークンは、さまざまな方法でJWTに含めることができます。 サポートされているクレームに記載されているデフォルトクレームのリストを含みます。 場合によっては、これらのクレームが他の目的で必要になることがあります。 その場合、このトークンを渡すためにアクセスプロファイルキーのカスタムクレームを指定できます。

アクセスプロファイルの構成方法 ​

Workatoクレームは、ADFS、OneLogin、Oktaなど、ほとんどのIDプロバイダーで機能します。

次の例では、Oktaでアクセスプロファイルを構成する方法を示します。

認可サーバーの構成 ​

Oktaでアプリケーションを作成し、検出URLを取得します:

Workatoアクセスプロファイルの作成 ​

Workatoでアクセスプロファイルを構成し、キーを取得します。

JWTクレームの構成 ​

アクセスプロファイルキーを含めるようにOkta認可サーバーを構成します。

これでセットアップは完了です。 この認可サーバーによって生成されるすべてのトークンが、API platformによって受け入れられ、検証されるようになります。

署名キーのローテーション ​

IdPは、セキュリティ態勢を強化するために署名キーを頻繁にローテーションします。 これは検出URLの内容に自動的に反映されます。 Workatoは、APIトラフィックに中断が発生しないように、署名キーと関連するキーIDを内部的に更新します。