Enregistrement d’application : l’identité n’est pas une permission
L’enregistrement d’application, ou App Registration, donne une identité à un logiciel pour qu’il puisse connecter des utilisateurs et demander l’accès à des API protégées. C’est une carte d’identité de l’application, pas une autorisation d’accès.
Pour Phenix Lite, cette distinction est concrète : identifier l’application mobile et authentifier un utilisateur sont nécessaires, mais ne prouvent pas que l’application peut consulter son compte financier.
1. Que définit un enregistrement d’application ?
L’enregistrement, l’authentification et l’autorisation répondent à des questions différentes :
- Enregistrement : quelle est cette application et comment est-elle configurée ?
- Authentification : quel utilisateur ou service effectue la demande ?
- Autorisation : cet appelant peut-il réaliser cette opération sur cette ressource maintenant ?
Un enregistrement définit généralement les éléments suivants :
| Élément | Rôle |
|---|---|
| Client ID | Identifie l’application. Ce n’est pas un secret. |
| Type de client | Distingue un client public, mobile ou navigateur, d’un backend confidentiel capable de protéger des identifiants. |
| URI de redirection | Destination exacte autorisée à recevoir la réponse d’autorisation après connexion. |
| Flux d’authentification autorisés | Définit comment obtenir des jetons, par exemple Authorization Code avec PKCE. |
| Permissions API demandées | Décrit les capacités souhaitées. Les demander ne signifie pas les obtenir. |
| Propriété et périmètre de gestion | Détermine qui peut administrer l’enregistrement dans son organisation et son espace de travail. |
Dans Ireti, ces responsabilités ont des propriétaires distincts :
- Ireti IAM, reposant sur Keycloak, gère les clients OAuth, l’authentification et les identifiants secrets.
- Ireti Platform gère les permissions de plateforme, les consentements et les décisions d’autorisation courantes.
- L’API métier possède les données métier et applique les restrictions propres aux ressources.
L’interface App Registration coordonne ces responsabilités. Elle ne constitue ni une autre autorité d’identité ni une source indépendante de permissions de plateforme.
2. Accès délégué et accès applicatif
Délégué : l’application agit pour un utilisateur
Prenons Phenix Lite qui consulte le solde de l’utilisateur connecté. La capacité approuvée de l’application et les droits propres de l’utilisateur doivent tous deux autoriser l’opération dans le périmètre visé. Le produit doit également vérifier le lien entre l’utilisateur, le client financier et le compte.
Pour la connexion native, le mobile utilise Authorization Code avec S256 PKCE, ouvre le navigateur système et reçoit le retour via son URI enregistrée. Une application mobile est un client public : elle ne doit pas contenir de secret client.
PKCE protège l’échange du code d’autorisation. Il n’accorde pas d’accès API et ne transforme pas le mobile en client confidentiel.
Applicatif : le service agit pour son propre compte
Un traitement serveur peut s’authentifier sans utilisateur interactif. Il agit sous un principal de service, l’identité technique de l’application dans le modèle d’autorisation, avec des permissions applicatives explicitement approuvées.
Un service confidentiel utilise couramment Client Credentials. Ses identifiants restent côté serveur. Il n’hérite pas des droits personnels de l’administrateur qui l’a enregistré ou qui a approuvé son accès.
| Accès délégué | Accès applicatif | |
|---|---|---|
| Identité autorisée | Application et utilisateur ensemble | Principal de service de l’application |
| Usage typique | Application mobile ou navigateur | Service backend ou tâche planifiée |
| Flux habituel | Authorization Code avec PKCE | Client Credentials |
| Identifiants | Aucun secret client intégré au mobile ou au navigateur | Identifiants protégés côté serveur |
| Limite d’autorisation | Capacité approuvée, droits utilisateur et restrictions métier | Permissions explicites du service et restrictions métier |
Un jeton d’accès identifie un appelant pour une audience donnée ; sa présence ne suffit pas à prouver une permission actuelle. Les API valident le jeton et appliquent les règles d’autorisation correspondantes.
3. Demander une permission n’est pas l’approuver
Dans le fonctionnement actuel d’Ireti :
Sélectionner et enregistrer signifie demander l’accès. Accorder le consentement administrateur signifie approuver cet accès.
Retirer une permission et enregistrer la révoque. La sélectionner à nouveau constitue une nouvelle demande et nécessite un nouveau consentement. Un enregistrement peut donc être valide alors que ses requêtes API restent interdites.
Le consentement administrateur à une permission API est aussi distinct du consentement d’identité présenté pendant la connexion. Autoriser une application à recevoir des informations d’identité ne l’autorise pas à lire un compte financier.
L’espace de gestion de l’enregistrement peut différer de l’espace contenant les ressources protégées. La permission doit cibler explicitement le bon périmètre ; posséder l’enregistrement ne donne pas accès aux ressources.
4. Phenix Lite : de la connexion à la lecture du solde
La preuve native de développement utilise un BFF, pour Backend for Frontend : un backend privé spécialisé pour la consultation du solde par l’application mobile.
Deux limites d’autorisation sont distinctes :
- Mobile vers BFF : ce client peut-il agir pour cet utilisateur ?
- BFF vers API financière : ce service backend peut-il effectuer l’opération financière ?
Le BFF ne doit jamais utiliser ses propres privilèges pour contourner un refus concernant le mobile. L’application ne reçoit jamais les identifiants du backend, et l’appelant ne peut pas sélectionner arbitrairement un compte financier.
APISIX fournit les routes approuvées et la limite d’application des contrôles ; il ne possède pas la vérité des permissions. Ireti Platform fournit les décisions courantes, tandis que le produit possède les liens client-compte et les restrictions métier.
La révocation doit affecter la requête suivante
Un jeton signé peut rester cryptographiquement valide après la révocation d’une permission. Vérifier uniquement sa signature et son expiration ne permettrait pas de détecter ce changement.
Dans la preuve de développement Phenix Lite, le BFF vérifie la permission déléguée actuelle à chaque lecture. Retirer cette permission bloque la lecture suivante dans la session existante, sans attendre l’expiration du jeton. Le mobile efface le solde précédemment affiché en cas de refus ou d’échec de lecture.
L’article en anglais From native sign-in to revocable financial access détaille cette preuve Android et ses critères d’acceptation. Cet exemple ne constitue ni un lancement en production ni une migration complète de l’application historique.
5. Ce que l’enregistrement ne fait pas
Créer un client OAuth ne signifie pas automatiquement :
- Publier une application dans le catalogue.
- L’activer pour une organisation.
- Créer un abonnement, un droit d’utilisation ou une attribution de place utilisateur.
- Accorder des permissions API.
- Créer un client financier ou un compte.
- Donner accès aux données à tous les utilisateurs connectés.
De même, une URL d’espace de travail est un sélecteur, pas une preuve d’autorisation. Administrer un enregistrement ne contourne pas les permissions, droits d’utilisation ou places nécessaires pour accéder à un espace applicatif.
Utilisez des identités distinctes pour les composants déployés indépendamment et pour les environnements. N’autorisez que les flux nécessaires, les URI de retour exactes et les audiences prévues, puis approuvez les permissions minimales sur les ressources.
L’enregistrement identifie le logiciel. L’authentification vérifie les identités. Le consentement approuve les capacités demandées. L’autorisation décide de ce que chaque requête peut réellement faire.