Fermé par défaut, identité de bout en bout.

Flexway valide les JWT avec des clés JWKS découvertes et mises en cache en arrière-plan ; la rotation des clés se fait sans redémarrage ni vague de 401. L'émetteur (iss) et l'audience (aud) sont vérifiés, et plusieurs émetteurs de fournisseurs différents cohabitent dans une même configuration (auth.issuers). Un émetteur peut accepter plusieurs audiences le temps d'un renommage. Par défaut seuls les algorithmes asymétriques sont admis : none et HS* sont refusés.

Les jetons opaques sont vérifiés par introspection RFC 7662 (opaque_tokens), avec les mêmes règles qu'un JWT et une réponse gardée en cache sans dépasser son expiration ; un fournisseur injoignable donne 503. La passerelle consomme des identités, elle n'en émet pas : l'émetteur reste celui de votre organisation.

Lier un jeton à son porteur, par certificat mTLS (RFC 8705) ou par preuve de possession DPoP (RFC 9449), est à venir ; le choix entre les deux reste ouvert.

L'exigence d'authentification vient du security du contrat, pas d'une table à côté : portées pour oauth2 et openIdConnect, rôles pour http bearer, complétés par x-flexway-scopes. Une opération sans alternative anonyme exige une identité ; les tags ne portent aucune exigence. Aucune opération n'est servie avec une exigence plus faible que celle déclarée.

Les rôles se lisent dans la claim désignée par roles_claim ; sans elle, aucun rôle n'est satisfait. Les refus suivent la sémantique HTTP - 401 quand l'identité manque ou ne vérifie pas, 403 quand elle ne suffit pas - avec WWW-Authenticate et un corps RFC 9457. L'appartenance d'une ressource à un tenant reste vérifiée par le service, seul à connaître sa donnée.

Ce qui n'est pas déclaré ne passe pas : un en-tête non déclaré est retiré, un paramètre de requête non déclaré est refusé par son nom, une méthode non déclarée reçoit 405 avec Allow, une origine non admise est refusée. CORS se déclare comme une politique, globale ou par hôte, et les en-têtes de sécurité de réponse sont posés sur chaque réponse.

Le corps et les paramètres sont validés contre le schéma du contrat : 422 qui nomme chaque champ en erreur, avec un code repris du mot-clé JSON Schema et renommable (errors.field_codes). Le corps n'est lu que si l'opération en déclare un, dans la borne server.limits.max_body (413 au-delà). Le mode se règle par hôte ou par opération (x-flexway-validation) - full, params ou off - et la liste blanche des en-têtes et paramètres est maintenue dans tous les modes.

Aucune erreur amont n'est relayée telle quelle : les refus de la passerelle suivent RFC 9457, avec un catalogue fermé de codes et un request_id et un trace_id dans la réponse, le détail restant au journal.

Quand un appelant ne peut produire ni identité de charge de travail ni jeton OAuth, une clé d'API reste possible, encadrée par construction. Elle se présente en en-tête seulement (Authorization: ApiKey), jamais en paramètre d'URL ; un schéma apiKey placé ailleurs est refusé au chargement. Le magasin ne garde que l'empreinte SHA-256, comparée à temps constant, et la clé n'existe en clair qu'une fois, à sa création. Chaque clé est liée à un tenant, à des opérations nommées et à une expiration obligatoire.

La rotation tient deux entrées actives le temps de la bascule ; la révocation consiste à retirer l'entrée, relue par chaque réplique à son rechargement, sans redémarrage. Un préfixe stable (fwk_) permet aux analyseurs de secrets de repérer une clé publiée par erreur, et chaque appel porte l'identifiant de la clé, jamais sa valeur, dans la trace et le journal.

Un certificat client est vérifié par l'écouteur TLS (server.tls) ou attesté par le bord via x-forwarded-client-cert, cru d'un pair de confiance seulement ; il est lié à un tenant et à des opérations (auth.mtls.clients). Le contrat décide quel mécanisme satisfait quelle alternative : un jeton ne remplace jamais une clé, ni l'inverse. Ni la clé ni le certificat attesté n'atteignent l'amont, et une clé d'API reste une identité, pas une autorisation.

Le tenant vient de l'identité vérifiée - la claim déclarée par l'émetteur (tenant_claim) - et jamais d'un en-tête fourni par le client, qui se forge. La passerelle l'écrit vers l'amont sous auth.tenant_header ; un en-tête de tenant entrant est écrasé. Les compteurs de débit et de quota sont indexés par tenant, sans partage possible.

Le débit se compte par appelant (émetteur et sujet, sinon l'adresse du client derrière server.trusted_proxies), jamais par pod appelant : deux utilisateurs derrière un même client serveur ont des compteurs distincts. Une réponse authentifiée n'est mise en cache qu'avec une clé de tenant et de sujet, déclarée par l'opération seule ; sans tenant et sujet, rien n'est caché.

Cette isolation du cache est tenue par un test bloquant rejoué à chaque modification, avec un contre-test qui ampute la clé du sujet. Un accès inter-tenant est traité comme une faille critique, pas comme un défaut.

audit.decisions écrit une ligne authz_decision par décision - toutes, ou les refus seulement - avec l'opération, le gabarit de chemin, le sujet haché et la chaîne d'agents. Chaque ligne est chaînée à la précédente (seq, prev, hash) par réplique, ce qui rend une suppression ou une altération vérifiable. Le journal ne contient aucune donnée personnelle en clair.

Le reste de la défense en profondeur tient au produit lui-même : image distroless non root, système de fichiers en lecture seule, SBOM, signature et attestation sur le digest de l'image, aucun greffon natif ni script dans la configuration. La surface d'administration est sur un port distinct et n'accepte aucune clé. Un audit horodaté, corrélé et vérifiable vous aide à répondre aux exigences de journalisation et de cybersécurité qui s'appliquent à votre plateforme.