Workflow d'enregistrement des clients

Le workflow d’enregistrement des clients soumet le provisionnement des clients OIDC et SAML à un moteur de politique à trois niveaux, avec revue humaine optionnelle. Les clients traversent un cycle de vie défini avant d’être écrits chez le fournisseur externe (Ory Hydra, Auth0, Entra ID, RFC 7592).

États du cycle de vie

Draft → Pending Review → Active
                ↓               ↑
        Changes Requested → (resubmit)
                ↓
            Rejected  (terminal — nouvelle soumission requise)

Active → Suspended  (réversible, config préservée)
Active → Deprecated (signal de fin de vie, toujours fonctionnel)

État	Qui peut agir	Notes
Draft	Membre de l’équipe	Privé ; non visible par les réviseurs
Pending Review	Système / Réviseur	Le moteur de politique s’exécute à la soumission
Changes Requested	Réviseur	L’équipe resoumet directement vers Pending Review
Active	Système / Réviseur	Fournisseur externe provisionné
Rejected	Réviseur / Moteur de politique	Violation stricte ; nouvelle soumission requise
Suspended	Réviseur ou admin d’org	Réversible ; config en production préservée
Deprecated	Réviseur ou admin d’org	Le client fonctionne toujours ; les équipes sont averties de migrer

Modèle de politique

Trois niveaux, chacun étant un sous-ensemble strict du niveau supérieur.

Niveau 1 — Politique de plateforme (limites globales strictes)

Défini par les admins d’instance dans Paramètres → Instance → Politique de plateforme.

Toute violation entraîne un rejet immédiat — sans passer par la revue humaine.

Champ	Type	Effet
`blockedGrantTypes`	`string[]`	Toute soumission demandant ces grant types est rejetée
`reservedScopePrefixes`	`string[]`	Les scopes commençant par ces préfixes sont rejetés (ex. `"platform:"`)
`maxAccessTokenLifetimeSecs`	`number?`	Plafond de durée de vie de token pour toutes les équipes

{
  "blockedGrantTypes": ["implicit", "password"],
  "reservedScopePrefixes": ["platform:", "internal:"],
  "maxAccessTokenLifetimeSecs": 86400
}

Niveau 2 — Profil de politique d’équipe (bornes par équipe)

Créé par les admins d’organisation dans Paramètres → Organisation → Profils de politique, puis assigné aux équipes.

Les soumissions hors de ces bornes sont acheminées vers la revue humaine (ni auto-approuvées, ni rejetées).

Contraintes du profil OIDC

{
  "type": "oidc",
  "allowedGrantTypes": ["authorization_code", "refresh_token"],
  "approvedScopes": ["openid", "profile", "email", "offline_access"],
  "redirectUriPatterns": ["https://*.example.com/*", "https://app.myco.io/callback"],
  "requirePkce": true,
  "maxAccessTokenLifetimeSecs": 3600,
  "maxRefreshTokenLifetimeSecs": 2592000
}

Champ	Description
`type`	Doit valoir `"oidc"`
`allowedGrantTypes`	Sous-ensemble de grant types autorisés
`approvedScopes`	Chaînes de scope autorisées (correspondance exacte)
`redirectUriPatterns`	Motifs glob ; `` correspond au sein d’un segment de chemin, `*` sur plusieurs segments
`requirePkce`	Si `true`, les soumissions sans PKCE sont acheminées vers la revue
`maxAccessTokenLifetimeSecs`	Plafond par équipe (doit être ≤ plafond de plateforme)
`maxRefreshTokenLifetimeSecs`	Plafond de refresh token par équipe

Contraintes du profil SAML

{
  "type": "saml",
  "allowedAcsUrlPatterns": ["https://*.example.com/saml/acs"],
  "allowedEntityIdPatterns": ["urn:example:*"],
  "releasableAttributes": ["email", "name", "groups"],
  "requiredSignatureAlgorithm": "rsa-sha256"
}

Champ	Description
`type`	Doit valoir `"saml"`
`allowedAcsUrlPatterns`	Motifs glob pour les URLs ACS autorisées
`allowedEntityIdPatterns`	Motifs glob pour les entity ID autorisés (omettre pour tout autoriser)
`releasableAttributes`	Noms d’attributs que le SP peut demander
`requiredSignatureAlgorithm`	`"rsa-sha256"` ou `"rsa-sha512"`

Niveau 3 — Configuration du client

Ce que l’équipe soumet. Auto-approuvé lorsque cela reste entièrement dans les bornes du niveau 2. Acheminé vers la revue humaine lorsque cela dépasse les bornes du niveau 2. Rejeté immédiatement en cas de violation du niveau 1.

Auto-approbation vs revue humaine

Soumission de la config
      │
      ▼
Vérification politique de plateforme
      │
      ├─ violation → Rejeté immédiatement (pas d'entrée en file de revue)
      │
      ▼
Vérification du profil d'équipe
      │
      ├─ aucun profil assigné → Revue nécessaire
      ├─ config hors du profil → Revue nécessaire (violations listées dans la demande de revue)
      │
      └─ config dans les bornes du profil → Auto-approuvé → Active
                                             (fournisseur externe provisionné immédiatement)

Templates

Il existe deux types de templates distincts, aux comportements différents.

Templates de framework (configuration de départ)

Lors de la création d’un nouvel enregistrement, le formulaire propose un sélecteur de template alimenté par le registre cerberauth/nacho — plus de 67 templates couvrant les frameworks et plateformes courants (React, Next.js, Django, Spring Boot, Go, etc.).

Sélectionner un template de framework pré-remplit la configuration du client :

Grant types (ex. authorization_code + pkce pour les SPA)
Méthode d’authentification du token endpoint (ex. none pour les clients publics)
Scopes demandés (ex. openid profile email)

Les templates de framework sont des configurations de départ uniquement — l’enregistrement est toujours créé en Draft et suit le cycle de revue normal. Les redirect URIs et autres champs propres à l’application doivent être renseignés avant soumission.

La liste des templates est récupérée depuis le dépôt nacho et mise en cache pendant 24 heures.

Templates d’organisation / d’instance (voie rapide)

Les templates d’organisation et d’instance contournent entièrement l’évaluation de politique. Une soumission provenant de l’un de ces templates est auto-approuvée immédiatement, sans passer par la file de revue.

Ils sont créés par :

Les admins d’instance — templates globaux visibles par toutes les organisations (ex. « SPA avec PKCE », « M2M Client Credentials »)
Les admins d’organisation — templates limités à leur propre organisation

Gérez-les depuis Paramètres → Organisation → Templates (portée organisation) ou Paramètres → Instance → Templates (portée globale).

Changesets

Les mises à jour de configuration sur un client Active passent par un changeset parallèle. La configuration en production continue de fonctionner pendant la revue.

Le membre de l’équipe accède à l’enregistrement du client et clique sur Proposer une modification.
Le moteur de politique s’exécute sur la nouvelle configuration.
Si auto-approuvé : le fournisseur est mis à jour de façon atomique.
Si une revue est nécessaire : une demande de revue est créée ; la configuration en production reste inchangée jusqu’à l’approbation du réviseur.
Approuvé → bascule atomique chez le fournisseur externe. Rejeté → la configuration en production reste inchangée.

Un seul changeset ouvert par client à la fois. Une nouvelle soumission remplace tout changeset en attente.

Guide de configuration

Définir la politique de plateforme (admin d’instance)

Allez dans Paramètres → Instance → Politique de plateforme. Ajoutez les grant types bloqués (ex. implicit, password) et les préfixes de scope réservés (ex. platform:, admin:). Enregistrez — prend effet immédiatement sur toutes les soumissions futures.
Créer un profil de politique (admin d’organisation)

Allez dans Paramètres → Organisation → Profils de politique → Nouveau profil. Choisissez le type de client (oidc ou saml) et saisissez les contraintes JSON (voir le format ci-dessus). Enregistrez — la version 1 est créée.

Pour mettre à jour les contraintes plus tard, ouvrez le profil et cliquez sur Nouvelle version. Les clients actifs existants référençant l’ancienne version ne sont pas affectés ; seules les nouvelles soumissions utilisent la nouvelle version.
Assigner un profil à une équipe (admin d’organisation)

Allez dans Paramètres → Organisation → Équipes → [nom de l’équipe] → Politique. Sélectionnez le profil pour les clients OAuth2/OIDC et/ou pour les clients SAML. Enregistrez.

Les équipes sans profil assigné sont toujours acheminées vers la revue humaine.
Ajouter des réviseurs (admin d’organisation)

Allez dans Paramètres → Organisation → Membres. Trouvez le membre et changez son rôle en Réviseur. Les réviseurs voient la File de revue dans la barre latérale.

Les admins d’instance (users.role = 'admin') peuvent toujours réviser, indépendamment de leur appartenance à l’organisation.
Soumettre un client (membre de l’équipe)

Allez dans Enregistrements → Nouvel enregistrement. Choisissez éventuellement un template de framework (ex. « React SPA », « Next.js App ») pour pré-remplir les grant types, la méthode d’authentification et les scopes, ou ignorez pour une config vierge. Choisissez le type de client, saisissez un nom, puis cliquez sur Créer le brouillon.

Renseignez les champs propres à l’application (redirect URIs, audience, etc.) puis cliquez sur Soumettre pour revue. Si auto-approuvé : le client est actif immédiatement. Si acheminé vers la revue : le statut affiche Pending Review.

File de revue

Les réviseurs accèdent aux soumissions en attente sur /review. Chaque revue affiche la configuration proposée complète, le résultat de l’évaluation de politique (quels champs ont déclenché la revue et pourquoi), et un fil de commentaires.

Action	Résultat
Approve	Client provisionné chez le fournisseur externe ; statut → Active
Request Changes	Statut → Changes Requested ; motif envoyé à l’équipe
Reject	Statut → Rejected (terminal) ; motif enregistré

Accès API / programmatique

Toutes les opérations du workflow sont actuellement exposées comme Server Actions Next.js. Une surface d’API REST n’est pas encore disponible mais est prévue. Pour un provisionnement automatisé, utilisez les templates (qui contournent la file de revue à l’instanciation).

Référence des rôles

Rôle	Peut soumettre	Peut réviser	Peut gérer les profils	Peut définir la politique de plateforme
Membre	✓	—	—	—
Réviseur	✓	✓	—	—
Admin / propriétaire d’org	✓	✓	✓ (portée org)	—
Admin d’instance	✓	✓	✓ (global + org)	✓