Okta Identity Engineリリースノート（プレビュー）

バージョン：2025.04.0

2025年4月

一般利用可能

Secure Identity Integrations

Secure Identity Integrations（SII）は、SSO、SCIM、エンタイトルメント管理、Universal Logout、Workflows、Identity Security Posture Management（ISPM）を含めて、最もよく使用される50個以上のエンタープライズSaaSアプリケーションにさらなる深みを提供します。

Okta Provisioning AgentとSDKの新しいバージョン

Okta Provisioning Agent 2.2.1とOkta Provisioning Agent SDK 2.1.1が利用可能になりました。これらのリリースには、バグ修正と軽微な改善が含まれます。

OINテストアカウント情報は30日後に削除

Oktaでは、OINウィザードでアプリを公開してから30日後にテストアカウントの資格情報を削除します。アプリを送信する前に、新しいテストアカウントを作成し、必要な情報を再入力する必要があります。

エンタイトルメントクレーム

アプリのエンタイトルメントでトークンを強化して、より深い統合を実現できるようになりました。アプリ統合にこの機能を構成した後、Identity EngineのOkta Expression Languageを使用して、実行時にOIDCクレームおよびSAMLアサーションとしてエンタイトルメントを追加します。「フェデレーションクレームを生成する」を参照してください。

アクセスリクエストの新しい外観と操作性

［Access Requests（アクセスリクエスト）］コンソールと［Okta Access Requests（Oktaアクセスリクエスト）］ Webアプリでは、サイドとトップのナビゲーションメニューの再設計やグレー背景の追加など外観と操作性が新しくなりました。また、アクセスリクエストにダークモードが利用できなくなりました。

Okta検証済みテキストをOINから削除

OINカタログでは、アプリ統合ページからOkta検証済みの免責事項が削除されました。

新しいレート制限イベントタイプ

このレート制限イベントタイプ：system.rate_limit.configuration.updateが、System Logに表示されるようになりました。次の内容が記録されます。

  • クライアントベースのレート制限設定の変更
  • レート制限警告通知しきい値の変更
  • レート制限通知が有効か無効か
  • APIトークンのレート制限パーセンテージの更新

条件付きで動的リソースセットを作成する

リソースセットの条件を使用すると、管理者の特定のアプリへのアクセスを除外することで、ロールのスコープを制限できます。これにより、カスタム管理者ロールをより細かく制御できるようになり、org固有のセキュリティニーズを満たすことができます。「リソースセットの条件」を参照してください。

Okta FastPassの同一デバイス登録

Okta FastPassを使用しているorgでは、Okta Verifyの登録プロセスが合理化されました。

  • ユーザーは現在使用しているデバイスで登録を開始して完了できます。以前は、アカウントをセットアップするには2つの異なるデバイスが必要でした。
  • ユーザーは登録時にorgのURLを入力する必要がなくなりました。
  • 登録フローの手順が少なくなりました。この機能は、Android、iOS、macOSデバイスでサポートされています。

パートナー管理者ポータルの継続的アクセス評価

Secure Partner Access Partnerの管理者ポータルでは、継続的アクセス評価が採用され、標準のトークン有効期間に従ってセッショントークンが保護され、トークンの有効期限が切れると再認証がトリガーされるようになりました。

領域のドメイン制限

領域内の特定ドメインにユーザーを制限できるようになり、これにより領域管理者とパートナー管理者の監視が強化され、ユーザー層間の境界が適用されます。「領域を管理する」を参照してください。

早期アクセス

Okta Privileged AccessでActive Directoryアカウントを管理する

この機能により、Okta AD Agentを使用してOkta Privileged Accessを通じてActive Directory（AD）アカウントパスワードを管理できます。管理者は、特定の組織単位（OU）内のアカウントに検出ルールを設定し、ユーザーアクセスのポリシーを作成して、チェックイン時またはスケジュールに従ってパスワードがローテーションされるようにできます。アクセス権を持つユーザーは、割り当てられたアカウントを表示し、パスワードを取得できます。この機能を有効にする場合は、Oktaサポートにお問い合わせください。「Active Directoryアカウントを管理する」を参照してください。

自動ローテーションによるOrg2OrgのOAuth 2.0プロビジョニング

複数orgアーキテクチャ（Oktaハブアンドスポークorgなど）をデプロイする管理者は、ユーザーとグループのプロビジョニングを保護する必要があります。OAuth 2.0スコープのトークンを使用したプロビジョニングには、より詳細なアクセス権限の設定、トークンの短い有効期間、キーの自動ローテーションなど、APIトークンに比べていくつかの利点があります。Admin Consoleから直接、Org2OrgアプリのプロビジョニングにOAuth 2.0の自動ローテーションを有効化できるようになりました。

「Okta Org2OrgをOktaと統合する」を参照してください。

SAP Netweaver ABAP用On-prem Connectorでサポートされる属性の追加

Okta On-prem Connectorでは、サポートされるユーザー属性が追加されて、OktaとSAP Netweaver ABAPとの統合が向上しました。

修正

  • Sign-In Widget（第3世代）でフォントサイズが正しく表示されませんでした。（OKTA-552923）

  • カスタムアプリのロゴがアプリのページに表示されませんでした。（OKTA-655724）

  • この更新では一般的なセキュリティ修正が適用されました。（OKTA-690936）

  • インポートの報告された結果が、インポートの完了時に表示された内容、インポートの概要メール、インポートモニタリングページに表示される値によって異なっていました。（OKTA-739010）

  • Active Directoryからプロファイルをインポートした一部のユーザーは、セルフサービスによるロック解除のメールを受信できず、アカウントを復旧できませんでした。（OKTA-843086）

  • 一部の管理者は、多数の認証ポリシールールがあるorgからAuthenticatorを削除できませんでした。（OKTA-847583）

  • MFA使用状況レポートのMFA要素列に、FIDO2（WebAuthn）Authenticatorの名前Windows Hello（Web認証）が表示されていました。

    （OKTA-848611）

  • Classic Engineで登録インラインフックがあるorgは、Identity Engineにアップグレードした後、登録インラインフックを非アクティブ化できませんでした。（OKTA-855960）

  • ［Settings（設定）］［API］メニューが、表示する権限のない一部の管理者に表示されていました。（OKTA-856337）

  • ［Authentication policies（認証ポリシー）］ページのページネーション制御と［Show more（表示を増やす）］が正しく機能しませんでした。（OKTA-858605）

  • 一部のネットワーク関連のuser.session.context.changeイベントでリスクレベルがLOWでした。（OKTA-863401）

  • エンドユーザーの［Settings（設定）］ページの［Recent activity（最近のアクティビティ）］タブで、テーブルが正しく表示されませんでした。（OKTA-874276）

  • ウィンドウのサイズが変更されると、エンドユーザーの［Settings（設定）］ページでテキストが正しく表示されませんでした。（OKTA-874292）

  • スクリーンリーダーは、エンドユーザーの［Settings（設定）］ページで［Select language（言語の選択）］ドロップダウンメニューにある言語名を読み取れませんでした。（OKTA-874318）

  • 管理者は、FIDO2（WebAuthn）AuthenticatorをAuthenticatorグループに追加できませんでした。（OKTA-875920）

  • 複数のユーザータイプを使用する管理者に、アプリインスタンスを更新しようとすると内部エラーが発生することがありました。（OKTA-880825）

  • インポートモニタリングページが、必要な権限を持たない管理者に表示可能でした。ページにアクセスすると403エラーが発生しました。（OKTA-880835）

  • Google Workspaceへのグループプッシュを実行すると、nullポインター例外のエラーが発生することがありました。（OKTA-886861）

  • user.risk.detectイベントが、［エンティティリスクポリシー］ページで誤って表示されていました。（OKTA-887297）

  • ユーザーがエンドユーザーの［Settings（設定）］ページにサインインし、ID検証ベンダーで認証しようとすると、［Back to Settings（設定に戻る）］ボタンが表示されませんでした。ユーザーが本人確認を満たしていない場合は、このボタンはエラーページでも表示されませんでした。（OKTA-894271）

  • グループ名に特殊文字が含まれていると、LDAPエージェントがクエリの解析に失敗しました。（OKTA-902231）

Okta Integration Network

週次の更新

2022.04.1：アップデート1は4月11日にデプロイを開始しました

一般利用可能

デバイス保証のOSバージョンアップデート

デバイス保証ポリシーで、次のOSバージョンがサポートされるようになりました。

  • Android 12、13、14、15セキュリティパッチ2025-04-01
  • iOS 16.7.11
  • iOS 18.4
  • macOS Ventura 13.7.5
  • macOS Sonoma 14.7.5
  • macOS Sequoia 15.4
  • Windows 10（10.0.17763.7009、10.0.19044.5608、10.0.19045.5608）
  • Windows 11（10.0.22621.5039、10.0.22631.5039、10.0.26100.3476）

修正

  • デバイス保証ポリシーにChrome OSプラットフォームの条件が含まれている場合は、アクセステストツールが動作しませんでした。（OKTA-840977）

  • Sign-In Widget（第3世代）では、Appleデバイスを使用するユーザーがOkta Verifyでサインインしようとすると、エラーが発生することがありました。（OKTA-861910）

  • ユーザーが選択した認証方法に応じて、Sign-In Widget（第3世代）のさまざまな場所にエラーメッセージが表示されました。（OKTA-871675）

  • スーパー管理者グループがグループリストに含まれていると、Preview orgでorg管理者がIdPグループの割り当てを編集できませんでした。（OKTA-880124）

  • ［ロールの編集］ 画面に正しいワークフロー権限が表示されないことがありました。（OKTA-886964）

  • 組織が認証方法チェーンを使用し、［Keep me signed in（サインインしたままにする）］オプションが選択されている場合に、ユーザーがスマートカードを使用して組織にサインインできませんでした。（OKTA-887124）

  • スーパー管理者がユーザーのAuthenticatorをリセットしようとしたときにエラーが発生しました。（OKTA-890695）

  • id_token_hintパラメーターがシステムログで露出していました。（OKTA-890738）

  • ユーザーがAzure Active Directory PowerShellでGraph APIを操作すると、そのアクティビティがOffice 365のログに誤って記録されていました。（OKTA-896032）

  • WS-Fedと統合されている場合に、ユーザーがOffice 365 GCC HighのOINアプリにサインインできませんでした。（OKTA-899506）

  • ［Oktaサポートへのアクセス権を付与する］ページの ［自分が割り当てたケースに対してサポートアクセス権を付与する］セクションに、正しいケースが表示されないことがありました。（OKTA-909308）

Okta Integration Network

プレビュー機能

Okta認証局の自動更新

管理証明に使用されるOkta認証局（CA）は5年ごとに期限切れになります。プロアクティブに更新しないと、期限切れのCAによって認証が中断され、コンプライアンス要件が妨げられます。このリスクを軽減するために、Okta CA更新サービスは有効期限の1年半前にCAを自動更新し、認証とコンプライアンスが中断されないようにします。このサービスは、CAの更新をプロアクティブに管理することで、ダウンタイムを防ぎ、手動による介入を減らし、管理証明がシームレスで中断されないようにします。「Okta認証局の更新とアクティブ化のガイド」を参照してください。

「サインインしたままにする」の詳細構成

管理者は、認証ポリシーの詳細レベルで、［Keep Me Signed In (KMSI)（サインインしたままにする（KMSI））］用の認証後プロンプトを構成できるようになりました。これにより、管理者はユーザーごと、グループごと、またはアプリごとに認証後のKMSIを選択的に有効化することができます。この機能を有効化すると、認証後のプロンプトをユーザーに表示する頻度を管理者が制御できる設定が公開されます。「サインインしたままにする」を参照してください。認証後のプロンプトテキスト（タイトル、サブタイトル、承諾ボタン、拒否ボタン）は、ブランド管理 APIを通じてカスタマイズできるようになりました。「サインインしたままにする」および「Brands API」を参照してください。

Workdayによる増分インポートのサポート

Workdayに増分インポートを直ちに実行する機能が加わりました。増分インポートはフルインポートよりもはるかに速いです。ただし、ユーザーがカスタム属性のみを変更した場合は検出されないため、これらの変更を取得するには定期的にフルインポートを実行する必要があります。「増分インポート」を参照してください。

新しい柔軟なLDAP

新しいLDAPスキーマでは、メールをカスタムスキーマに移動し、名、姓、ユーザー名、UIDを任意にすることで柔軟性が向上します。これにより、LDAPスキーマに特定の属性が含まれていない場合のエラーシナリオを回避できます。

Admin Consoleへの新規の単一要素アクセスを防止する

この機能は、Admin Consoleへの単一要素アクセスを管理者が構成できないようにします。この機能は現在、新しいorgにのみ利用できます。

アプリケーションエンタイトルメントポリシー

管理者は、アプリを個人またはグループに割り当てる際に属性マッピングを上書きできるようになりました。また、属性をデフォルトのマッピングに戻すこともできます。「アプリケーション属性マッピングを上書きする」を参照してください。この機能は、すべてのorgで段階的に利用できるようになります。

ニックネーム要素のエンドユーザー設定

エンドユーザーは、電話、WebAuthn、Okta Verifyの要素にニックネームを付けられるようになりました。1つの要素のインスタンスを複数登録している場合は、ニックネームを付けると要素をすぐに識別しやすくなります（例：「自分の個人携帯電話」または「自分のオフィス用MacBook TouchID」）。「エンドユーザー向けドキュメント」を参照してください。これはセルフサービスの機能です。

システムログイベントの詳細

Oktaがセキュリティ脅威を特定すると、結果のシステムログエントリー「security.threat.detected」にイベントの詳細な理由が提供されるようになりました。「システムログ」を参照してください。

ThreatInsightのコアOkta APIエンドポイントでの対象範囲

Okta ThreatInsightの対象範囲が、コアOkta APIエンドポイント（OpenID Connect &; OAuth 2.0、Okta Management、MyAccount API）に利用できるようになりました。Okta ThreatInsightは、ヒューリスティックスと機械学習モデルに基づいて、Oktaの顧客ベース全体で悪意のあるアクティビティを一貫して示すIPアドレスのリストを更新して維持します。Okta orgにOkta ThreatInsightが有効化されている場合、これらの不正なIPアドレスからのリクエストはブロックされるか、さらに分析するために昇格されます。これまで、Okta ThreatInsightの対象範囲は、Okta認証エンドポイント（登録エンドポイントと復旧エンドポイントを含む）にのみ適用されていました。本リリースでは、認証エンドポイントに強化された攻撃パターンが検出され、非認証エンドポイントにも制限された攻撃パターンが検出されます。既存のOkta ThreatInsight構成に変更はありません。ログとブロックモード、ログモード、および除外ネットワーク ゾーンを使用しても、Okta ThreatInsightを有効化できます。高脅威のsecurity.threat.detectedイベントに対して、Negative IP Reputationの新しい理由が利用可能になりました。「Okta ThreatInsightのシステムログイベント」を参照してください。

SSOアプリのダッシュボードウィジェット

SSOアプリの新しいウィジェットには、選択した期間におけるorgの各アプリでのユーザーサインインイベント数が表示されます。これを使用すれば、最も頻繁に使用されるアプリを確認し、org全体の認証アクティビティを簡単に監視できます。

セルフサービスロック解除プロセスの改善

以前のバージョンのセルフサービスロック解除（SSU）フローでは、エンドユーザーエクスペリエンスで不要な摩擦が発生していました。新しく強化されたSSU機能により、アカウントのロック解除メールにシームレスなマジックリンクエクスペリエンスが導入されます。ユーザーは、同じブラウザーを使用する場合は同意を提供する必要がなくなりました。さらに、アカウントのロック解除に成功した後、Eメールマジックリンクのクリックもアプリケーションの保証ポリシーに反映されるようになりました。保証要件が満たされた後、ユーザーはアプリケーションに直接サインインします。

セルフサービス登録エクスペリエンスの改善

セルフサービス登録（SSR）フローの以前のバージョンでは、複雑な一連のテンプレートを使用して、アクティベーションメールをエンドユーザーに送信していました。これは、簡素化されたSSRフローにより、カスタマイズされたウェルカムメッセージを含む2つのメールテンプレートのみに削減されます。アプリケーションでエンドユーザーのメールアドレスをすぐに確認する必要がある場合、Oktaでは［Registration - Activation（登録 - アクティベーション）］テンプレートを使用します。このテンプレートには、よりスムーズなサインインエクスペリエンスのためのマジックリンクが含まれています。アプリケーションへのサインインにメール確認がすぐに必要でない場合、Oktaは登録 - メール確認テンプレートを使用します。このテンプレートには、エンドユーザーがアプリケーションに正常にサインインした後に随時メール確認を完了するためのリンクが含まれています。

System Logのメール失敗イベント

管理者は、System Logでメール配信失敗イベントを表示できるようになりました。これにより、管理者がorg内のメールイベントアクティビティを適切に監視できるようになります。「System Log」を参照してください。

Office 365サインオンポリシーに追加のフィルターを選択する

管理者がアプリサインオンポリシーを作成するときに、Webブラウザーとモダン認証クライアントを区別できるように、フィルターが追加されました。

デバイス認可の付与タイプ

インターネット技術の進歩により、スマートデバイスやIoT（Internet of Things）が急増しています。消費者はこれらのデバイスで実行されるアプリケーションにサインインする必要がありますが、スマートTV、車のコンソール、サーモスタットなどのデバイスではWebブラウザーがサポートされていないか、入力機能が制限されています。その結果、ユーザーはエラーが発生しやすく時間のかかる、安全でない認証ソリューションを利用することになります。

デバイス認可付与機能はOAuth 2.0の付与タイプで、入力に制約のあるデバイスだけでなく、Webブラウザーのないデバイスにもサインインできます。この機能により、ユーザーはラップトップや携帯電話などのセカンダリデバイスを使用して、そのようなデバイスで実行されるアプリケーションへのサインインを完了することができます。

エンドユーザーページでコンテンツセキュリティーポリシーを適用する

コンテンツセキュリティーポリシーが、カスタマイズ不可のページでカスタムドメインがあるorgのエンドユーザーページに適用されるようになりました。コンテンツセキュリティーポリシーのヘッダーにより、ブラウザーでWebページが実行できるアクションの種類を確実に認識できるようにすることで、クロスサイトスクリプトやデータインジェクションといった攻撃を検出できる追加のセキュリティーレイヤーを提供します。昨年から管理者ページにはポリシーがすでに適用され、エンドユーザーページに対してもレポートのみのモードに適用されています。今後もエンドユーザーページに対するコンテンツセキュリティーポリシーの適用を繰り返し行っていくことで、この最初のリリースよりも厳格にしていく予定です。

この機能は、すべてのorgで段階的に利用できるようになります。