Vue d’ensemble
Le module Applications connectées permet à des applications externes (portails, ERP, outils BI, middleware .NET, scripts d’intégration…) de s’authentifier auprès de l’API REST Cirrus Shield sans stocker de mot de passe d’utilisateur humain. Avant d’écrire la moindre ligne de code contre l’API REST (voir la section suivante), votre intégration doit être enregistrée comme application connectée.
Accéder à la gestion des applications connectées
Navigation : Configuration → Applications connectées
Cette page liste toutes les applications OAuth enregistrées pour votre organisation, avec leur statut (actif/inactif) et la date de dernière utilisation. C’est ici qu’un administrateur crée une nouvelle application, ou modifie/désactive/supprime une application existante.
Créer une application connectée
Depuis la page de liste, cliquer sur Nouvelle application.
Champs obligatoires (communs aux deux types de client) :
| Champ | Description |
|---|---|
| Nom | Nom affiché sur la page de consentement. Max 100 caractères. |
| Type de client | Confidential ou Public — voir la section « Types de clients » ci-dessous. |
| Scopes autorisés | Permissions accordées à l’application — voir la section « Scopes disponibles » ci-dessous. |
Champs additionnels pour un client Confidential :
| Champ | Description |
|---|---|
| Utilisateur associé | Compte Cirrus Shield qui fournit le contexte de données pour les appels machine-to-machine (M2M). |
| IPs autorisées | Optionnel — liste d’IPs ou de plages CIDR autorisées à appeler le token endpoint. |
| Durée access token | Durée de validité en secondes. Défaut : 3600s. Maximum : 86400s. |
Champs additionnels pour un client Public :
| Champ | Description |
|---|---|
| Redirect URIs | Une URI par ligne. Correspondance exacte obligatoire — pas de wildcards. |
| Durée access token | Défaut : 900s (15 min) pour le flux utilisateur. |
| Durée refresh token | Défaut : 604800s (7 jours). Maximum : 2592000s. |
Secret client : après la création d’un client Confidential, le secret est affiché une seule fois. Il doit être copié immédiatement — il ne peut pas être récupéré ensuite. Format : cs_ suivi de 40 caractères base64url (ex. cs_rxm2doH1mPQ28NWKbXIlCYImdOrHUXW5HiIGd0Vx). Un client Public n’a pas de secret : PKCE en tient lieu.
Types de clients
Client Confidential (Machine-to-Machine) — pour les applications serveur qui s’authentifient sans interaction utilisateur : scripts, jobs planifiés, intégrations backend.
- Possède un
client_secretstocké côté serveur. - Utilise le flux Client Credentials.
- Agit avec les droits de l’utilisateur associé configuré.
- Ne peut pas utiliser le flux Authorization Code.
Client Public (délégation utilisateur) — pour les portails web ou applications mobiles qui agissent au nom d’un utilisateur Cirrus Shield réel.
- Pas de secret (PKCE remplace la preuve de possession).
- Utilise le flux Authorization Code + PKCE.
- Agit avec les droits de l’utilisateur qui a consenti.
- Émet des refresh tokens si
offline_accessfigure dans les scopes.
Scopes disponibles
| Scope | Ce qu’il autorise |
|---|---|
api:read | Lire les enregistrements (Query, Describe) |
api:write | Créer et modifier des enregistrements, envoyer des emails, générer des documents |
api:delete | Supprimer des enregistrements |
api | Accès complet à l’API (équivaut à api:read + api:write + api:delete) |
offline_access | Obtenir un refresh token (flux Authorization Code uniquement) |
ℹ️ Les scopes accordés à l’application ne font que définir le maximum possible : l’utilisateur associé (Confidential) ou l’utilisateur connecté (Public) peut encore être plus restreint par son propre profil.
Gérer une application existante
Depuis la page de détail du client :
- Activer / Désactiver — un client désactivé retourne
401 invalid_clientsur toute tentative de token. - Régénérer le secret — invalide immédiatement tous les tokens actifs du client, puis génère un nouveau secret affiché une seule fois. L’ancien secret cesse de fonctionner immédiatement.
- Supprimer — révoque tous les tokens actifs et supprime définitivement le client.
Journal d’activité
La page de détail de chaque client affiche les 20 derniers événements OAuth :
| Type d’événement | Signification |
|---|---|
TOKEN_ISSUED | Token émis avec succès |
TOKEN_REFRESHED | Token renouvelé via refresh token |
TOKEN_REVOKED | Token révoqué (manuellement ou par rotation) |
AUTH_FAILED | Échec d’authentification — affiché en rouge |
INTROSPECT | Vérification de token par un Resource Server |
Aucun token ni credential n’apparaît dans les logs : seules les métadonnées (IP source, durée, statut HTTP) sont enregistrées.
Bonnes pratiques de sécurité
- Ne jamais partager le
client_secretentre plusieurs applications — créer un client par application. - Restreindre les IPs pour les clients M2M si l’application a une IP fixe.
- Accorder le minimum de scopes nécessaires à chaque application.
- Surveiller les événements
AUTH_FAILED— un nombre élevé peut indiquer une tentative d’attaque. - Régénérer le secret immédiatement en cas de compromission suspectée.
- Désactiver plutôt que supprimer une application temporairement hors service (les logs sont conservés).
Une fois l’application connectée créée, l’obtention et l’utilisation des tokens OAuth 2.0 (endpoints, flux Client Credentials et Authorization Code + PKCE, introspection, validation JWT, exemples de code) sont détaillées dans la section suivante : 1. AuthToken.
