Structure des données d’application
Introduction
Dans Logto, une application fait référence à 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 sont utilisées pour identifier la source des requêtes faites à l’API Logto, ainsi que pour gérer le processus d’authentification (Authentification) et d’autorisation (Authorization) des 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 (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.
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 (Access tokens) à courte durée de vie et une rotation des jetons de rafraîchissement (Refresh tokens).
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 et de suivre facilement 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ées est utilisée pour valider l’URI de redirection incluse dans la requête d’autorisation (Authorization request) envoyée par l’application à Logto lors du processus d’authentification (Authentification). Si l’URI de redirection spécifiée dans la requête d’autorisation correspond à l’une des URI autorisées 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 (Authentification).
Vous pouvez consulter le point de terminaison de redirection pour plus d’informations.
Comprendre les URI de redirection dans OIDC avec le flux Authorization Code
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ées dans les composants hostname et pathname des URI HTTP / HTTPS.
Règles :
- Les wildcards ne sont autorisées que dans le hostname et le pathname
- Les wildcards ne sont pas autorisées 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-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 exactes 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, ce qui aide à prévenir les accès non autorisés et les risques de sécurité associé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 de type cross-site request forgery (CSRF). 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 celles 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 (Authorization) 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 doit obtenir un jeton d’accès (Jeton d’accès) ou un jeton d’identifiant (Jeton d’identifiant), il envoie une requête au point de terminaison de jeton avec une autorisation (Authorization) d’accès, qui est généralement un code d’autorisation ou un jeton de rafraîchissement (Jeton de rafraîchissement). Le point de terminaison de jeton valide alors l’autorisation (Authorization) et délivre un jeton d’accès (Jeton d’accès) ou un jeton d’identifiant (Jeton d’identifiant) au client si l’autorisation (Authorization) est valide.
Vous pouvez consulter le point de terminaison de jeton pour plus d’informations.
Point de terminaison Userinfo
Le point de terminaison UserInfo d’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 dans la requête d’authentification (Authentification request) ou que offline_access soit présent dans les portées (Scopes).
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 (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 (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 (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).
Pour les clients publics, lorsque cette fonctionnalité est activée, un nouveau jeton de rafraîchissement (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 (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 du jeton 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 (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 n’étendra 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 (Jeton de rafraîchissement) si nécessaire.
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 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é.