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 et d’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.
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 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 device flow : un type spécial d’application native pour les appareils à saisie limitée ou les applications sans interface (par exemple, téléviseurs intelligents, consoles de jeux, outils CLI, appareils IoT). Elle utilise le OAuth 2.0 Device Authorization Grant au lieu du flux standard basé sur la redirection. Voir Démarrage rapide device flow pour plus de détails.
- 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, spécifiquement pour les clients privés (applications web traditionnelles et M2M) en tant que barrière de sécurité privée.
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 à durée de vie courte et la rotation des jetons de rafraîchissement.
Nom de l’application
Le nom de l’application est un nom lisible par l’humain 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.
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 fidèlement 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 envoyée par l’application à Logto lors du processus d’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.
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 en OIDC avec le flux Authorization Code
Modèles génériques (wildcard)
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 jokers peuvent être utilisés dans les composants hostname et pathname des URI HTTP / HTTPS.
Règles :
- Les jokers ne sont autorisés que dans le hostname et le pathname
- Les jokers ne sont pas autorisés dans le schéma, le port, les paramètres de requête ou les fragments de hachage
- Les jokers 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-domainehttps://preview-*.example.com/callback- correspond aux déploiements de prévisualisationhttps://example.com/*/callback- correspond à n’importe quel segment de chemin
Les URI de redirection génériques 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 (Relying Party Initiated) Logout 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, contribuant ainsi à 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.
La liste des origines autorisées doit contenir l’origine à partir de laquelle 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 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 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, un jeton d’identifiant ou un 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, que prompt=consent soit présenté dans la requête d’authentification ou non, et que offline_access soit inclus dans les portées ou non.
Cependant, cette pratique est déconseillée sauf nécessité (elle est 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 peut émettre un nouveau jeton de rafraîchissement lorsqu’un client utilise un jeton de rafraîchissement pour demander de nouveaux jetons. Si le jeton de rafraîchissement et sa subvention d’application sont toujours valides, la politique de rotation par défaut est la suivante :
- Les jetons de rafraîchissement ne peuvent être rotés que tant que la chaîne de jetons de rafraîchissement existe depuis moins d’un an. Il s’agit d’une limite de sécurité interne ; la durée de vie propre du jeton de rafraîchissement ou celle de la subvention d’application peut expirer plus tôt. Une fois la limite atteinte, Logto ne fait plus tourner le jeton de rafraîchissement, et l’expiration du jeton actuel est définitive.
- Pour les clients publics qui n’utilisent pas de jetons de rafraîchissement liés à l’expéditeur (par exemple, applications natives classiques et applications monopage), Logto fait tourner le jeton de rafraîchissement à chaque demande de jeton de rafraîchissement tant que la rotation est autorisée.
- Pour les autres clients, Logto fait tourner le jeton de rafraîchissement uniquement lorsqu’il est proche de l’expiration (>=70 % de sa durée de vie initiale écoulée).
Pour les clients publics, il est fortement recommandé de garder la rotation du jeton de rafraîchissement activée pour des raisons de sécurité.
Les jetons de rafraîchissement liés à l’expéditeur sont associés à une clé de preuve ou un certificat détenu par le client. Pour les SPA classiques, la rotation émet un nouveau jeton de rafraîchissement mais n’étend pas la durée de vie du jeton de rafraîchissement. Le nouveau jeton hérite de la durée de vie restante du jeton précédent.
Les jetons de rafraîchissement sont associés à une subvention d’application. La durée de vie par défaut d’une subvention Logto est de 180 jours. Lorsque la subvention expire, les demandes de jeton de rafraîchissement échouent et le jeton de rafraîchissement ne peut plus être utilisé pour obtenir de nouveaux jetons, même si la rotation est activée.
Cela signifie que la durée de vie maximale pratique d’une autorisation basée sur un jeton de rafraîchissement est actuellement limitée par la durée de vie de la subvention, la révocation explicite ou l’expiration propre du jeton de rafraîchissement, selon ce qui arrive en premier.
Comprendre la rotation du jeton de rafraîchissement
Durée de vie (TTL) du jeton de rafraîchissement en jours
Disponibilité : Application native, Web traditionnel, SPA ; Défaut : 14 jours ; Maximum : 180 jours
La durée pendant laquelle un jeton de rafraîchissement peut être utilisé pour demander de nouveaux jetons d’accès avant d’expirer et de devenir invalide. Les demandes 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.
Le rafraîchissement du TTL n’est pas disponible dans les applications monopage (SPA) pour des raisons de sécurité. Pour les SPA, ce paramètre contrôle la durée de vie fixe du jeton de rafraîchissement à partir de l’émission initiale. Logto n’étendra pas la durée de vie via les demandes de jeton, et la rotation du jeton de rafraîchissement n’empêche pas l’expiration des jetons de rafraîchissement SPA.
Le TTL du jeton de rafraîchissement n’est pas la seule limite d’expiration. Les jetons de rafraîchissement sont liés à une subvention d’application, et la durée de vie par défaut d’une subvention Logto est de 180 jours. Lorsque la subvention expire, les demandes de jeton de rafraîchissement échouent même si le jeton de rafraîchissement serait encore valide.
Pour les clients où les demandes de jeton rafraîchissent le TTL du jeton de rafraîchissement, le TTL de la subvention agit comme la durée de vie maximale absolue pour la chaîne de jetons de rafraîchissement. Pour les SPA, le TTL fixe du jeton de rafraîchissement peut expirer avant la subvention.
Lorsqu’un jeton de rafraîchissement est émis sans la portée offline_access dans la 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 garantir que le paramètre de durée de vie du jeton de rafraîchissement prenne pleinement effet, 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.
Nombre maximal de subventions autorisées (maxAllowedGrants)
maxAllowedGrants est un champ optionnel au niveau de l’application sous customClientMetadata qui contrôle le nombre maximal de subventions actives simultanées par utilisateur pour l’application actuelle.
- Défaut :
undefined(aucune limite) - Si configuré : À chaque autorisation réussie, Logto vérifie le nombre total de subventions actives pour l’utilisateur dans l’application actuelle (tous navigateurs et appareils confondus). Si la limite est dépassée, Logto révoque les subventions les plus anciennes.
Ce paramètre est utile lorsque vous souhaitez limiter le nombre d’appareils authentifiés simultanément par application.
Ce champ n’est pas pris en charge pour :
- Applications machine à machine
- Applications protégées
- Applications SAML
Données personnalisées
Informations personnalisées supplémentaires 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é.