PD-XX — Mise en place du fournisseur d’identité (IdP OAuth2 / OIDC)¶

1. Objectif¶

Définir de manière canonique, contractuelle et auditable la mise en place d’un fournisseur d’identité OAuth2 / OpenID Connect servant de socle transverse d’authentification et d’autorisation pour l’ensemble du système ProbatioVault.

Cette User Story vise à établir un référentiel d’identité unique, standardisé, souverain et testable, sans introduire de dépendance métier ni de logique cryptographique applicative.

2. Périmètre / Hors périmètre¶

Inclus¶

• Mise en place d’un IdP OAuth2 / OIDC auto‑hébergé.
• Définition d’une implémentation de référence basée sur Keycloak.
• Séparation stricte des environnements (au minimum : non‑prod / prod).
• Émission de tokens JWT signés conformes aux standards OAuth2/OIDC.
• Mise à disposition des documents de découverte OIDC et du JWKS.
• Support des claims d’identité et d’autorisation normatifs.
• Journalisation minimale permettant l’audit des authentifications et émissions de tokens.

Exclu¶

• Authentification zero‑knowledge utilisateur (SRP‑6a).
• Gestion des clés de chiffrement applicatives.
• Fédération d’identité externe (Google, FranceConnect, SAML, etc.).
• MFA / authentification forte.
• Gestion du cycle de vie métier des comptes utilisateurs.
• Toute logique métier ProbatioVault.

3. Définitions¶

• IdP : Identity Provider, composant émettant des identités vérifiables.
• OAuth2 / OIDC : standards d’autorisation et d’identité.
• JWT : Jeton signé transportant des claims.
• Issuer (iss) : Autorité émettrice du token.
• Audience (aud) : Destinataire(s) du token.
• JWKS : Jeu de clés publiques de vérification.
• Realm : Domaine de sécurité isolé.

4. Invariants (non négociables)¶

4.1 Bloc normatif IAM / JWT (transverse)¶

Statut : NORMATIF — opposable contractuellement. Applicable à tout token d’identité/autorisation utilisé dans le système ProbatioVault.

• INV‑IAM‑01 — Émetteur (issuer) normatif
  Tout token accepté doit être émis par un issuer explicitement autorisé, liste fermée par environnement. Toute valeur iss non autorisée est rejetée.

• INV‑IAM‑02 — Audience(s) autorisée(s)
  Le token doit contenir au moins une audience appartenant à l’ensemble des audiences autorisées pour le composant consommateur. Absence ou incompatibilité ⇒ rejet.

• INV‑IAM‑03 — Algorithmes et clés cryptographiques
  Seuls les algorithmes explicitement autorisés sont acceptés (liste fermée). Tout algorithme non autorisé est interdit par défaut. Les clés de signature doivent respecter une taille minimale conforme ; algorithmes non signés ou affaiblis interdits.

• INV‑IAM‑04 — Claims normatifs requis
  Claims obligatoires : iss, aud, sub, iat, exp (et nbf si présent). L’absence ou la non‑conformité d’un seul claim entraîne un rejet systématique. Les claims supplémentaires sont ignorés à des fins décisionnelles sauf mention contraire dans une US spécifique.

• INV‑IAM‑05 — Contraintes temporelles
  Les claims temporels (iat, nbf, exp) sont évalués selon une politique déterministe. Un token expiré ou non encore valide est rejeté. Une tolérance d’horloge maximale est définie et appliquée de manière homogène.

• INV‑IAM‑06 — Politique de flux d’émission
  Les tokens acceptés doivent provenir d’un flux d’émission autorisé pour le type de client concerné (catégorie de client ↔ flux OIDC autorisés). Tout flux non autorisé entraîne un rejet, même si le token est valide cryptographiquement.

• INV‑IAM‑07 — Isolation par environnement
  Les tokens sont strictement liés à leur environnement d’émission. Un token émis pour un environnement ne doit jamais être accepté dans un autre, indépendamment des audiences ou droits.

5. Flux nominaux¶

F1 — Découverte OIDC¶

1. Un client récupère le document de découverte OIDC de l’IdP.
2. Les endpoints et métadonnées sont exposés conformément au standard.

F2 — Émission d’un token¶

1. Une identité valide est présentée à l’IdP (mécanisme hors périmètre).
2. L’IdP émet un access_token JWT signé.
3. Le token contient les claims normatifs requis et respecte l’ensemble des invariants INV‑IAM‑01 à INV‑IAM‑07.
4. Le token est explicitement rattaché à un environnement unique par la valeur de son claim iss, conformément à l’invariant INV‑IAM‑08.
5. L’émission (ou le refus) de token donne lieu à un événement journalisé conforme à l’invariant INV‑IAM‑09.

F3 — Consommation du token¶

1. Un service ProbatioVault reçoit un token.
2. Il valide le token sans appel réseau à l’IdP.
3. La décision d’accès est prise localement.
4. Chaque authentification, émission ou refus de token produit un événement journalisé conforme à l’invariant INV‑IAM‑09.
5. Les éléments nécessaires à la démonstration de l’auto‑hébergement de l’IdP et de l’absence de secrets applicatifs sont maintenus et accessibles conformément à l’invariant INV‑IAM‑10.

5bis. Diagrammes¶

D1 — Cycle de vie d’un token JWT (state diagram)¶

Réf. invariants : INV‑IAM‑01 à INV‑IAM‑08, INV‑04, INV‑IAM‑11.

stateDiagram-v2
    [*] --> Requested : Client présente identité

    Requested --> Emitted : IdP valide identité\n+ claims conformes (INV‑IAM‑04)
    Requested --> EmissionRefused : Identité invalide\nou IdP indisponible (INV‑IAM‑11)

    EmissionRefused --> [*] : Signal d’erreur observable\n(INV‑IAM‑09 journalisé)

    Emitted --> Valid : iat ≤ now ≤ exp\n(INV‑IAM‑05, tolérance ±2min)
    Emitted --> NotYetValid : now < nbf\n(INV‑IAM‑05)

    NotYetValid --> Valid : nbf atteint

    Valid --> Accepted : iss ✓ (INV‑IAM‑01/08)\naud ✓ (INV‑IAM‑02)\nalg ✓ (INV‑IAM‑03)\nflux ✓ (INV‑IAM‑06)\nenv ✓ (INV‑IAM‑07)
    Valid --> Rejected : Échec validation\n(un ou plusieurs invariants)
    Valid --> Expired : now > exp + tolérance\n(INV‑IAM‑05)

    Expired --> Rejected : Rejet systématique

    Accepted --> [*]
    Rejected --> [*] : Événement journalisé\n(INV‑IAM‑09)

D2 — Flux F2 : Émission d’un token (sequence diagram)¶

Réf. invariants : INV‑01, INV‑02, INV‑04, INV‑05, INV‑IAM‑01, INV‑IAM‑04, INV‑IAM‑08, INV‑IAM‑09.

sequenceDiagram
    autonumber
    participant C as Client
    participant IdP as IdP Keycloak<br/>(auto‑hébergé, INV‑02)
    participant Log as Journal IAM

    C->>IdP: Présentation identité<br/>(flux autorisé, INV‑IAM‑06)
    IdP->>IdP: Validation identité
    alt Identité valide
        IdP->>IdP: Construction JWT signé (INV‑04)<br/>claims: iss, aud, sub, iat, exp (INV‑IAM‑04)<br/>iss = issuer environnement (INV‑IAM‑08)<br/>aucun secret applicatif (INV‑05)
        IdP->>Log: Événement EMISSION_OK (INV‑IAM‑09)
        IdP-->>C: access_token JWT
    else Identité invalide
        IdP->>Log: Événement EMISSION_REFUS (INV‑IAM‑09)
        IdP-->>C: Erreur 401
    end

D3 — Flux F3 : Consommation et validation d’un token (sequence diagram)¶

Réf. invariants : INV‑04, INV‑IAM‑01 à INV‑IAM‑08, INV‑IAM‑09, INV‑IAM‑10.

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Service ProbatioVault
    participant JWKS as JWKS (clés publiques,<br/>cache local)
    participant Log as Journal IAM

    C->>S: Requête + access_token JWT
    S->>JWKS: Récupération clé publique<br/>(vérification hors‑ligne, INV‑04)
    JWKS-->>S: Clé publique

    S->>S: 1. Vérification signature (INV‑IAM‑03)
    S->>S: 2. Vérification iss ∈ issuers autorisés (INV‑IAM‑01/08)
    S->>S: 3. Vérification aud (INV‑IAM‑02)
    S->>S: 4. Vérification claims requis (INV‑IAM‑04)
    S->>S: 5. Vérification temporelle iat/exp/nbf (INV‑IAM‑05)
    S->>S: 6. Vérification flux d’émission (INV‑IAM‑06)
    S->>S: 7. Vérification isolation env (INV‑IAM‑07)

    alt Toutes validations OK
        S->>Log: Événement AUTH_OK (INV‑IAM‑09)
        S-->>C: Réponse 200
    else Au moins un invariant échoue
        S->>Log: Événement AUTH_REFUS (INV‑IAM‑09)
        S-->>C: Erreur 401 (message uniforme)
    end

6. Cas d’erreur¶

• IdP indisponible → aucun token n’est émis.
• Token non signé ou invalide → rejet par les services consommateurs.
• Token émis hors environnement attendu → rejet.
• En cas d’indisponibilité de l’IdP, l’absence d’émission de token est accompagnée d’un signal d’erreur observable, conformément à l’invariant INV‑IAM‑11.
• Le signal d’indisponibilité emprunte un canal normatif documenté (signal applicatif, journalisation INV‑IAM‑09 ou indicateur d’état), conformément à INV‑IAM‑11.

7. Critères d’acceptation (testables)¶

8. Scénarios de test (GWT)¶

S1 — Découverte OIDC
Given un IdP opérationnel
When le document de découverte est demandé
Then les métadonnées OIDC sont exposées

S2 — Isolation environnement
Given deux environnements distincts
When un token d’un environnement est utilisé dans l’autre
Then le token est rejeté

9. Hypothèses explicites¶

10. Points à clarifier¶

• Politique de rétention des logs (périmètre d’infra opérationnelle).
• Les valeurs concrètes (noms d’issuer, audiences, algorithmes précis, flux autorisés) sont fournies au niveau environnement/implémentation et ne modifient pas les règles normatives ci‑dessus. La durée minimale de conservation des journaux IAM est définie de manière normative par l’invariant INV‑IAM‑09.

11. Annexe A — Principes et bonnes pratiques IAM / JWT¶

Statut : NON NORMATIF — EXPLICATIF. Cette annexe est strictement non contractuelle. Les valeurs concrètes des paramètres IAM/JWT (issuers, audiences, algorithmes, tailles de clés, durées, flux autorisés) sont définies exclusivement dans l’Annexe B — NORMATIVE. Elle fournit un cadre explicatif et des bonnes pratiques sans valeur opposable.

A.1 — Objectif de l’annexe¶

Cette annexe vise à expliciter les principes de conception retenus pour l’IAM, fournir un contexte de compréhension aux équipes et aux auditeurs, et justifier les choix de sécurité généraux sans figer de paramètres. Elle ne définit aucune valeur normative.

A.2 — Séparation des responsabilités¶

Le modèle IAM repose sur une séparation stricte entre : identité/authentification/autorisation (émission et validation de tokens, gestion des identités, contrôle d’accès) et gestion des secrets applicatifs (stockage de clés, secrets applicatifs, accès aux données). Objectif : réduire la surface d’attaque, limiter les fuites de secrets, améliorer l’auditabilité.

A.3 — Principes de validation JWT¶

Validation cryptographique stricte ; rejet par défaut de toute valeur non explicitement autorisée ; absence d’hypothèse implicite ; décisions déterministes (acceptation/rejet).

A.4 — Isolation par environnement (principe)¶

Garantir qu’un token émis dans un environnement ne puisse pas être accepté dans un autre ; aucune escalade ni confusion inter-environnements. Le mécanisme précis d’identification est défini de manière normative en Annexe B.

A.5 — Gestion des erreurs et observabilité¶

En cas d’erreur IAM : aucun token émis, indisponibilité observable, erreurs distinguables des refus d’autorisation. Formats/codes/signaux précis non imposés ici.

A.6 — Journalisation (principes généraux)¶

Objectifs : traçabilité des événements de sécurité, auditabilité, détection d’anomalies. Exigences : éviter toute fuite de secrets, rester exploitable sans exposer de données sensibles. Les exigences minimales opposables sont définies dans le corps normatif.

A.7 — Évolutivité et gouvernance¶

Annexe évolutive sans impact contractuel, accompagnant les mises à jour de sécurité et support d’audit. Toute divergence avec l’Annexe B est sans effet juridique.

12. Annexe B — Paramètres IAM / JWT normatifs¶

Statut : NORMATIF — CONTRACTUEL. Cette annexe fait partie intégrante de PD-235. Elle constitue la seule source de vérité normative pour les paramètres IAM/JWT utilisés par les invariants INV-IAM-01 à INV-IAM-11. Toute implémentation, tout test et tout audit doit s’y référer.

B.1 — Issuers autorisés par environnement¶

Chaque environnement ProbatioVault est identifié par un issuer OIDC unique et exclusif.

Règle normative : tout token dont le claim iss ne correspond pas à l’issuer de l’environnement courant est rejeté.

B.2 — Audiences autorisées¶

Règle normative : un token doit contenir au moins une audience appartenant à cette liste ; toute autre audience entraîne un rejet.

B.3 — Algorithmes cryptographiques autorisés¶

Algorithmes interdits : none et tout algorithme non listé ci-dessus. Règle : tout token signé avec un algorithme non autorisé est rejeté.

B.4 — Exigences de clés cryptographiques¶

Toute clé ne respectant pas ces tailles rend le token invalide.

B.5 — Claims JWT requis¶

Claims obligatoires : iss, aud, sub, iat, exp. Le claim nbf est optionnel ; s’il est présent, il est évalué. L’absence ou l’invalidité d’un claim requis entraîne un rejet.

B.6 — Contraintes temporelles¶

B.7 — Flux OAuth2 / OIDC autorisés¶

Tout token issu d’un flux non listé est rejeté.

B.8 — Gouvernance et évolution¶

Annexe fermée : toute valeur non listée est interdite. Toute modification doit être versionnée, peut être effectuée sans modifier les invariants, et ne doit pas introduire d’ambiguïté rétroactive.

Références¶

• Epic : Socle IAM / Sécurité
• JIRA : PD‑XX
• Repos concernés : infra / backend
• Documents associés : PD‑26‑specification.md