Préparez vos personnalisations pour la mise à niveau

Évaluez toutes les personnalisations avant de tenter une mise à niveau en libre-service. Les pages de connexion personnalisées que vous configurez dans Classic Engine peuvent ne pas fonctionner après votre mise à niveau vers Identity Engine.

Le hub de mise à niveau OIE affiche un élément de reconnaissance s'il détecte des personnalisations dans votre expérience de connexion. Cependant, cela ne signifie pas que les personnalisations rencontrent des problèmes (par exemple, une chaîne d'interface utilisateur modifiée est une personnalisation). Si vous voyez un élément de confirmation de personnalisation, repérez-le dans votre organisation Okta, puis suivez les étapes de préparation.

Avant de commencer

Déterminez le modèle de déploiement que votre organisation utilise pour implémenter l'expérience d'authentification Okta.

  • Redirection : l'utilisateur est redirigé depuis une app vers le Sign-In Widget hébergé par Okta pour authentification. Une fois l'authentification terminée, ils sont redirigés vers l'application. La préparation est simple pour les modèles de redirection.
  • Intégré : l'utilisateur ne quitte jamais l'application. Au lieu de cela, les API gèrent le flux d'authentification avec un Sign-In Widget hébergé par le client ou avec un code côté serveur. Si votre organisation héberge le Sign-In Widget, la préparation de la mise à niveau est relativement simple. Si vous utilisez des API ou des SDK, la préparation est plus compliquée.

Les organisations qui comportent plusieurs marques peuvent utiliser des modèles de déploiement différents pour chacune d'elles. Reportez-vous aux scénarios suivants pour apprendre comment préparer chaque modèle.

Sign-In Widget hébergé par Okta (par défaut)

Si l'URL de connexion de votre organisation inclut okta.com ou oktapreview.com, vous utilisez le Sign-In Widget hébergé par Okta. Il s'agit de la configuration par défaut, et vous n'avez aucune personnalisation. Aucune modification n'est requise.

Sign-In Widget hébergé par Okta avec un domaine personnalisé

Les organisations avec des domaines personnalisés utilisent le Sign-In Widget hébergé par Okta, mais n'ont pas okta.com ou oktapreview.com dans l' URL de connexion . Pour localiser et tester les personnalisations dans votre Sign-In Widget, suivez les étapes suivantes.

  1. Dans Admin Console, allez à PersonnalisationsMarques.

  2. Sélectionnez une marque qui possède un domaine personnalisé, puis ouvrez son onglet Pages .
  3. Dans le panneau Page de connexion, cliquez sur Configurer.
  4. Dans Éditeur de code, recherchez les méthodes JavaScript obsolète. Si vous en trouvez, effectuez les modifications recommandées dans le guide.
  5. Recherchez des scripts CSS personnalisés ou un langage modifié. Si vous en trouvez, vous pouvez le tester en copiant le code et en le collant dans l'éditeur de code d'une organisation Identity Engine .

Une fois vos problèmes résolus, vous pourrez mettre à niveau la version du Sign-In Widget et procéder aux tests.

  1. Mettre à niveau le Sign-In Widget.
  2. Testez le flux de connexion dans une app et vérifiez que le Sign-In Widget mis à jour fonctionne comme prévu.

Sign-In Widget hébergé par le client

Le hub de mise à niveau OIE affiche un élément de confirmation s'il détecte un Sign-In Widgetintégré. Suivez les étapes suivantes pour découvrir où le Sign-In Widget est intégré.

  1. Dans Admin Console, allez à SécuritéAPI.

  2. Ouvrez l'onglet Origines approuvées.
  3. Filtrez le type de liste par CORS.
  4. Inspectez chaque URL enregistrée pour CORS. CORS est requis pour les flux d'authentification côté client (comme le Sign-In Widget ou le SDK JavaScript AuthJS). Toute URL qui apparaît est donc une implémentation possible.

Après avoir identifié l'endroit où le Sign-In Widget est intégré, vous pouvez mettre à niveau sa version et procéder aux tests.

  1. Mettre à niveau le Sign-In Widget.
  2. Testez le flux de connexion dans une app et vérifiez que le Sign-In Widget mis à jour fonctionne comme prévu.
  3. Créer un style pour votre page de connexion et mettre à jour les propriétés i18n.
  4. Consultez Modèle de déploiement - Okta Sign-in Widget intégré.

SDK hébergé par le client ou page de connexion personnalisée avec code côté serveur

Okta recommande de passer à l'un des autres modèles de déploiement avant de procéder à la mise à niveau. Identity Engine propose des branding, appels incorporés, et des appels d'événement avancés qui réduisent le besoin de SDK hébergé ou de code côté serveur.

Il s'agit du scénario le plus complexe. Le hub de mise à niveau OIE n'affiche pas toujours d'élément de reconnaissance pour les implémentations intégrées ou côté serveur (il est actuellement limité à l'utilisation d'API de session). Travaillez avec vos développeurs pour vous assurer que toutes les équipes qui gèrent les flux personnalisés d'authentification ou de récupération peuvent tester leur code avant la mise à niveau. Ces étapes peuvent vous aider à identifier où le code se trouve.

  1. Dans Admin Console, allez à Rapportsjournal système.

  2. Dans le champ Recherche, saisissez cette requête :

    client.userAgent.rawUserAgent pr and (debugContext.debugData.requestUri w "/api/v1/authn" ou debugContext.debugData.requestUri w "/api/v1/sessions" ou debugContext.debugData.requestUri w "/api/v1/ facteurs")

  3. Téléchargez les résultats au format CSV.
  4. Recherchez dans le CSV toute valeur raw.UserAgent qui ne provient pas d'un navigateur commun.
  5. Rechercher dans les journaux système des jetons API d'application fiables (System.Transaction.Detail.RequestApiToken).

Après avoir identifié l'endroit où le Sign-In Widget est intégré, travaillez avec vos développeurs pour vous préparer à la mise à niveau :

Rubriques liées

Modifications de la configuration du widget pour Identity Engine

Enregistrez votre expérience Classic Engine

Sign-In Widget