# 5. Authentification et habilitations

## Modes de connexion

### Connexion locale

Le backend cherche l’utilisateur dans `auth_users`. Le compte doit être actif et posséder un mot de passe. Les hashes bcrypt sont supportés ; une compatibilité avec d’anciens mots de passe en clair existe encore et doit être résorbée. Si la table n’est pas disponible, un compte de secours peut être fourni par l’environnement.

### Microsoft Entra ID

Le mode OIDC utilise l’authorization code flow avec `state`, `nonce` et PKCE. Le backend échange le code, charge les clés Microsoft JWKS, vérifie la signature RS256 et contrôle l’émetteur, l’audience, le tenant, l’expiration et le nonce.

Un premier SSO crée automatiquement un compte actif de rôle `lecture`. Un administrateur doit ensuite attribuer les permissions nécessaires.

Dans la version analysée, le domaine accepté est codé en dur dans `src/lib/auth.ts` : `@groupevitaminet.com`. La variable d’environnement éventuelle de domaine n’est donc pas l’autorité effective. Toute évolution de domaine doit inclure code, tests et documentation.

## Session

Le JWT utilise `SECRET_KEY`, `JWT_ALGORITHM` — `HS256` par défaut — et une durée de 24 heures par défaut. Il est lu depuis le cookie `auth_token` ou un Bearer token. À chaque requête protégée, le backend recharge l’utilisateur et refuse un compte désactivé ou un rôle inconnu.

## Rôles

Les rôles connus sont `super_admin`, `admin`, `rh`, `responsable` et `lecture`. Le rôle historique `user` est normalisé vers `lecture`.

Le `super_admin` possède toutes les permissions et tous les scopes. Pour les autres rôles, le rôle seul ne suffit pas : ce sont les lignes d’habilitation qui autorisent les modules.

## Modules de permission

`dashboard`, `alertes`, `etat_civil`, `contrats`, `absences`, `visites_medicales`, `sanctions`, `fiches_paie`, `impressions`, `autres`, `parametres`.

Chaque module a un droit de lecture et d’écriture. L’écriture implique la lecture.

## Scopes de données

Les données salarié peuvent être limitées par :

- secteurs ;
- établissements ;
- catégories ;
- types de contrat.

Une liste non restreinte est représentée par le drapeau `all_*`. Les routes convertissent le profil d’accès en filtres métier. Les fiches de paie appliquent au minimum le scope établissement.

## Ajouter un nouveau module protégé

1. Ajouter le module à `APP_MODULES` dans `src/lib/authorization.ts`.
2. Adapter le validator et l’interface d’administration des utilisateurs.
3. Appliquer `requirePermission(request, module, level)` sur toutes les routes concernées.
4. Appliquer les scopes à chaque requête salarié.
5. Masquer ou désactiver l’interface frontend sans considérer cela comme une sécurité.
6. Tester 401, 403, lecture, écriture, accès total et accès limité.

## Checklist SSO production

- Redirect URI HTTPS exacte enregistrée dans Entra ;
- tenant, client ID et secret valides ;
- horloge du serveur synchronisée ;
- `FRONTEND_ORIGIN` correct ;
- callback accessible via Caddy ;
- compte nouvellement créé visible dans Paramètres ;
- permission minimale attribuée explicitement ;
- déconnexion et désactivation testées.