Notes de version Okta Identity Engine (Production)

Version : 2026.08.0

Importer des agents IA depuis Microsoft Office 365

Vous pouvez désormais importer et gérer les agents IA créés dans Microsoft Copilot Studio et Microsoft IA Foundry directement par Okta. Consultez Importations d'agents IA.

Importer des agents IA depuis Workday

Vous pouvez désormais importer et gérer les agents IA intégrés dans le système d'enregistrement des agents Workday (ASOR) directement par Okta. Consultez Importations d'agents IA.

Mise à jour de la version du système d'exploitation pour la garantie des appareils

Les versions des systèmes d'exploitation suivantes sont désormais prises en charge dans les politiques de garantie des appareils :

• Android 13, 14, 15, 16 avec correctif de sécurité 2026-01-05

Intégration SAML SSO pour Anthropic (Claude)

Une nouvelle intégration SSO SAML 2.0 pour Anthropic (Claude) est désormais disponible sur l'Okta Integration Network, l'intégration existante d'Anthropic AI Agent étant incluse.

Claude prend en charge l'authentification SSO SAML 2.0.

L'intégration d'application Claude prend désormais en charge la SSO SAML 2.0. Les organisations abonnées à Okta for AI Agents peuvent continuer à utiliser l'intégration pour importer les agents gérés par l'utilisateur dans Okta. Consultez Intégrer Claude à Okta.

Approvisionnement pour Barracuda

L'approvisionnement est désormais disponible pour l'intégration de l'application Barracuda WAF-as-a-Service. Consultez Intégrer Barracuda WAF-as-a-Service avec Okta.

Approvisionnement pour Linear

L'approvisionnement continu est maintenant disponible. Consultez Créer une intégration Linear.

Approvisionnement pour Appspace

L'approvisionnement est désormais disponible pour l'intégration de l'application Appspace. Lorsque vous provisionnez l'application, vous pouvez activer des fonctionnalités de sécurité telles que la gestion des droits. Consultez Intégrer Appspace à Okta.

Sign-In Widget, version 7.47.1

Pour plus de détails sur cette version, consultez les notes de version du Sign-In Widget. Pour plus d'informations sur le widget, consultez Okta Sign-In Widget.

Mise à jour de l'audience d'agent à agent

L'URL de ressource du serveur agent-agent (paramètre audience) peut désormais être une chaîne libre.

Cross app access pour les agents IA et les applications

Cross app access sécurise désormais les connexions entre les applications de requêtes SAML personnalisées et les applications de ressources OIDC/SAML. Cette fonctionnalité permet aux administrateurs de connecter en toute sécurité les agents et les applications d'IA pour agir au nom des utilisateurs, en contournant le besoin de consentement de l'utilisateur . Les administrateurs conservent une visibilité totale et un contrôle précis sur chaque action qu'un agent IA peut exécuter pour un utilisateur. Consultez Configurer les connecteurs de serveur de ressources.

Approvisionnement pour SafetyCulture

L'approvisionnement est désormais disponible pour l'intégration de l'application SafteyCulture. Consultez Intégrer SafetyCulture à Okta.

Approvisionnement pour Toggl

L'approvisionnement est désormais disponible pour l'intégration de l'application Toggl. Consultez Intégrer Toggl à Okta.

Approvisionnement pour Moodle

L'approvisionnement est désormais disponible pour l'intégration de l'application Moodle. Consultez Intégrer Moodle à Okta.

Connexions d'agent à agent

Les connexions de serveurs d'agent à agent permettent aux administrateurs de connecter les agents IA à d'autres agents IA. Les administrateurs peuvent gérer les permissions pour restreindre l'accès aux tâches appropriées des agents IA et autoriser les applications de service à appeler les agents IA sans contexte utilisateur. À l'aide des jetons et du journal système, les administrateurs peuvent voir tous les utilisateurs, agents IA et applications qui appellent un agent IA. Consultez Connexions d'agent à agent.

Approvisionnement pour Elastic Search

L'approvisionnement est désormais disponible pour l'intégration de l'application Elastic Search. Consultez Intégrer Elastic Search à Okta.

Approvisionnement pour QualtricsXM

L'approvisionnement est désormais disponible pour l'intégration de l'application QualtricsXM. Consultez Intégrer Qualtrics XM à Okta.

Approvisionnement pour HERE

L'approvisionnement est désormais disponible pour l'intégration de l'application HERE. Consultez Intégrer HERE à Okta.

URL d'émetteur modifiable pour les connexions de ressources d'agent IA

Désormais, lorsque vous créez une connexion de ressource entre un agent IA et un serveur d'autorisations, vous pouvez modifier l'URL de l'émetteur du serveur d'autorisations.

Entrées en échec ignorées lors de l'importation d'agents IA

Désormais, lorsque vous importez des agents IA depuis un fournisseur, Okta ignore les entrées en échec et crée ou met à jour celles réussies. 

Mise à jour de la version du système d'exploitation pour la garantie des appareils

Les versions des systèmes d'exploitation suivantes sont désormais prises en charge dans les politiques de garantie des appareils :

• Android 14, 15, 16, 17 (2026-07-01)
• Versions de Windows 10 (10.0.17763.9020, 10.0.19044.7548, 10.0.19045.7548)
• Versions de Windows 11 (10.0.22631.7376, 10.0.26100.8875, 10.0.26200.8875)

Importer des agents IA depuis Langsmith

Vous pouvez désormais importer et gérer les agents IA créés dans Langsmith Deployments directement via Okta. Consultez Importations d'agents IA.

Mise à jour de la version du système d'exploitation pour la garantie des appareils

Les versions des systèmes d'exploitation suivantes sont désormais prises en charge dans les politiques de garantie des appareils :

• macOS (26.6, 15.7.8, 14.8.8)
• iOS (26.6)

Sign-In Widget, versions 7.48.1 et 7.48.0

Pour plus d'informations sur ces versions, consultez la section Notes de version du Sign-In Widget. Pour plus d'informations sur le widget, consultez Okta Sign-In Widget.

Amélioration de l'enrôlement des cartes à puce

Les utilisateurs peuvent désormais enrôler une carte à puce même si l'attribut de connexion ne correspond pas à la valeur mappée depuis la carte. Auparavant, l'enrôlement échouait lors de la mise en correspondance dynamique ou de l'approvisionnement juste-à-temps, car l'attribut de connexion était considéré comme ne pouvant pas être mis à jour. Consultez Ajouter un fournisseur d'identité par carte à puce.

Enregistrement suspect d'un authentificateur

Cette détection indique qu'Okta Identity Thread Protection (ITP) a identifié une activité suspecte lors d'un événement d'enrôlement d'authentificateur. Les critères spécifiques et les détails de l'événement qui ont déclenché l'alerte sont enregistrés dans le journal système user.risk.detect pour enquête. Consultez Enrôlement suspect d'un authentificateur.

Okta Provisioning Agent, version 3.3.0

Okta Provisioning Agent 3.3.0 est désormais disponible. Cette version prend en charge la réduction dynamique de la taille des pages lors des importations d'applications SCIM, de l'approvisionnement delta via des requêtes PATCH et de la suppression automatisée des droits lors des certifications d'accès. De plus, cette version met à jour le JRE Amazon Corretto fourni vers la version 17.0.19.10.1 et résout un problème de sécurité lié à la journalisation. Consultez l'historique des versions de la trousse SDK et d'Okta Provisioning Agent.

Okta Active Directory Agent, version  3.23.0

Cette version de l'Okta Active Directory Agent met à jour l'utilitaire de gestion de l'AD Agent pour guider les administrateurs dans l'octroi des autorisations minimales requises au lieu de leur demander d'ajouter des comptes de service au groupe Administrateurs du domaine. De plus, le programme d'installation ne s'interrompt plus lors des vérifications des autorisations des comptes de service dans des environnements mal configurés. Cette version comprend également des améliorations de sécurité et des correctifs de bugs. Consulter Historique des versions d'Okta Active Directory Agent.

Nouveau cycle de vie des versions de recherche

Un nouveau cycle de vie des versions de recherche, signalé par une bannière Version de recherche, est désormais disponible pour la documentation destinée aux administrateurs Okta. Les fonctionnalités Version de recherche sont disponibles exclusivement pour les membres du programme Okta Research Partner pendant une période d'évaluation fixe, avant qu'une fonctionnalité ne passe en accès anticipé ou en disponibilité générale. Consultez Versions de recherche.

Amélioration des événements du journal système pour le routage IdP

Les événements du journal système pour le routage IdP incluent désormais les informations cibles de la règle de découverte IdP correspondante, le cas échéant.

Nouveau nombre minimal de caractères pour les noms des agents IA

Les noms des agents IA doivent désormais contenir au minimum trois caractères. 

Nouveau service de proxy pour les zones dynamiques améliorées

PROXYLINE_PROXY est désormais pris en charge en tant que catégorie de service de proxy individuelle dans les zones dynamiques améliorées. Consultez Catégories d'IP prises en charge.

Demander l'exportation des données d'abonnement

Pour exporter des informations sur les utilisateurs abonnés aux requêtes d'accès, sélectionnez l'option Abonnements aux requêtes dans la fenêtre Exporter les données. L'option Requêtes n'inclut plus les données des abonnés. Consultez Exporter des données depuis Requêtes d'accès.

Nouvelle cible pour les événements user.risk.detect

Identity Threat Protection renseigne désormais les facteurs affectés dans la cible de l'événement user.risk.detect pour les actions critiques d'entité correspondant à des adresses IP à haut risque.

Nouveaux événements du journal système pour l'approvisionnement basé sur les applications Office 365

Le journal système enregistre désormais les événements suivants relatifs à l'authentification basée sur des applications pour l'approvisionnement d'Office 365 : app.office365.provisioning_app.create : cet événement est enregistré lorsqu'Okta crée une application Microsoft Entra ID dédiée qui est enregistrée et utilisée pour l'approvisionnement d'Office 365. app.office365.provisioning_app_credential.rotate : cet événement est autorisations lorsqu'Okta procède à une rotation du secret client de l'application Microsoft Entra ID enregistrée qui est utilisée pour l'approvisionnement d'Office 365. Le champ Outcome dans les données de cet événement indique si la rotation du secret client a réussi ou non.

Vérifications de posture avancées pour l'assurance des appareils

Les vérifications de posture avancées permettent aux administrateurs de configurer des conditions de sécurité d'appareil spécifiques au-delà de ce que prennent en charge les politiques de vérification d'appareils standard. À l'aide d'Osquery, vous pouvez écrire des requêtes SQL personnalisées pour évaluer l'état des appareils sur les appareils macOS et Windows, configurer des vérifications pour les appareils non gérés et les intégrer à des outils EDR (détection des point de terminaison ). Voir Configurer des vérifications de posture avancées pour la garantie des appareils.

Application d'un chiffrement fort pour l'authentification par certificat client X.509

Okta applique désormais des chiffres cryptographiques forts pour les certificats client X.509 utilisés dans l'authentification mTLS. Les certificats clients signés avec des chiffres faibles, tels que RSA-1024, ne sont plus acceptés pour les nouvelles orgs. Si vous utilisez authentification par certificat X.509, assurez-vous que vos certificats client répondent aux exigences de chiffrement FIPS 140-2.

Écran d'enrôlement des clés d'accès mis à jour

L'écran d'enrôlement des clés d'accès dans le Sign-In Widget inclut désormais un texte mis à jour et une image d'information pour aider les utilisateurs à comprendre ce que sont les clés d'accès avant leur enrôlement.

E-mails personnalisables pour l'authentificateur de Clés d'accès (FIDO2 WebAuthn)

L'e-mail que les utilisateurs reçoivent lorsque l'administrateur configure un authentificateur de Clés d'accès (FIDO2 WebAuthn) est maintenant disponible en tant que modèle personnalisable dans Personnalisations > Marques > E-mails. Les administrateurs peuvent modifier la ligne d'objet, le corps de e-mail et les variables dynamiques telles que le code PIN, le prénom et le nom de org , et peuvent ajouter du contenu dans plusieurs langues. 

Gestion de l'enrôlement automatique par e-mail et gestion de la récupération

Les administrateurs peuvent contrôler l'enrôlement automatique d'une adresse e-mail en tant qu'authentificateur et configurer la récupération, le déverrouillage et le changement du mot de passe par e-mail lorsque l'adresse e-mail n'est pas un authentificateur. Consultez Faire de l'e-mail un authentificateur facultatif.

Authentification basée sur les applications pour l'approvisionnement d'Office 365

Okta crée désormais une application dédiée dans votre Tenant Microsoft Entra ID au lieu d'un compte de service pour la synchronisation de l'utilisateur et l'approvisionnement de la synchronisation universelle. Cette application prend en charge l'authentification par application et contribue à améliorer la sécurité de votre organisation. Si vous avez déjà configuré User Sync (Synchronisation de l'utilisateur) ou Universal Sync (Synchronisation universelle), vous devez vous réauthentifier et consentir à deux nouvelles permissions d'ici le 30 septembre 2026. Consultez Fournir un consentement administrateur Microsoft pour Okta.

Les pages Serveurs MCP et Serveurs de ressources ont été déplacées vers Applications et ressources.

Dans l'Admin console, les pages Serveurs MCP et Serveur de ressources ont été déplacées du menu Directory vers le menu Applications et ressources.

Le menu Applications a été renommé Applications et ressources.

Dans l'Admin Console, le menu Applications est désormais appelé Applications et ressources.

Protection contre la violation d'identifiants améliorée

Cette fonctionnalité fournit un flux de détection d'identifiants compromis de haute qualité pour les clients Okta Customer Identity (OCI) avec Identity Threat Protection, qui identifie plus vite les identifiants compromis. Voir Protection des identifiants violés.

Mettre à jour les affectations de règle de groupe

Les administrateurs peuvent désormais mettre à jour les groupes affectés à une règle de groupe sans supprimer ni recréer la règle. Cela simplifie la gestion des appartenances aux groupe et des conditions de règle. Voir Modifier les règles de groupe.

Importer des utilisateurs sans licence depuis Azure Active Directory vers Okta

Vous pouvez désormais importer des utilisateurs depuis Microsoft Azure Active Directory (AAD) qui ne disposent pas d'une licence Office 365 affectée. Cela permet aux administrateurs de centraliser le cycle de vie de leur main-d'œuvre dans Okta et élimine la nécessité de gérer les comptes sans licence sur les deux plateformes. Consultez Importer des utilisateurs dans  Office 365  à l'aide de l'API Microsoft Graph.

Vérification de l'identité avec intégrations soumises par le fournisseur

Les fournisseurs de vérification d'identité (IDV) peuvent maintenant soumettre des intégrations via Okta Integration Network. Vous pouvez configurer et appliquer ces intégrations à vos politiques d'authentification afin de vérifier les identités des utilisateurs.

Rotation à la demande des certificats de signature SSO Office 365

Les intégrations d'application Office 365 qui utilisent WS-Federation pour l'authentification prennent désormais en charge l'utilisation des certificats au niveau de l'application. Le passage des certificats au niveau de l'organisation aux certificats au niveau de l'application améliore vos résultats en matière de sécurité en éliminant un point de défaillance unique en cas d'expiration d'un certificat partagé au niveau de l'organisation. Les mises à jour de l'interface utilisateur permettent aux administrateurs informatiques de surveiller facilement le statut des certificats, de générer des certificats à la demande et d'effectuer des rotations de certificats sans interrompre les opérations. Consultez la section Configurer l'authentification unique pour Office 365.

Synchroniser les données de l'appareil avec Anything-as-a-Source

En plus des utilisateurs et des groupes, les intégrations de source d'identité personnalisée peuvent désormais synchroniser les données des appareils à partir d'une source fiable. Les appareils utilisent un ensemble fixe d'attributs : serialNumber, platform et displayName. Voir Utiliser Anything-as-a-Source.

Gestion des modifications de politique

Les administrateurs peuvent créer des branches de leurs politiques de connexion à l'application pour examiner et surveiller l'impact des modifications avant d'appliquer la politique pour les utilisateurs finaux. Cela permet aux administrateurs de rédiger des changements de politique, de les tester par rapport au trafic réel des utilisateurs et de les déployer en toute confiance. Consultez Gérer les branches de politiques de connexion à l'application.

Vérification de l'identité avec intégrations soumises par le fournisseur

Les fournisseurs de vérification d'identité (IDV) peuvent maintenant soumettre des intégrations via Okta Integration Network. Vous pouvez configurer et appliquer ces intégrations à vos politiques d'authentification afin de vérifier les identités des utilisateurs.

Importer des agents IA depuis Glean

Vous pouvez désormais importer et gérer les agents d'IA créés avec Glean Agent Builder directement via Okta. Consultez Importations d'agents IA.

Mode du capteur de posture de l'appareil Okta Verify

Auparavant, l'application de la posture de sécurité des appareils créait d'importants champs aveugles sur les appareils partagés, car elle nécessitait une enrôlement unique à Okta FastPass. Le mode Capteur d'Okta Verify résout ce problème en enregistrant l'application directement auprès de l'org, ce qui permet d'évaluer instantanément les politiques de vérification des appareils sensibles au contexte lorsque l'utilisateur s'authentifie. Cette fonctionnalité est particulièrement utile pour les travailleurs de première ligne, car elle garantit une conformité complète pour les flottes partagées et garantit le bon fonctionnement des appareils avant que l'accès ne soit accordé. Consultez Mode du capteur de posture de l'appareil.

Fonctionnalité Device Visibility pour macOS et Windows

Device Visibility remplace la page de détails de base pour les appareils gérés par une nouvelle vue à quatre onglets pour les appareils macOS et Windows. Elle expose les comptes utilisateur au niveau du système d'exploitation, le statut d'enrôlement à Okta FastPass et à l'authentification SSO sur la plateforme, la version Okta Verify et les indices de sécurité des appareils en un seul endroit. Il est ainsi plus facile pour les administrateurs informatiques et les administrateurs de sécurité de vérifier l'enrôlement des authentificateurs et d'évaluer la posture de sécurité des appareils sans écraser les informations provenant de plusieurs écrans. Consultez Voir les détails des appareils.

Suppression de la configuration de Cross App Access via une connexion gérée

La suppression de la possibilité de configurer le Cross App Access depuis l’onglet Connexion gérée situé sur la page de profil de l’application est prévue pour une prochaine version. Une fois supprimées, vos configurations existantes cesseront de fonctionner. Reconfigurez vos connexions depuis l'onglet Serveur de ressources pour éviter les interruptions. Consultez Connecter les agents IA aux ressources.

Nouveaux événements du journal système pour les modifications d’appareils en masse

Les événements du journal système suivants sont désormais disponibles pour les modifications d'appareils en masse :

• system.identity_sources.bulk_device_upsert
• system.identity_sources.bulk_device_delete

Fonctionnalité Device Visibility pour macOS et Windows

Device Visibility remplace la page de détails de base pour les appareils gérés par une nouvelle vue à quatre onglets pour les appareils macOS et Windows. Elle expose les comptes utilisateur au niveau du système d'exploitation, le statut d'enrôlement à Okta FastPass et à l'authentification SSO sur la plateforme, la version Okta Verify et les indices de sécurité des appareils en un seul endroit. Il est ainsi plus facile pour les administrateurs informatiques et les administrateurs de sécurité de vérifier l'enrôlement des authentificateurs et d'évaluer la posture de sécurité des appareils sans écraser les informations provenant de plusieurs écrans. Consultez Voir les détails des appareils.

Publics multiples pour les serveurs d'autorisations personnalisés

Les serveurs d’autorisations personnalisés prennent désormais en charge plusieurs publics en plus d'un public par défaut. Consultez Créer un serveur d'autorisations.

Configuration souple de l'authentificateur Okta Verify

Okta Verify est regroupé au sein d'un authentificateur unique doté de paramètres valables à l'échelle de l'org, ce qui vous empêche de configurer des méthodes de vérification individuelles (Okta FastPass, notification push ou TOTP) pour chaque groupe. Cette fonctionnalité divise Okta Verify en authentificateurs distincts, propres à chaque méthode, ce qui vous permet de déployer progressivement Okta FastPass.

Invite de promotion de l'enrôlement d'une clé d'accès

Vous pouvez désormais configurer un encouragement à l'enrôlement de clés d'accès qui invite les utilisateurs finaux à enrôler un authentificateur par clés d'accès lorsqu'ils se connectent. Cet encouragement s'applique uniquement lorsque l'authentificateur par clés d'accès est facultatif, et les utilisateurs qui l'ignorent peuvent quand même se connecter avec un autre authentificateur. Vous pouvez contrôler la fréquence d'affichage de l'invite et le nombre de fois qu'un utilisateur peut l'ignorer avant qu'Okta ne cesse de l'afficher. Consultez Créer une politique d'enrôlement des authentificateurs.

Politique d'identification des utilisateurs

Les administrateurs peuvent désormais gérer les règles de la politique d’identification des utilisateurs pour contrôler si le bouton Se connecter avec Okta FastPass s'affiche application par application, au lieu de s’appuyer sur un paramètre unique à l’échelle de l’org. Cela facilite la gestion des groupes pilotes lors des déploiements d’Okta FastPass et la personnalisation de l’expérience de connexion pour chaque application. Consultez Ajouter une règle à une politique d'identification des utilisateurs.

Sélecteur de la version d'Okta Engine sur help.okta.com

Vous pouvez désormais vérifier si un sujet sur help.okta.com s'applique à Identity Engine ou à Classic Engine et basculer directement vers la page correspondante en un clic. Le sélecteur reste visible lorsque vous faites défiler la page. Si un sujet est propre à un moteur, un message No matching topic for [Identity/Classic] engine s'affiche.

• Dans Sécurité > Fournisseurs d'identité, le bouton Réinitialiser la chaîne de certificats pour les fournisseurs d'identité de carte à puce était disponible pour les administrateurs en lecture seule. (OKTA-1205602)

• L'événement user.authentication.sso était absent du journal système lorsque les appels incorporés SAML généraient des erreurs 5xx. (OKTA-1223139)

• Les champs Échange de jetons sécurisés OAuth (STS) étaient visibles pour les applications de serveurs de ressources qui ne prenaient pas en charge le protocole STS.  (OKTA-1226327)

• Certaines tentatives de connexion faisant référence à un lien d'application de signet non résolu renvoyait un type de message d'erreur incorrect. (OKTA-1234441)

• Lorsqu'un administrateur importait des utilisateurs Active Directory, la confirmation de l'utilisateur échouait si les attributs d'un utilisateur supprimé entraient en conflit avec un profil utilisateur entrant.  (OKTA-1235909)

• StackAdapt (OIDC) a été mis à jour. En savoir plus.

• Clutch Security (service d'API) a été mis à jour. En savoir plus.

• X (Twitter) (SWA) a été mis à jour.

• Mountain Goat est désormais disponible. En savoir plus.

• Alpacon prend désormais en charge la configuration Express.

• Alpacon (OIDC) est désormais disponible. En savoir plus.

• Finopz (OIDC) est désormais disponible. En savoir plus.

• Skillcast (SAML) est désormais disponible. En savoir plus.

• Skillcast (SCIM) est désormais disponible. En savoir plus.

Mise à jour de la version du système d'exploitation pour la garantie des appareils

Les versions des systèmes d'exploitation suivantes sont désormais prises en charge dans les politiques de garantie des appareils :

• Android 14, 15, 16, 17 (2026-08-01)

Nouvelles catégories de service IP pour les zones dynamiques améliorées

Plusieurs nouvelles catégories de service IP sont désormais prises en charge en tant que catégorie de service VPN individuelle dans les zones dynamiques améliorées. Consultez Catégories d'IP prises en charge.

Prise en charge de Cross App Access pour les agents et applications IA pour tous les clients

Utilisez XAA pour sécuriser l'accès entre les applications demandeuses d'agents SSO personnalisées et les applications de ressources SSO. XAA permet aux clients de connecter des agents et applications IA afin qu'ils agissent au nom d’un utilisateur, et supprime la nécessité d’un consentement de l’utilisateur au moment de l’exécution. La connexion XAA est gérée par les administrateurs Okta, ce qui leur offre une visibilité et un contrôle sur les actions qu'un agent IA peut entreprendre au nom d'un utilisateur via les protocoles SSO OIDC et SAML pris en charge.

• Pour la configuration des applications demandeuses d'agents, consultez Ajouter des agents IA manuellement et sélectionnez votre application d'agents SSO dans Accès utilisateur > Application utilisée pour la configuration de l’accès.
• Pour la configuration de l’application de ressources XAA, consultez Configurer les connecteurs de serveur de ressources. Si vous configurez une application de ressources OIN, XAA doit déjà être activé.
• Pour connecter l'agent IA à l'application de ressources, consultez Connecter les agents IA à des ressources et sélectionnez Application comme type de ressource, puis votre application de ressources.

Pour les applications demandeuses d'agents qui utilisent OIDC pour la SSO, Okta permet de lier un agent IA à une application SSO OIDC afin qu'ils partagent les mêmes identifiants. Si vous souhaitez supprimer cette configuration dans Okta, supprimez l'agent IA et l'application OIDC correspondante.

Grâce à cette fonctionnalité de liaison de l'agent IA et l'application, les administrateurs peuvent désormais configurer l'authentification directe des utilisateurs pour l'agent IA. Si vous disposez d’une org Okta for AI Agents et que vous avez déjà utilisé l’onglet Délégation pour configurer l’accès des agents IA via des liens de délégation, vous devez les reconfigurer avec l’onglet Accès utilisateur. Consultez le guide Migration from un lien de délégation Okta for AI Agents.

• Dans certaines organisations, le journal système n'affichait pas les événements user.session.start de manière uniforme pour toutes les tentatives de connexion. (OKTA-1138083)

• Les règles de routage du fournisseur d'identité (IdP) délimitées par l'application pouvaient acheminer les demandes d'authentification vers le mauvais IdP, entraînant ainsi des échecs de connexion pour les utilisateurs qui auraient dû être redirigés vers un IdP différent ou la page de connexion par défaut. (OKTA-1176869)

• Lors de la réinitialisation du mot de passe d'un administrateur, l'onglet Rôles d'administrateur disparaissait de la page du profil utilisateur dans l'Admin Console. (OKTA-1184998)

• Si votre rôle personnalisé n'incluait que l'autorisation Réinitialiser les authentificateurs des utilisateurs, vous pouviez également enrôler à tort des authentificateurs au nom des utilisateurs. (OKTA-1220095)

• Lorsqu'une attribution de jeton OAuth échouait, l'événement du journal système qui en résultait n'affichait pas les détails de l'utilisateur. (OKTA-1229159)

• Lorsqu'un administrateur importait des utilisateurs Active Directory, la confirmation de l'utilisateur échouait si les attributs d'un utilisateur supprimé entraient en conflit avec un profil utilisateur entrant. (OKTA-1235909)

• Les champs Échange de jetons sécurisés OAuth (STS) étaient visibles pour les applications de serveurs de ressources qui ne prenaient pas en charge le protocole STS.  (OKTA-1238571)

• Sur la page Agents IA, le filtre Application d'authentification de l'utilisateur était visible pour les organisations qui n'étaient pas abonnées à Okta for AI Agents. (OKTA-1239631)

• Sur la page Enregistrer un agent IA, le texte d'aide sous le champ Nom affichait un nombre minimal de caractères incorrect. (OKTA-1241243)

• Dans certaines organisations, le nombre minimal de caractères du nom d'un agent IA était de 5 caractères au lieu de 3. (OKTA-1242199)

• Lorsqu'un administrateur activait une clé publique/privée pour un agent IA, le statut affiché était Désactivé. (OKTA-1245200)

• Lorsque l'exigence d'interaction utilisateur pour une règle de politique d’Okta Account Management était définie sur N'importe quelle interaction, Okta l'appliquait de manière incorrecte comme si Exiger un code d'accès à l'appareil ou une vérification de l’utilisateur était sélectionné, ce qui pouvait empêcher les utilisateurs de se connecter. (OKTA-1245305)

• Lorsqu'un administrateur importait des agents IA depuis Microsoft Copilot Studio ou Microsoft Foundry, les propriétaires configurés ne leur étaient pas attribués. (OKTA-1245342)

• Airwallex (OIDC) est désormais disponible. En savoir plus.

• Le logiciel Stages de Bold Group (SAML) est désormais disponible. En savoir plus.

• Gateco (SCIM) est désormais disponible. En savoir plus.

• NewCore (service d'API) a été mis à jour.

• Orca Security (SAML) est désormais disponible. En savoir plus.

• Orca Security (SCIM) est désormais disponible. En savoir plus.

• Square (OIDC) est désormais disponible. En savoir plus.

• Statsig Lifecycle Management Connector by Redblock (SCIM) est désormais disponible. En savoir plus.

• Vimeo Lifecycle Management Connector by Redblock (SCIM) est désormais disponible. En savoir plus.

Mise à jour de la version du système d'exploitation pour la garantie des appareils

Les versions des systèmes d'exploitation suivantes sont désormais prises en charge dans les politiques de garantie des appareils :

• macOS 14.8.9
• macOS 15.7.9
• macOS 26.6.1

Radius Agent version 2.27

Cette version inclut des améliorations et correctifs internes.

Empreinte numérique TLS JA4

Okta capture désormais les empreintes digitales du client TLS JA4 pour les types d'événements du journal système (securityContext.tlsFingerprint.ja4 pr), au lieu d'un sous-ensemble sélectionné. Cela inclut les événements de téléphonie (par exemple, OTP/envoi de SMS), ainsi que les événements de connexion, d'authentification et de jeton. Les clients et les équipes de sécurité d'Okta disposent ainsi d'une visibilité au niveau de l'empreinte digitale pour repérer le trafic des robots, la fraude au péage et d'autres modèles d'attaques basés sur TLS que les signaux d'IP ou agent-utilisateur ne détectent pas eux-mêmes.

Ceci n'est pas encore disponible pour les orgs sur des domaines hébergés de manière personnalisée.

Analyse des importations améliorée avec mises à jour en temps réel

Vous pouvez désormais consulter la progression en temps réel des importations depuis le tableau de bord Analyse des importations. Vous bénéficiez d'une plus grande visibilité sur le statut actuel des importations en cours, comme le nombre de blocs de données en cours de traitement.

Copier les adresses e-mail d'expéditeur vers le domaine par défaut de la marque

Vous pouvez désormais copier une adresse e-mail d'expéditeur personnalisée vers le domaine Okta par défaut lors de la configuration des paramètres d'e-mail d'une marque. Auparavant, cette option n'était disponible que lors de la copie entre des marques personnalisées.

• Lors de la connexion à une application Microsoft Forms, les utilisateurs étaient redirigés vers la page générique du produit Microsoft Forms au lieu de l'application Microsoft Forms appropriée à l'adresse forms.cloud.microsoft. (OKTA-1145722)

• Lorsque les administrateurs tentaient de mettre à jour une politique de sécurité, une invite d'authentification renforcée avec une action protégée leur demandait à plusieurs reprises d'activer les fenêtres contextuelles du navigateur. (OKTA-1146100)

• Le rapport sur l'intégrité des mots de passe Okta expirait pour les organisations ayant des répertoires utilisateur volumineux et renvoyait des données incomplètes. Les rapports pour les grandes orgs sont désormais limités à un maximum de 500 000 utilisateurs afin de garantir des performances fiables. (OKTA-1151306)

• Lors de la réinitialisation du mot de passe d'un administrateur, l'onglet Rôles d'administrateur disparaissait de la page du profil utilisateur dans l'Admin Console. (OKTA-1184998)

• Dans le journal système, les événements d'échec du cycle de vie des agents IA affichaient les détails bruts des exceptions internes. (OKTA-1186282)

• Dans certaines organisations, les utilisateurs voyaient un message d'erreur lorsqu'ils dépassaient le nombre limite de tentatives infructueuses de saisie d'un mot de passe, au lieu d'être invités à démarrer le flux de récupération du compte. (OKTA-1199064)

• Les requêtes de création ou de mise à jour d’utilisateurs échouaient parfois, même lorsque le corps de la requête contenait des attributs de profil valides et définis. (OKTA-1210697)

• Une fois qu'un administrateur avait déconnecté un utilisateur d'un fournisseur d'identité OIDC, la page du profil de l'utilisateur dans l'Admin Console était vide et se chargeait en boucle. (OKTA-1231254)

• Les utilisateurs voyaient le mauvais message d’erreur lorsqu’une expression Okta Expression Language non valide était configurée dans une application SAML. (OKTA-1231797)

• L'expiration de la session de l'appareil DBSSO était définie sur une durée plus courte que prévu. (OKTA-1242470)

• Les URL des pages Serveurs MCP et Serveur de ressources n'indiquaient pas leur nouvel emplacement dans le menu Applications et ressources. (OKTA-1245160)

• Lorsqu'un administrateur tentait d'enregistrer un serveur MCP avec une URL incomplète, il recevait une erreur 400 au lieu d'un message d'erreur descriptif. (OKTA-1246008)

• Les paramètres de l'authentificateur Okta Verify fourni précédent restaient en cache pendant 1 heure, même si la configuration flexible de l'authentificateur Okta Verify était activée. (OKTA-1246010)

• AppsFlyer Lifecycle Management Connector By Redblock (SCIM) a été mis à jour. En savoir plus.

• Briefly (OIDC) est désormais disponible. En savoir plus.

• Briefly (SCIM) est désormais disponible. En savoir plus.

• Clipper Card (SWA) a été mis à jour.

• Harmony (intégration de service d'API) dispose désormais de la permission okta.schemas.read.

• L'intégration Hero dispose de nouvelles permissions okta.roles.read, okta.userTypes.read, okta.logs.read et okta.groups.read.

• MicroWest Software Systems - AMMSWEB (SAML) est désormais disponible. En savoir plus.

• MintMCP (SAML) est désormais disponible. En savoir plus.

• OCCAM Razor (OIDC) dispose de trois nouvelles URI de redirection.

• Orchestra (OIDC) est désormais disponible. En savoir plus.

• Orchestra (SCIM) est désormais disponible. En savoir plus.

• Petual (SCIM) est désormais disponible. En savoir plus.

• Petual prend désormais en charge la configuration Express.

• RansomLeak (SAML) est désormais disponible. En savoir plus.

• RansomLeak (SCIM) est désormais disponible. En savoir plus.

• Remote.com (SCIM) est désormais disponible. En savoir plus.

• Le paramètre Rubrik Security Cloud (intégration de service d'API) a été mis à jour.

• Showpad (SAML) a un nouveau guide de configuration. En savoir plus.

• Showpad (SCIM) a un nouveau guide de configuration. En savoir plus.

• ZoomInfo a mis à jour un mappage de profil.

Enregistrement manuel des serveurs MCP

Les administrateurs peuvent désormais configurer manuellement les détails du serveur d'autorisations et les identifiants client lors de l'enregistrement des serveurs MCP. Cela permet l'enregistrement de serveurs MCP internes ou hérités qui ne prennent pas en charge les points de terminaison de découverte de métadonnées automatisée. Consultez Ajouter des serveurs MCP.

Mise à jour de la version du système d'exploitation pour la garantie des appareils

Les versions des systèmes d'exploitation suivantes sont désormais prises en charge dans les politiques de garantie des appareils :

• macOS (26.6.2)
• iOS (26.6.1, 18.7.10)
• Versions de Windows 10 (10.0.17763.9121, 10.0.19044.7663, 10.0.19045.7663)
• Versions de Windows 11 (10.0.22631.7517, 10.0.26100.9168, 10.0.26200.9168)

Exigence d'authentification pour l'application d'un agent IA

Lorsqu'un agent IA est lié à une application, l'onglet Accès utilisateur affiche désormais l'exigence d'authentification pour l'application. Il fournit également un lien vers l'onglet Authentification de l'application, dans lequel vous pouvez configurer une politique d'authentification. 

Mises à jour de l'intégration Jamf Pro

Le champ Format du nom d'utilisateur de l'application dans l'Admin Console s'affiche désormais par défaut. Cela permet aux administrateurs de configurer des mappages personnalisés pour l'attribut SCIM userName.

• Lorsqu'un administrateur configurait une URL de déconnexion unique avec des paramètres de requête pour une application OIDC, les paramètres de requête étaient supprimés de la requête sortante, alors qu'ils auraient dû être inclus. (OKTA-1148277)

• Les droits ne pouvaient pas être importés sans activer d'autres paramètres d'approvisionnement en aval pour l'On-prem Connector pour les bases de données génériques. (OKTA-1167099)

• Après la mise à niveau d'une org de Classic Engine vers Identity Engine, un authentificateur par téléphone qui avait été inscrit avant la mise à niveau affichait la date de la première authentification de l'utilisateur comme date de création, plutôt que la date d'enrôlement initiale. (OKTA-1172610)

• Lorsque l'appartenance à un groupe était supprimée en masse, les règles de groupe désactivées apparaissaient toujours dans l'onglet Groupe > Personnes. (OKTA-1199754)

• Lorsqu'un utilisateur qui avait été supprimé d'une application dans Okta lui était réaffecté, le statut restait à l'état « Désactivé » dans l'interface utilisateur de l'application. (OKTA-1217473)

• Certaines détections d'ITP ne disposaient pas de champs distincts pour l'adresse IP et external_session_id. (OKTA-1219107)

• Dans un flux de connexion avec plusieurs règles de politique Okta Account Management nécessitant l'inscription en ligne de plusieurs authentificateurs, les utilisateurs qui avaient inscrit une clé de sécurité recevaient une erreur et étaient invités à plusieurs reprises à se réinscrire. (OKTA-1238490)

• Certains liens de la page d'aide à la connexion ne respectaient pas le rapport de contraste minimum. (OKTA-1241201)

• Si un utilisateur finalisait la récupération du mot de passe depuis la page de connexion et devait ensuite mettre à jour son profil (par exemple, pour accepter les conditions générales mises à jour), la mise à jour échouait avec une erreur, empêchant ainsi l'utilisateur de finaliser le flux de connexion. (OKTA-1241265)

• Les attributs personnalisés (tels que l'ID d'employé) et leurs champs de mappage d'attributs qui étaient ajoutés à la vérification d'identité (IDV) n'étaient pas inclus dans la charge utile envoyée au fournisseur de vérification. (OKTA-1243676)

• La portée interclient_access était absente de la liste des portées pour les serveurs d'autorisations. (OKTA-1250422)

• Le pied de page était absent sur la page Applications. (OKTA-1251535)

• Lorsque les administrateurs créaient ou modifiaient un ensemble de ressources d'administrateur personnalisé dans l'Admin Console, la tentative d'affectation de 300 domaines Realm ou plus entraînait l'omission de ressources dans la liste de sélection. (OKTA-1252754)

• Lorsqu'un administrateur lançait une importation d'utilisateurs pour un compte de service unique ne disposant pas d'objet utilisateur Okta, le processus de synchronisation des profils mettait à jour de manière erronée tous les utilisateurs de l'instance Active Directory. (OKTA-1267422)

• L'importation d'utilisateurs ne parvenait pas à procéder à la pagination, seuls les 100 premiers utilisateurs étant récupérés. (OKTA-1257332)

• Flexopus (SAML) est désormais disponible. En savoir plus.

• Paminga (OIDC) est désormais disponible. En savoir plus.

• Paminga (SCIM) est désormais disponible. En savoir plus.

• La gestion du cycle de vie Upwave de Redblock (SCIM) est désormais disponible. En savoir plus.

• Velantix Axiom (OIDC) est désormais disponible. En savoir plus.

• Velantix Axiom (SCIM) est maintenant disponible. En savoir plus.

Connecteur SAP

L'intégration SAP a été migrée pour utiliser l'API SCIM 2.0, et le flux d'aide HTTP interne du connecteur a été mis à jour pour prendre en charge ce standard.

• Après avoir répondu à l'invite Maintenir la connexion dans un Sign-In Widget intégré, certains utilisateurs rencontraient une erreur qui interrompait le flux de connexion. (OKTA-1236248)

• Les administrateurs disposant de l'autorisation Gérer les applications pouvaient ajouter des URL de point de terminaison OAuth incorrectes à une intégration d'application. (OKTA-1236616)

• Un avertissement s'affichait lorsqu'un administrateur sélectionnait une application en Federation Broker Mode dans l'onglet Accès de l'utilisateur d'un agent IA . (OKTA-1248268)

• Dans les orgs avec la fonctionnalité Gestion des changements de politique activée et des branches de politiques existantes, l'activation de la politique d'identification des utilisateurs créait des politiques d'authentification en double. (OKTA-1250771)

• Lorsque les administrateurs effectuaient des actions de gestion des utilisateurs de base, les requêtes échouaient et renvoyaient une erreur générique Mauvaise requête. (OKTA-1252640)

• L'importation d'utilisateurs ne parvenait pas à procéder à la pagination, seuls les 100 premiers utilisateurs étant récupérés. (OKTA-1257332)

• Lorsqu'aucune clé d'accès n'était enrôlée, le tableau de bord des utilisateurs finaux affichait l'étiquette de méthodes de sécurité comme Clé de sécurité ou Authentificateur biométrique au lieu de Clé d'accès. (OKTA-1258336)

• Lors de l'envoi d'une requête POST au point de terminaison /api/v1/iam/auditors/{principalId} en utilisant un type de principal non reconnu, Okta renvoyait une erreur HTTP 501 Non implémenté au lieu d'une réponse d'erreur valide côté client. (OKTA-1258808)

• La page Console des administrateurs pour les règles de politique de découverte de l'IdP n'affichait pas d'indicateur de chargement lors du chargement des instances d'application. (OKTA-1259638)

• Lorsqu'un mécanisme de protection contre le retrait d'une application utilisateur était déclenché au cours d'une importation, la reprise de l'opération entraînait une importation complète du tenant au lieu d'une importation incrémentielle. (OKTA-1271321)

• Marker.io by Redblock (SCIM) est désormais disponible. En savoir plus.

• Square (OIDC) prend désormais en charge le flux de SSO initiée par IdP. En savoir plus.