Aller au contenu principal

Structure des données d’application

Introduction​

Dans Logto, une application désigne un programme ou service logiciel spécifique qui est enregistré sur la plateforme Logto et qui a reçu l’autorisation d’accéder aux informations utilisateur ou d’effectuer des actions au nom d’un utilisateur. Les applications servent à identifier la source des requêtes faites à l’API Logto, ainsi qu’à gérer le processus d’authentification (Authentification) et d’autorisation (Autorisation) pour les utilisateurs accédant à ces applications.

L’utilisation des applications dans l’expérience de connexion Logto permet aux utilisateurs d’accéder facilement à leurs applications autorisées et de les gérer depuis un emplacement unique, avec un processus d’authentification cohérent et sécurisé. Cela contribue à simplifier l’expérience utilisateur et à garantir que seules les personnes autorisées accèdent à des informations sensibles ou effectuent des actions au nom de l’organisation (Organisation).

Les applications sont également utilisées dans les journaux d’audit de Logto pour suivre l’activité des utilisateurs et identifier toute menace ou violation potentielle de sécurité. En associant des actions spécifiques à une application particulière, Logto peut fournir des informations détaillées sur la façon dont les données sont consultées et utilisées, permettant ainsi aux organisations (Organisations) de mieux gérer leurs exigences de sécurité et de conformité. Si vous souhaitez intégrer votre application à Logto, consultez Intégrer Logto.

Propriétés​

ID d’application​

L’ID d’application est une clé unique générée automatiquement pour identifier votre application dans Logto, et est référencée comme client id dans OAuth 2.0.

Types d’application​

Une application peut être l’un des types suivants :

  • Application native : une application qui s’exécute dans un environnement natif. Par exemple, application iOS, application Android.
  • Application monopage (SPA) : une application qui s’exécute dans un navigateur web, qui met à jour la page avec de nouvelles données du serveur sans recharger entièrement la page. Par exemple, application React DOM, application Vue.
  • Application web traditionnelle : une application qui rend et met à jour les pages uniquement via le serveur web. Par exemple, JSP, PHP.
  • Application machine à machine (M2M) : une application qui s’exécute dans un environnement machine pour une communication directe service à service sans interaction utilisateur.

Secret d’application​

Le secret d’application est une clé utilisée pour authentifier l’application dans le système d’authentification (Authentification), spécifiquement pour les clients privés (applications web traditionnelles et M2M) en tant que barrière de sécurité privée.

astuce:

Les applications monopage (SPA) et les applications natives ne fournissent pas de secret d’application. Les SPA et les applications natives sont des "clients publics" et ne peuvent pas conserver de secrets (le code du navigateur ou les bundles d’application sont inspectables). Au lieu d’un secret d’application, Logto les protège avec PKCE, une validation stricte des URI de redirection / CORS, des jetons d’accès (Jetons d’accès) à courte durée de vie et la rotation des jetons de rafraîchissement (Jetons de rafraîchissement).

Nom de l’application​

Le nom de l’application est un nom lisible par l’homme de l’application et sera affiché dans la console d’administration.

Le nom de l’application est un élément important de la gestion des applications dans Logto, car il permet aux administrateurs d’identifier facilement et de suivre l’activité des applications individuelles sur la plateforme.

remarque:

Il est important de noter que le nom de l’application doit être choisi avec soin, car il sera visible par tous les utilisateurs ayant accès à la console d’administration. Il doit refléter avec précision le but et la fonction de l’application, tout en étant facile à comprendre et à reconnaître.

Description​

Une brève description de l’application sera affichée sur la page de détails de l’application dans la console d’administration. La description vise à fournir aux administrateurs des informations supplémentaires sur l’application, telles que son objectif, ses fonctionnalités et tout autre détail pertinent.

URI de redirection​

Les URI de redirection sont une liste d’URI de redirection valides qui ont été préconfigurées pour une application. Lorsqu’un utilisateur se connecte à Logto et tente d’accéder à l’application, il est redirigé vers l’un des URI autorisés spécifiés dans les paramètres de l’application.

La liste des URI autorisés est utilisée pour valider l’URI de redirection inclus dans la requête d’autorisation (Requête d’autorisation) envoyée par l’application à Logto lors du processus d’authentification (Authentification). Si l’URI de redirection spécifié dans la requête d’autorisation correspond à l’un des URI autorisés dans les paramètres de l’application, l’utilisateur est redirigé vers cet URI après une authentification réussie. Si l’URI de redirection ne figure pas dans la liste autorisée, l’utilisateur ne sera pas redirigé et le processus d’authentification échouera.

remarque:

Il est important de s’assurer que tous les URI de redirection valides sont ajoutés à la liste autorisée pour une application dans Logto, afin de garantir que les utilisateurs puissent accéder à l’application après authentification.

Vous pouvez consulter le point de terminaison de redirection pour plus d’informations.

Comprendre les URI de redirection dans OIDC avec le flux de code d’autorisation

Modèles génériques (wildcards)​

Disponibilité : Application monopage, application web traditionnelle

Les URI de redirection prennent en charge les modèles génériques (*) pour les environnements dynamiques tels que les déploiements de prévisualisation. Les wildcards peuvent être utilisés dans les composants hostname et pathname des URI HTTP / HTTPS.

Règles :

  • Les wildcards ne sont autorisés que dans le hostname et le pathname
  • Les wildcards ne sont pas autorisés dans le schéma, le port, les paramètres de requête ou les fragments de hachage
  • Les wildcards dans le hostname doivent inclure au moins un point (par exemple, https://*.example.com/callback)

Exemples :

  • https://*.example.com/callback - correspond à n’importe quel sous-domaine
  • https://preview-*.example.com/callback - correspond aux déploiements de prévisualisation
  • https://example.com/*/callback - correspond à n’importe quel segment de chemin
attention:

Les URI de redirection avec wildcards ne sont pas standard OIDC et peuvent augmenter la surface d’attaque. À utiliser avec précaution et privilégier les URI de redirection exacts autant que possible.

URI de redirection après déconnexion​

Les URI de redirection après déconnexion sont une liste d’URI valides qui ont été préconfigurées pour une application afin de rediriger l’utilisateur après sa déconnexion de Logto.

L’utilisation des URI de redirection après déconnexion autorisées pour la déconnexion fait partie de la spécification RP-Initiated (déconnexion initiée par la partie de confiance) dans OIDC. Cette spécification fournit une méthode standardisée permettant aux applications d’initier une demande de déconnexion pour un utilisateur, ce qui inclut la redirection de l’utilisateur vers un point de terminaison préconfiguré après sa déconnexion.

Lorsqu’un utilisateur se déconnecte de Logto, sa session est terminée et il est redirigé vers l’un des URI autorisés spécifiés dans les paramètres de l’application. Cela garantit que l’utilisateur est dirigé uniquement vers des points de terminaison autorisés et valides après sa déconnexion, ce qui aide à prévenir les accès non autorisés et les risques de sécurité liés à la redirection des utilisateurs vers des points de terminaison inconnus ou non vérifiés.

Vous pouvez consulter la déconnexion initiée par le RP pour plus d’informations.

Origines autorisées CORS​

Les origines autorisées CORS (Cross-origin resource sharing) sont une liste d’origines autorisées à partir desquelles une application peut effectuer des requêtes vers le service Logto. Toute origine qui ne figure pas dans la liste autorisée ne pourra pas effectuer de requêtes vers le service Logto.

La liste des origines autorisées CORS est utilisée pour restreindre l’accès au service Logto depuis des domaines non autorisés, et pour aider à prévenir les attaques CSRF (Cross-site request forgery). En spécifiant les origines autorisées pour une application dans Logto, le service peut s’assurer que seuls les domaines autorisés peuvent effectuer des requêtes vers le service.

remarque:

La liste des origines autorisées doit contenir l’origine où l’application sera servie. Cela garantit que les requêtes provenant de l’application sont autorisées, tandis que les requêtes provenant d’origines non autorisées sont bloquées.

Point de terminaison de configuration du fournisseur OpenID​

Le point de terminaison pour la découverte OpenID Connect.

Point de terminaison d’autorisation​

Le point de terminaison d’autorisation est un terme OIDC, et c’est un point de terminaison requis utilisé pour initier le processus d’authentification (Authentification) pour un utilisateur. Lorsqu’un utilisateur tente d’accéder à une ressource ou application protégée enregistrée sur la plateforme Logto, il sera redirigé vers le point de terminaison d’autorisation pour authentifier son identité et obtenir l’autorisation (Autorisation) d’accéder à la ressource demandée.

Vous pouvez consulter le point de terminaison d’autorisation pour plus d’informations.

Point de terminaison de jeton​

Le point de terminaison de jeton est un terme OIDC, c’est un point de terminaison d’API web utilisé par un client OIDC pour obtenir un jeton d’accès (Jeton d’accès), un jeton d’identifiant (Jeton d’identifiant) ou un jeton de rafraîchissement (Jeton de rafraîchissement) auprès d’un fournisseur OIDC.

Lorsqu’un client OIDC a besoin d’obtenir un jeton d’accès ou un jeton d’identifiant, il envoie une requête au point de terminaison de jeton avec une autorisation, qui est généralement un code d’autorisation ou un jeton de rafraîchissement. Le point de terminaison de jeton valide alors l’autorisation et délivre un jeton d’accès ou un jeton d’identifiant au client si l’autorisation est valide.

Vous pouvez consulter le point de terminaison de jeton pour plus d’informations.

Point de terminaison Userinfo​

Le point de terminaison UserInfo OpenID Connect.

Toujours émettre un jeton de rafraîchissement​

Disponibilité : Web traditionnel, SPA

Lorsqu’il est activé, Logto émettra toujours des jetons de rafraîchissement (Jetons de rafraîchissement), que prompt=consent soit présenté ou non dans la requête d’authentification (Requête d’authentification), ni offline_access dans les portées (Portées).

Cependant, cette pratique est déconseillée sauf nécessité (généralement utile pour certaines intégrations OAuth tierces qui nécessitent un jeton de rafraîchissement), car elle n’est pas compatible avec OpenID Connect et peut potentiellement causer des problèmes.

Rotation du jeton de rafraîchissement​

Défaut : true

Lorsqu’elle est activée, Logto émettra un nouveau jeton de rafraîchissement (Jeton de rafraîchissement) pour les requêtes de jeton dans les conditions suivantes :

  • Si le jeton de rafraîchissement a été renouvelé (sa durée de vie prolongée par l’émission d’un nouveau) pendant un an ; OU
  • Si le jeton de rafraîchissement approche de sa date d’expiration (>=70% de sa durée de vie initiale écoulée) ; OU
  • Si le client est un client public, par exemple une application native ou une application monopage (SPA).
remarque:

Pour les clients publics, lorsque cette fonctionnalité est activée, un nouveau jeton de rafraîchissement sera toujours émis lorsque le client échange un nouveau jeton d’accès (Jeton d’accès) à l’aide du jeton de rafraîchissement. Bien que vous puissiez désactiver cette fonctionnalité pour ces clients publics, il est fortement recommandé de la laisser activée pour des raisons de sécurité.

Comprendre la rotation des jetons de rafraîchissement

Durée de vie (TTL) du jeton de rafraîchissement en jours​

Disponibilité : Pas SPA ; Défaut : 14 jours

La durée pendant laquelle un jeton de rafraîchissement (Jeton de rafraîchissement) peut être utilisé pour demander de nouveaux jetons d’accès (Jetons d’accès) avant d’expirer et de devenir invalide. Les requêtes de jeton prolongeront la durée de vie du jeton de rafraîchissement à cette valeur.

En général, une valeur plus basse est préférable.

Remarque : Le renouvellement du TTL n’est pas disponible dans les SPA (application monopage) pour des raisons de sécurité. Cela signifie que Logto ne prolongera pas la durée de vie via les requêtes de jeton. Pour améliorer l’expérience utilisateur, vous pouvez activer la fonctionnalité "Rotation du jeton de rafraîchissement", permettant à Logto d’émettre un nouveau jeton de rafraîchissement lorsque nécessaire.

Jeton de rafraîchissement et liaison de session:

Lorsqu’un jeton de rafraîchissement est émis sans la portée offline_access dans la requête d’autorisation (Requête d’autorisation), il sera lié à la session utilisateur. La session a une durée de vie fixe de 14 jours. Après l’expiration de la session, le jeton de rafraîchissement devient invalide, quelle que soit sa propre durée de vie.

Pour que la durée de vie du jeton de rafraîchissement soit pleinement effective, assurez-vous d’inclure la portée offline_access dans votre requête d’autorisation.

URI de déconnexion backchannel​

Le point de terminaison de déconnexion backchannel OpenID Connect. Voir Déconnexion fédérée : déconnexion back-channel pour plus d’informations.

Données personnalisées​

Informations supplémentaires personnalisées sur l’application non listées dans les propriétés prédéfinies de l’application ; les utilisateurs peuvent définir leurs propres champs de données personnalisées selon leurs besoins spécifiques, tels que des paramètres et configurations propres à leur activité.