Préparer 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, il est dirigé vers l'app. La préparation est simple pour les modèles de redirection.
  • Intégré : L'utilisateur ne quitte jamais l'app. 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 org inclut okta.comou 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 orgs 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 l'Admin Console, accédez à Personnalisations > Marques.

  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ètes. 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 l'Admin Console, accédez à 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éez un style pour votre page de connexionet mettez à jour les propriétés i18n.
  4. Consultez Modèle de déploiement - Okta Sign-in Widget intégré.

SDK d'authentification hébergé par le client

Le hub de mise à niveau OIE affiche une action élément de reconnaissance s'il détecte l'utilisation d'un SDK d'authentification intégré dans votre votre org. Travaillez avec vos développeurs pour vous assurer que toutes les équipes qui ont recours à des SDK d'authentification peuvent tester leur code avant la mise à niveau. Ces étapes peuvent vous aider à identifier si le SDK est utilisé.

  1. Dans l'Admin Console, accédez à Rapports > Journal système.

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

    client.userAgent.rawUserAgent pr and (debugContext.debugData.requestUri sw "/api/v1/authn" or debugContext.debugData.requestUri sw "/api/v1/sessions" or debugContext.debugData.requestUri sw "/api/v1/factors")

  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'app fiables (System.Transaction.Detail.RequestApiToken).

Après avoir identifié l'endroit où le SDK est utilisé, travaillez avec vos développeurs pour vous préparer à la mise à niveau. Classic Engine Les SDK ont une prise en charge limitée avec Identity Engine. Si vous souhaitez continuer à utiliser les SDK Okta intégrés, terminez la mise à niveau, puis mettez à jour les SDK Identity Engine . Consultez Mettre à niveau votre application vers le SDK Identity Engine.

Consultez Modèle de déploiement –­ SDK Okta intégré.

API d'authentification hébergé par le client

Le hub de mise à niveau OIE affiche un élément d'action de la reconnaissance s'il détecte l'utilisation de l'API d'authentification directe dans votre org. Travaillez avec vos développeurs pour vous assurer que toutes les équipes qui ont recours à des API d'authentification peuvent tester leur code avant la mise à niveau. Ces étapes peuvent vous aider à identifier si l'API est utilisé.

  1. Dans l'Admin Console, accédez à Rapports > Journal système.

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

    client.userAgent.rawUserAgent pr and (debugContext.debugData.requestUri sw "/api/v1/authn" or debugContext.debugData.requestUri sw "/api/v1/sessions" or debugContext.debugData.requestUri sw "/api/v1/factors")

  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ù l'API est utilisé, travaillez avec vos développeurs pour vous préparer à la mise à niveau. L'API Classic Engine /authn ne fonctionne pas avec Identity Engine. Si vous souhaitez continuer à utiliser les API d'authentification, consultez Configurer les types d'autorisation pour l'authentification directe.

Consultez le Modèle de déploiement : Authentication API intégrée.