Créer des intégrations d'app OpenID Connect

Une intégration d'apps OpenID Connect (OIDC) fournit une couche d'identité en plus du protocole OAuth 2.0 pour vérifier l'identité des utilisateurs finaux et obtenir des informations liées à leur profil.

Okta prend en charge tous les paramètres du protocole OIDC. Pour afficher ces paramètres, consultez OpenID Connect & OAuth 2.0 API.

Avant de commencer

  • Pour en savoir plus sur la OpenID Connect Foundation (OIDF) et pour passer en revue toutes les caractéristiques du protocole, consultez la section Bienvenue dans OpenID Connect.
  • Choisissez une plateforme pour votre intégration d'applications. Vous pouvez choisir des applications Web, natives ou monopage (SPA).
    • Si votre app cible est une app Web ou une app native, déterminez si vous souhaitez utiliser les jetons d'actualisation.
    • Si votre app cible est une application monopage (SPA), déterminez la visibilité et le flux de connexion que vous souhaitez. Vous pouvez initier un flux de connexion en arrière-plan (sans vignette Okta), ou activer l'app ou Okta pour initier la demande de connexion.

      Si vous décidez que soit l'app, soit Okta peut initier la demande de connexion, deux options de flux s'offrent à vous :

      • Redirigez vers votre app OIDC pour lancer la demande de connexion. Cela correspond à la Section 4 de la spécification d'OpenID Connect. Lorsque les utilisateurs finaux cliquent sur une vignette Okta, ils sont redirigés vers l'URI initiate_login_uri de l'app client, qui crée une requête d'autorisation et redirige l'utilisateur final vers Okta.
      • Envoyez directement un jeton d'ID à votre app OIDC. C'est un flux plus simple. Okta crée un jeton d'ID et le publie directement sur le premier URI de redirection enregistré pour l'app cible. Ce flux est le même que celui des requêtes de connexion pour les applications SAML. Vous pouvez configurer les permissions OIDC à accorder. Ce flux utilise le mode de réponse form_post. Aucun paramètre d'état n'est inclus dans la requête, car il s'agit d'une requête à sens unique.
  • Assurez-vous que les points de terminaison des URI (Uniform Resource Identifier) de redirection sont fonctionnels. Un URI de redirection reçoit la réponse d'authentification et le jeton d'ID envoyés par Okta.

  • Si votre intégration d'app contient des liens vers des instructions, évitez les problèmes d'accès en ajoutant Okta à votre liste des sites qui peuvent toujours utiliser des cookies. Voir Atténuer l'impact de la dépréciation des cookies tiers.

Lancer l'assistant

  1. Dans Admin Console, accédez à ApplicationsApplications.

  2. Cliquez sur Créer une intégration d'application.
  3. Sélectionnez OIDC - OpenID Connect comme méthode de connexion.
  4. Choisissez le type d'app à intégrer à Okta :
    • Application Web
    • Application monopage
    • Application native
  5. Cliquez sur Suivant.

Configurer les paramètres généraux

L'assistant d'intégration d'application pour OIDC comporte trois sections :

  1. Paramètres généraux :
    • Nom de l'intégration d'application : précisez le nom de votre intégration d'application. Vous devez impérativement utiliser des caractères UTF-8 de 3 octets pour nommer l'intégration d'application.

      Okta attribue automatiquement un nom par défaut à votre intégration d'application en fonction de la plateforme que vous avez sélectionnée. Si une autre intégration d'application au sein de votre org Okta possède déjà le même nom par défaut, un chiffre sera ajouté au nom de l'intégration d'application pour différencier les intégrations ayant le même nom.

    • Notes d'application pour les utilisateurs finaux : saisissez du texte dans le champ pour afficher une note concernant l'app dans Okta End-User Dashboard.
    • Notes d'application pour les administrateurs : saisissez du texte dans le champ pour afficher une note sur l'app aux administrateurs sur la page de l'app OIDC.
    • Exiger l'en-tête Demonstrating Proof of Possession (DPoP) dans les requêtes de jeton : sélectionnez cette option pour exiger d'un client qu'il prouve la possession d'une paire de clés publique/privée pour les requêtes de jeton. Le serveur d'autorisations rejette les demandes de jeton de ce client qui ne contiennent pas l'en-tête DPoP. Vous ne pouvez pas sélectionner Implicite (hybride) dans les options Type d'autorisation lorsque vous exigez DPoP.
    • Type d'autorisation : sélectionnez les types d'autorisations que vous souhaitez utiliser. Cliquez sur Avancé pour afficher d'autres types d'autorisations. Voir Configurer les types d'autorisations de l'authentification directe pour obtenir la description de chaque type d'autorisation. Les types d'autorisations disponibles pour votre intégration d'application dépendent de la plateforme que vous avez sélectionnée. Voir Vue d'ensemble d'OAuth 2.0 et d'OpenID Connect.
    • URI de redirection de connexion : un URI de redirection de connexion reçoit la réponse d'authentification et le jeton d'ID envoyés par Okta pour la demande de connexion. Les URI doivent être des URI absolus.

      Vous pouvez spécifier plusieurs URI et les trier dans n'importe quel ordre. Les utilisateurs voient un message d'erreur s'afficher s'ils essaient de se connecter à un URI qui n'est pas enregistré avec votre intégration.

      Si votre client OIDC est configuré pour prendre en charge plusieurs sous-domaines, vous pouvez utiliser un URI unique avec un caractère générique. Choisissez Autoriser le caractère générique dans l'URI de redirection de connexion. Voir la section Apps API pour obtenir plus d'instructions de configuration concernant les caractères génériques.

      L'utilisation de caractères génériques dans les sous-domaines est déconseillée. Les caractères génériques peuvent permettre aux personnes malveillantes de rediriger l'envoi des jetons ou des codes d'autorisation vers des pages qu'elles contrôlent ou des pages inattendues.

    • Facultatif. URI de redirection de déconnexion : lorsque votre application contacte Okta pour fermer la session utilisateur, Okta redirige l'utilisateur vers cet URI. Les URI doivent être des URI absolus. Vous pouvez indiquer plusieurs URI. Vous ne pouvez pas utiliser de caractères génériques dans les sous-domaines pour les URI de redirection de déconnexion.

  2. Origines approuvées : configurez des options pour les intégrations d'apps Web et natives :
    • Facultatif. URI de base : indiquez un URI de base pour lequel vous souhaitez autoriser les demandes cross-origin vers les API Okta. Ces URI sont ajoutés aux origines approuvées de votre org Okta. Vous pouvez gérer ces URI de base dans SécuritéAPI et en sélectionnant l'onglet Origines approuvées. Voir Aperçu du partage des ressources cross-origin (CORS).
  3. Affectations : l'option par défaut vous permet d'affecter et d'accorder l'accès à cette intégration d'application à toutes les personnes de votre org Okta.
    • Accès contrôlé :
      • Limiter accès à des groupes sélectionnés : saisissez les noms des groupes auxquels vous souhaitez accorder l'accès.
      • Ignorer l'affectation de groupe pour le moment : créez l'app sans lui affecter de groupe.
  4. Cliquez sur Enregistrer. La page des paramètres s'affiche.

Lorsque vous ajoutez une intégration d'app depuis l'OIN, Okta génère un événement Mettre à jour l'application qui apparaît dans le System Log. Cet événement reflète la création d'une nouvelle instance d'une app existante.

Lorsque vous créez une app à l'aide de l'assistant d'intégration d'application (AIW), Okta génère un événement Créer une application qui apparaît dans le Journal système. Cet événement reflète la création d'une nouvelle app.

Configurer les paramètres OIDC

Les options de l'onglet Général sont identiques, quel que soit le type d'intégration OIDC. Cliquez sur Modifier pour modifier les options.

Apps Web

La section Identifiants client contient des informations importantes et indispensables pour les flux d'authentification.

  • ID de client : il s'agit de l'identificateur public, obligatoire pour tous les flux OAuth. Cet identificateur est généré de manière aléatoire lorsque vous créez l'intégration d'app.

  • Authentification client : choisissez la méthode à utiliser pour l'authentification client.
  • Proof Key for Code Exchange (PKCE) : indique si la défi du code PKCE est nécessaire pour vérifier les demandes de clients. Cette option est facultative pour les méthodes d'identification suivantes : Clé secrète client et Clé publique/Clé privée. Voir Changer la méthode d'authentification client si vous passez d'une clé secrète client à une clé publique ou clé privée.

  • Cliquez sur Enregistrer.

Dans la section Paramètres généraux, vous pouvez configurer les paramètres suivants :

Dans la section Application, configurez les détails de l'app :

  • Nom de l'intégration d'application : modifiez le nom si nécessaire.
  • Exiger l'en-tête Demonstrating Proof of Possession (DPoP) dans les requêtes de jeton: sélectionnez cette option pour exiger d'un client qu'il prouve qu'il possède une paire de clés publique/privée pour les requêtes de jeton. Le serveur d'autorisations rejette les demandes de jeton de ce client qui ne contiennent pas l'en-tête DPoP. Vous ne pouvez pas sélectionner Implicite (hybride) dans les options Type d'autorisation lorsque vous exigez DPoP.
  • Type d'autorisation : faites votre choix parmi les différents types d'autorisations.
    • Identifiants client : utilisez les identifiants du client pour un client agissant pour son propre compte.
    • Code d'autorisation : utilisez un code d'autorisation pour un client agissant pour le compte d'un utilisateur.
    • Jeton d'actualisation : effectuez une rotation de jetons après chaque utilisation ou utilisez un jeton persistant. Si vous choisissez d'effectuer une rotation de jetons après chaque utilisation, vous pourrez définir une période de validité qui détermine la durée pendant laquelle le jeton reste actif.
    • Autorisation d'appareil : utilisez l'autorisation d'appareil comme type d'autorisation pour un client agissant au nom d'un utilisateur.
    • Implicite (hybride): utilisez un type d'autorisation implicite pour un client agissant au nom d'un utilisateur. Sélectionnez le type de jeton que vous souhaitez utiliser :
      • Autoriser le jeton d'ID avec le type d'autorisation implicite
      • Autoriser le jeton d'accès avec le type d'autorisation implicite

Ajoutez ou retirez le consentement de l'utilisateur pour une intégration OIDC dans la section Consentement de l'utilisateur.

  • Exiger le consentement : sélectionnez cette option pour inviter l'utilisateur à approuver l'accès de l'intégration aux ressources spécifiques dans une fenêtre contextuelle. Vous pouvez configurer le consentement pour une permission OIDC dans votre autorisation personnalisée en suivant la procédure décrite à la section Créer des permissions d'accès aux API. Cette case à cocher n'apparait que si API Access Management d'Okta est activé pour votre org. Voir Demander le consentement de l'utilisateur.
  • URI des conditions d'utilisation : collez le lien où vous avez stocké le texte des conditions d'utilisation que vous souhaitez voir apparaître dans la fenêtre contextuelle de consentement.
  • URI de la politique : collez le lien où vous avez stocké le texte de la politique que vous souhaitez voir apparaître dans la fenêtre contextuelle de consentement.
  • URI du logo : collez le lien où vous avez stocké le logo que vous souhaitez voir apparaître dans la fenêtre contextuelle de consentement. Pour de meilleurs résultats, utilisez une image au format PNG, en mode paysage et avec un arrière-plan transparent. Utilisez une résolution minimale de 420 x 120 pixels pour éviter un agrandissement de l'image.

Dans la section Déconnexion, configurez les options de déconnexion des apps.

  • Connexion : configurez les URI pour la connexion et la déconnexion des apps.
  • URI de redirection de connexion : URI vers lequel Okta enverra les réponses OAuth. Saisissez un ou plusieurs URI.
  • Saisissez un ou plusieurs URI de redirection de connexion. C'est là qu'Okta redirige le navigateur après la déconnexion de la partie de confiance et la fin de la session utilisateur final. Saisissez un ou plusieurs URI.

  • Connexion initiée par : indiquez si le processus de connexion est initié directement par l'application en arrière-plan, ou si l'application ou Okta peut initier la demande de connexion.

    • Application uniquement : l'app démarre en arrière-plan et la vignette Okta n'apparaît pas.

    • Si vous choisissez Okta ou l'application, votre intégration utilisera une vignette Okta :

      • Visibilité de l'application : sélectionnez si vous souhaitez que l'app soit visible ou non pour les utilisateurs finaux .
      • Flux de connexion : sélectionnez une option :
      • Si vous choisissez Envoyer le jeton d'identificateur directement à l'application (Okta simplifié), vous pourrez également choisir les permissions OIDC pour le flux.
      • Implicite : une section Lien d'intégration de l'application apparaît en bas de la page des paramètres. L'URL que vous pouvez utiliser pour la connexion au client OIDC en dehors d'Oktas'affiche.
    • URI d'initiation de connexion : utilisé pour initier une demande de connexion. Lorsqu'Okta est redirigé vers ce point de terminaison, cela déclenche l'envoi d'une requête d'autorisation par le client. Saisissez ou modifiez l'URI.
  • Cliquez sur Enregistrer.

Applications monopages

La section Identifiants client contient des informations importantes et indispensables pour les flux d'authentification.

  • ID de client : il s'agit de l'identificateur public, obligatoire pour tous les flux OAuth. Cet identificateur est généré de manière aléatoire lorsque vous créez l'intégration d'application.

  • Authentification client : choisissez la méthode à utiliser pour l'authentification client.

    • Aucune : méthode par défaut pour les intégrations des applications monopages. Cette option nécessite une Clé de vérification pour l'échange de code (PKCE) pour effectuer une vérification supplémentaire. La PKCE garantit que seul le client qui a demandé le jeton d'accès peut l'utiliser.

  • Clé de vérification pour l'échange de code (PKCE) : indique si le défi du code PKCE est nécessaire pour vérifier les demandes de clients. Si la méthode d'authentification que vous choisissez est Aucune, un défi PKCE est requis par défaut. La vérification du code PKCE est facultative pour les méthodes d'authentification Clé secrète client et Clé publique/Clé privée. Si vous avez modifié la méthode d'authentification de votre client, consultez Modifier les méthodes d'authentification client pour en savoir plus sur la façon dont les clés secrètes client et clés existantes sont affectées.

  • Cliquez sur Enregistrer.

Dans la section Paramètres généraux, vous pouvez configurer les paramètres suivants :

Dans la section Application, configurez les détails de app .

  • Nom de l'intégration d'application : modifiez le nom si nécessaire.

  • Type d'autorisation : faites votre choix parmi les différents types d'autorisations.

    • Code d'autorisation : utilisez un code d'autorisation comme type d'autorisation pour un client agissant au nom d'un utilisateur.
    • Jeton d'actualisation : changez de jeton après chaque utilisation ou utilisez un jeton persistant. Si vous choisissez d'effectuer une rotation de jetons après chaque utilisation, vous pourrez définir une période de validité qui détermine la durée pendant laquelle le jeton reste actif.
    • Autorisation d'appareil : utilisez l'autorisation d'appareil comme type d'autorisation pour un client agissant au nom d'un utilisateur.
    • Implicite (hybride): utilisez un type d'autorisation implicite pour un client agissant au nom d'un utilisateur. Sélectionnez le type de jeton que vous souhaitez utiliser :
      • Autoriser le jeton d'ID avec le type d'autorisation implicite
      • Autoriser le jeton d'accès avec le type d'autorisation implicite
  • Exiger l'en-tête Demonstrating Proof of Possession (DPoP) dans les requêtes de jeton: sélectionnez cette option pour exiger d'un client qu'il prouve la possession d'une paire de clés publique/privée pour les requêtes de jeton. Le serveur d'autorisations rejette les demandes de jeton de ce client qui ne contiennent pas l'en-tête DPoP. Vous ne pouvez pas sélectionner Implicite (hybride) dans les options Type d'autorisation lorsque vous exigez DPoP.

Ajoutez ou retirez le consentement de l'utilisateur pour une intégration OIDC dans la section Consentement de l'utilisateur.

  • Consentement de l'utilisateur :
    • Exiger le consentement : sélectionnez cette option pour inviter l'utilisateur à approuver l'accès de l'intégration aux ressources spécifiques dans une fenêtre contextuelle. Vous pouvez configurer le consentement pour une permission OIDC dans votre autorisation personnalisée en suivant la procédure décrite à la section Créer des permissions d'accès aux API. Cette case à cocher n'apparait que si API Access Management d'Okta est activé pour votre org. Voir Demander le consentement de l'utilisateur.
    • URI des conditions d'utilisation : collez le lien où vous avez stocké le texte des conditions d'utilisation que vous souhaitez voir apparaître dans la fenêtre contextuelle de consentement.
    • URI de la politique : collez le lien où vous avez stocké le texte de la politique que vous souhaitez voir apparaître dans la fenêtre contextuelle de consentement.
    • URI du logo : collez le lien où vous avez stocké le logo que vous souhaitez voir apparaître dans la fenêtre contextuelle de consentement. Pour de meilleurs résultats, utilisez une image au format PNG, en mode paysage et avec un arrière-plan transparent. Utilisez une résolution minimale de 420 x 120 pixels pour éviter un agrandissement de l'image.

Dans la section Connexion, configurez les détails de connexion.

  • Connexion : configurez les URI pour la connexion et la déconnexion des applications.
    • URI de redirection de connexion : URI vers lequel Okta enverra les réponses OAuth. Saisissez un ou plusieurs URI.
    • Saisissez un ou plusieurs URI de redirection de connexion. C'est là qu'Okta redirige le navigateur après la déconnexion de la partie de confiance et la fin de la session utilisateur final. Saisissez un ou plusieurs URI.
  • Connexion initiée par : indiquez si le processus de connexion est initié directement par l'application en arrière-plan, ou si l'application ou Okta peut initier la demande de connexion.

    • Application uniquement : l'app démarre en arrière-plan et la vignette Okta n'apparaît pas.

    • Si vous choisissez Okta ou l'application, votre intégration utilisera une vignette Okta :

      • Visibilité de l'application : sélectionnez si vous souhaitez que l'app soit visible ou non pour les utilisateurs finaux .
      • Flux de connexion : sélectionnez une option :
      • Si vous choisissez Envoyer le jeton d'identificateur directement à l'application (Okta simplifié), vous pourrez également choisir les permissions OIDC pour le flux.
      • Implicite : une section Lien d'intégration de l'application apparaît en bas de la page des paramètres. L'URL que vous pouvez utiliser pour la connexion au client OIDC en dehors d'Oktas'affiche.
    • URI d'initiation de connexion : utilisé pour initier une demande de connexion. Lorsqu'Okta est redirigé vers ce point de terminaison, cela déclenche l'envoi d'une requête d'autorisation par le client. Saisissez ou modifiez l'URI.
  • Cliquez sur Enregistrer.

Applications natives

La section Identifiants client contient des informations importantes et indispensables pour les flux d'authentification.

  • ID de client : il s'agit de l'identificateur public, obligatoire pour tous les flux OAuth. Cet identificateur est généré de manière aléatoire lorsque vous créez l'intégration d'application.
  • Authentification client : choisissez la méthode à utiliser pour l'authentification client.
    • Aucune : méthode recommandée pour les applications natives. Cette option nécessite une Clé de vérification pour l'échange de code (PKCE) pour effectuer une vérification supplémentaire. La PKCE garantit que seul le client qui a demandé le jeton d'accès peut l'utiliser.
    • Clé secrète client : un panneau vous permettant de générer une clé secrète client que le client devra utiliser s'affichera. Ces données ne sont connues que d'Okta et de votre intégration d'application. Cliquez sur Enregistrer pour générer la clé secrète client. Vous pouvez afficher ou copier la clé secrète client. Si vous disposez d'une seconde clé secrète client, vous pouvez modifier le statut pour sélectionner la clé secrète active. Voir la section Changer une clé secrète client en créant une seconde clé secrète client.
    • Clé publique/Clé privée : si vous choisissez cette option, un panneau vous permettant de générer ou d'ajouter une paire de clés publique/privée à utiliser pour la connexion client s'affichera. Voir Gérer les clés secrètes et les clés pour l'authentification client des applications OIDC.
  • Clé de vérification pour l'échange de code (PKCE) : indique si le défi du code PKCE est nécessaire pour vérifier les demandes de clients. Si la méthode d'authentification que vous choisissez est Aucune, un défi PKCE est requis par défaut. La vérification du code PKCE est facultative pour les méthodes d'authentification Clé secrète client et Clé publique/Clé privée. Si vous avez modifié la méthode d'authentification de votre client, consultez Modifier les méthodes d'authentification client pour en savoir plus sur la façon dont les clés secrètes client et clés existantes sont affectées.
  • Cliquez sur Enregistrer.

Dans la section Paramètres généraux, vous pouvez configurer les paramètres suivants :

Dans la section Application, configurez les détails de app .

  • Nom de l'intégration d'application : modifiez le nom si nécessaire.

  • Type d'autorisation : faites votre choix parmi les différents types d'autorisations.

    • Code d'autorisation : utilisez un code d'autorisation comme type d'autorisation pour un client agissant au nom d'un utilisateur.
    • Code d'interaction: utilisez un code d'interaction comme type d'autorisation pour un client agissant au nom d'un utilisateur.
    • Jeton d'actualisation : changez de jeton après chaque utilisation ou utilisez un jeton persistant. Si vous choisissez d'effectuer une rotation des jetons après chaque utilisation, vous pourrez définir une période de validité qui détermine la durée pendant laquelle le jeton reste actif.
    • Mot de passe du propriétaire de la ressource : utilisez le mot de passe du propriétaire de la ressource comme type d'autorisation pour un client agissant au nom d'un utilisateur.
    • Assertion SAML 2.0: utilisez une assertion SAML 2.0 comme type d'autorisation pour un client agissant au nom d'un utilisateur.
    • Autorisation d'appareil : utilisez l'autorisation d'appareil comme type d'autorisation pour un client agissant au nom d'un utilisateur.
    • Échange de jeton : utilisez un échange de jeton comme type d'autorisation pour un client agissant pour le compte d'un utilisateur.
    • Implicite (hybride): utilisez un type d'autorisation implicite pour un client agissant au nom d'un utilisateur. Sélectionnez le type de jeton que vous souhaitez utiliser :
      • Autoriser le jeton d'ID avec le type d'autorisation implicite
      • Autoriser le jeton d'accès avec le type d'autorisation implicite
  • Exiger l'en-tête Demonstrating Proof of Possession (DPoP) dans les requêtes de jeton: sélectionnez cette option pour exiger d'un client qu'il prouve la possession d'une paire de clés publique/privée pour les requêtes de jeton. Le serveur d'autorisations rejette les demandes de jeton de ce client qui ne contiennent pas l'en-tête DPoP. Vous ne pouvez pas sélectionner Implicite (hybride) dans les options Type d'autorisation lorsque vous exigez DPoP.

Ajoutez ou retirez le consentement de l'utilisateur pour une intégration OIDC dans la section Consentement de l'utilisateur.

  • Consentement de l'utilisateur :
    • Exiger le consentement : sélectionnez cette option pour inviter l'utilisateur à approuver l'accès de l'intégration aux ressources spécifiques dans une fenêtre contextuelle. Vous pouvez configurer le consentement pour une permission OIDC dans votre autorisation personnalisée en suivant la procédure décrite à la section Créer des permissions d'accès aux API. Cette case à cocher n'apparait que si API Access Management d'Okta est activé pour votre org. Voir Demander le consentement de l'utilisateur.
    • URI des conditions d'utilisation : collez le lien où vous avez stocké le texte des conditions d'utilisation que vous souhaitez voir apparaître dans la fenêtre contextuelle de consentement.
    • URI de la politique : collez le lien où vous avez stocké le texte de la politique que vous souhaitez voir apparaître dans la fenêtre contextuelle de consentement.
    • URI du logo : collez le lien où vous avez stocké le logo que vous souhaitez voir apparaître dans la fenêtre contextuelle de consentement. Pour de meilleurs résultats, utilisez une image au format PNG, en mode paysage et avec un arrière-plan transparent. Utilisez une résolution minimale de 420 x 120 pixels pour éviter un agrandissement de l'image.

Dans la section Connexion, configurez les détails de connexion.

  • Connexion : configurez les URI pour la connexion et la déconnexion des applications.
    • URI de redirection de connexion : URI vers lequel Okta enverra les réponses OAuth. Saisissez un ou plusieurs URI.
    • Saisissez un ou plusieurs URI de redirection de connexion. C'est là qu'Okta redirige le navigateur après la déconnexion de la partie de confiance et la fin de la session utilisateur final. Saisissez un ou plusieurs URI.
    • Saisissez ou modifiez l'URI d'initiation de connexion utilisé pour initier une demande de connexion. Lorsqu'Okta est redirigé vers ce point de terminaison, cela déclenche l'envoi d'une requête d'autorisation par le client. Saisissez ou modifiez l'URI.
  • Cliquez sur Enregistrer.

Configurer les paramètres facultatifs

Vous pouvez éventuellement configurer un filtre de demandes de groupe, configurer des droits, définir des limites d'utilisation d'application et définir l'émetteur.

Configurer le filtre Demandes de groupes

  1. Accédez à l'onglet Authentification et faites défiler la page vers le bas jusqu'à la section Jeton d'ID OpenID Connect.

  2. Sélectionnez le Type de demande de groupes. Vous pouvez soit choisir un filtre pour les demandes de groupe existantes, soit choisir une expression pour créer un filtre personnalisé pour une demande de groupe différente.

    L'API ne peut pas créer de jetons d'ID si ces deux conditions apparaissent dans votre configuration :

    • Plus de 100 groupes correspondent au filtre de demandes de groupes.
    • Vous utilisez n'importe quel type d'autorisation, sauf Code d'autorisation ou Code d'autorisation avec PKCE .

    Pour en savoir plus sur les demandes de groupes pour la SSO, voir Personnaliser les jetons renvoyés par Okta.

Définir les limites d'utilisation des applications

Vous pouvez configurer une limite d'utilisation pour des applications OAuth 2.0 individuelles. Par défaut, les nouvelles applications consomment 50 % des limites d'utilisation de chaque API.

  1. Dans l'onglet Limites d'utilisation des applications, cliquez sur Modifier.
  2. Positionnez le curseur sur le pourcentage de votre choix.
  3. Cliquez sur Enregistrer.

Voir Tableau de bord des limites d'utilisation.

Définir l'émetteur

Si vous avez activé et défini un domaine d'URL personnalisé, le champ Émetteur par défaut est l'URL personnalisée qui s'affiche au format URL personnalisée (https://id.example.com). Dans le champ, utilisez la flèche du menu déroulant pour sélectionner l'URL de l'organisation.

Vous pouvez aussi choisir Dynamique, ce qui vous permet d'utiliser le domaine organisationnel ou le domaine personnalisé, en fonction du domaine de la demande.

Étapes suivantes