Identité, sessions et autorisations

Google prouve l'identité. Yisin API décide ce que cette identité peut faire. Les interfaces ne deviennent jamais l'autorité des droits.

Parcours retenu

Navigateur
   │  Authorization Code + state + PKCE
   ▼
Google OIDC
   │  ID token signé
   ▼
yisin-web ou yisin-admin
   │  session chiffrée HttpOnly, 50 minutes
   │  BFF /api/yisin/* ajoute Authorization: Bearer
   ▼
yisin-api
   │  signature + issuer + audience + dates + statut + rôles
   ▼
PostgreSQL

Le callback ne place ni le secret Google ni l'ID token dans le JavaScript du navigateur. Auth.js conserve les données techniques dans un cookie de session chiffré, HttpOnly et SameSite=Lax. Le BFF déchiffre la session côté serveur, rejette les jetons proches de l'expiration et ne transmet que quelques en-têtes explicitement autorisés.

Dans yisin-admin, les mutations BFF exigent en plus une origine identique et un jeton CSRF à double soumission obtenu sur une route authentifiée.

Deux clients, une autorité

yisin-web et yisin-admin ont chacun leur propre Client ID Google et leur URL de callback. yisin-api accepte uniquement ces deux audiences. Au premier appel /me, le couple stable (issuer, sub) crée un compte local, un workspace personnel et le rôle owner de ce workspace.

L'adresse électronique ne sert jamais d'identifiant primaire et ne confère aucun rôle. Un rôle de plateforme est attribué explicitement à l'account_id. L'interface Admin refuse toute session dont platform_roles est vide ; l'API répète toujours l'autorisation sur chaque contrat sensible.

Limite MFA assumée

Le jeton d'identité Google standard prouve l'authentification, mais ne fournit pas de façon fiable une preuve amr ou acr indiquant un second facteur. Yisin ne transforme donc pas une connexion Google ordinaire en « MFA vérifié ».

Conséquence : la console peut authentifier et reconnaître un opérateur, mais les mutations qui utilisent la politique RequireAdminPermission restent refusées. Leur activation nécessite un fournisseur capable d'attester le MFA, ou un mécanisme de step-up Yisin conçu et audité.

Secrets et environnements

En local, les interfaces peuvent lire les documents JSON Google ignorés par Git et un fichier .auth-secret généré séparément. En préproduction et en production, les valeurs sont injectées depuis le gestionnaire de secrets ; les fichiers téléchargés depuis Google ne sont pas intégrés aux images Docker.

Les URLs AUTH_URL et de callback doivent correspondre exactement aux valeurs déclarées dans Google Cloud. En production, tous les échanges passent par TLS et les cookies prennent le préfixe __Secure-.

État de recette

Contrôle	État
Validation Google JWT/JWKS et deux audiences	testé côté API
Rattachement idempotent (issuer, sub)	testé côté API
Session et BFF Web/Admin	code et dépendances livrés
CSRF des mutations Admin	code livré, recette navigateur à exécuter
Refus Admin sans rôle	code livré, recette navigateur à exécuter
Attribution explicite du premier rôle	commande livrée
MFA administratif attesté	non satisfait
TLS, reverse proxy et rotation des secrets	recette production à faire