Authentification

Stib inclut un système d'authentification optionnel qui permet de sécuriser votre instance et de contrôler les accès. Lorsqu'il est activé, les utilisateurs doivent se connecter avant d'interagir avec Stib. Vous pouvez utiliser des comptes locaux ou connecter un fournisseur d'identité externe via OIDC Single Sign-On.

INFO

L'authentification est désactivée par défaut. Stib fonctionne directement sans aucune connexion — idéal pour un usage personnel ou local. Activez l'authentification uniquement lorsque vous devez partager votre instance avec d'autres personnes.

Fonctionnement de l'authentification

Lorsque l'authentification est activée :

Chaque requête API est vérifiée par un middleware d'authentification (sauf les routes publiques comme les health checks)
Les utilisateurs reçoivent un token JWT (HS256, expiration 24 heures) lors de la connexion
Le secret JWT est généré automatiquement au premier démarrage et stocké en base de données
Deux méthodes d'authentification sont disponibles : comptes locaux et OIDC SSO

Activer l'authentification

L'authentification se configure depuis la page Paramètres de l'interface web Stib.

Au premier lancement, Stib vous invite à créer un compte super administrateur (identifiant + mot de passe). Ce compte a un accès complet à tous les paramètres, y compris la configuration OIDC. Une fois créé, rendez-vous dans Paramètres → Authentification pour activer la connexion sur votre instance.

Variables d'environnement

Variable	Description	Défaut	Requis
`STIB_SERVER_ORIGIN`	URL publique de votre instance Stib (ex. `https://stib.example.com`). Utilisée pour construire l'URL de callback OIDC.	`http://localhost:50505`	Oui, pour OIDC

WARNING

STIB_SERVER_ORIGIN doit correspondre à l'URL que vos utilisateurs saisissent dans leur navigateur. Si elle est incorrecte, le callback OIDC échouera. Incluez le protocole et le port si non standard (ex. https://stib.example.com:8443).

Configuration OIDC SSO

Stib supporte tout fournisseur d'identité compatible OIDC. L'interface Paramètres inclut des presets pour les fournisseurs courants.

Fournisseurs supportés

Fournisseur	URL de l'émetteur	Notes
Google	`https://accounts.google.com`	Fonctionne avec Google Workspace et les comptes personnels
Microsoft Entra ID	`https://login.microsoftonline.com/{tenant-id}/v2.0`	Nécessite votre ID de tenant Azure AD
Keycloak	URL de votre realm Keycloak	Fournisseur d'identité auto-hébergé
Personnalisé	Toute URL d'émetteur compatible OIDC	Doit exposer `/.well-known/openid-configuration`

Paramètres requis

Paramètre	Description
URL de l'émetteur (Issuer URL)	L'URL de base du fournisseur OIDC. Stib récupère le document de découverte depuis `{issuer_url}/.well-known/openid-configuration`.
Client ID	L'identifiant client OAuth2 fourni lors de l'enregistrement de votre application chez le fournisseur.
Client Secret	Le secret client OAuth2. Chiffré au repos avec AES-256-GCM à l'aide d'une clé dérivée du secret JWT.
Scopes	Les scopes OIDC à demander. Par défaut : `openid email profile`.

Mise en place d'OIDC

WARNING

La configuration OIDC nécessite les privilèges super admin. Seul le compte super administrateur créé lors de la première configuration peut accéder à Paramètres → Configuration OIDC.

Enregistrez une application chez votre fournisseur d'identité
Définissez l'URI de redirection : {STIB_SERVER_ORIGIN}/api/auth/oidc/callback
Copiez le Client ID et le Client Secret
Dans Stib, allez dans Paramètres → Configuration OIDC
Sélectionnez votre fournisseur dans le menu déroulant (ou choisissez Personnalisé)
Renseignez l'URL de l'émetteur, le Client ID, le Client Secret et les Scopes
Cliquez sur Tester la connexion pour valider la configuration
Activez Activer OIDC et cliquez sur Enregistrer

TIP

L'URI de redirection est affichée dans le panneau de configuration OIDC avec un bouton de copie (ex. https://stib.example.com/api/auth/oidc/callback). Utilisez cette valeur exacte lors de l'enregistrement de votre application chez le fournisseur d'identité.

Guides par fournisseur

Google

Accédez à la Google Cloud Console → APIs & Services → Credentials
Créez un OAuth 2.0 Client ID (Application Web)
Ajoutez l'URI de redirection : {STIB_SERVER_ORIGIN}/api/auth/oidc/callback
Dans Stib, sélectionnez Google dans le menu déroulant
L'URL de l'émetteur est pré-remplie : https://accounts.google.com
Saisissez votre Client ID et Client Secret

Microsoft Entra ID

Accédez au Portail Azure → Microsoft Entra ID → Inscriptions d'applications
Inscrivez une nouvelle application avec l'URI de redirection : {STIB_SERVER_ORIGIN}/api/auth/oidc/callback
Sous Certificats et secrets, créez un nouveau secret client
Dans Stib, sélectionnez Microsoft Entra ID dans le menu déroulant
Saisissez votre ID de tenant — l'URL de l'émetteur est construite automatiquement : https://login.microsoftonline.com/{tenant-id}/v2.0
Saisissez votre Client ID et Client Secret

INFO

Trouvez votre ID de tenant dans le Portail Azure sous Microsoft Entra ID → Vue d'ensemble. C'est la valeur « ID d'annuaire (tenant) ».

Keycloak

Dans l'administration Keycloak, créez un nouveau Client dans votre realm
Activez Authentification du client (Client authentication)
Définissez l'URI de redirection valide : {STIB_SERVER_ORIGIN}/api/auth/oidc/callback
Dans Stib, sélectionnez Keycloak dans le menu déroulant
Saisissez votre URL d'émetteur : https://votre-keycloak.example.com/realms/{nom-du-realm}
Saisissez votre Client ID et Client Secret

Fournisseur personnalisé

Tout fournisseur compatible OIDC fonctionne avec Stib. Le fournisseur doit :

Exposer un document de découverte à {issuer_url}/.well-known/openid-configuration
Supporter le flux d'autorisation par code avec PKCE
Retourner un id_token contenant les claims sub, email, et optionnellement name et picture

Dans Stib, sélectionnez Personnalisé dans le menu déroulant
Saisissez l'URL de l'émetteur de votre fournisseur
Saisissez votre Client ID et Client Secret
Ajustez les scopes si votre fournisseur utilise des noms de scopes non standard

Fonctionnement de la connexion SSO

Lorsqu'OIDC est activé, la page de connexion affiche un bouton « Se connecter avec {Fournisseur} » à côté du formulaire de connexion local.

Flux de connexion

L'utilisateur clique sur « Se connecter avec Google »
        │
        ▼
┌─────────────────────────────┐
│  Serveur Stib               │
│  GET /api/auth/oidc         │
│  • Génère le verifier PKCE  │
│  • Génère le state (CSRF)   │
│  • Stocke les deux en mémoire│
│  • Redirige vers le fournisseur│
└──────────┬──────────────────┘
           │  Redirection 302
           ▼
┌─────────────────────────────┐
│  Fournisseur d'identité     │
│  • L'utilisateur s'authentifie│
│  • L'utilisateur consent    │
│  • Redirige avec un code    │
└──────────┬──────────────────┘
           │  Redirection 302
           ▼
┌─────────────────────────────┐
│  Serveur Stib               │
│  GET /api/auth/oidc/callback│
│  • Valide le state (CSRF)   │
│  • Échange le code contre   │
│    les tokens via PKCE      │
│  • Valide l'ID token        │
│  • Provisionne l'utilisateur│
│  • Émet un JWT Stib         │
│  • Redirige vers le frontend│
└─────────────────────────────┘

Validation du token

L'ID token reçu du fournisseur est validé sur :

Émetteur (issuer) — doit correspondre à l'URL de l'émetteur configurée
Audience — doit contenir le Client ID configuré
Expiration — le token ne doit pas être expiré

INFO

Stib ne vérifie pas la signature cryptographique de l'ID token via JWKS. Le token étant reçu directement du fournisseur d'identité via TLS (point de terminaison token), la couche de transport garantit l'authenticité.

Provisionnement des utilisateurs

Stib utilise le provisionnement Just-In-Time (JIT) — les comptes utilisateurs sont créés automatiquement lors de la première connexion SSO.

Première connexion

Le serveur recherche l'utilisateur par le claim sub (subject) de l'ID token
S'il n'est pas trouvé, il vérifie que l'email ne soit pas en conflit avec le compte super administrateur
En l'absence de conflit, un nouvel utilisateur est créé avec :
- Rôle : user
- Fournisseur d'authentification : oidc
- Nom et avatar issus des claims de l'ID token (name, picture)
Les invitations de projet en attente correspondant à l'email de l'utilisateur sont automatiquement résolues

Connexions suivantes

À chaque connexion, le nom et l'avatar de l'utilisateur sont mis à jour depuis les derniers claims de l'ID token. Cela maintient les profils en synchronisation avec le fournisseur d'identité.

WARNING

Un utilisateur OIDC ne peut pas se connecter si son email correspond à celui du super administrateur. Le compte super administrateur est toujours un compte local.

SSO Mobile

L'application mobile Stib supporte le SSO via un flux de callback par deep link.

Flux de connexion mobile

L'application mobile initie l'authentification : GET /api/auth/oidc?mobile_redirect=stib://auth/callback
Le serveur redirige vers le fournisseur d'identité (même flux PKCE que le web)
Après authentification réussie, le serveur redirige vers : stib://auth/callback?token={jwt}
L'application mobile capture le deep link et stocke le token JWT

INFO

Le paramètre mobile_redirect doit utiliser le schéma stib://. Le serveur valide ceci pour prévenir les attaques de redirection ouverte.

Considérations de sécurité

PKCE (Proof Key for Code Exchange)

Stib utilise PKCE avec la méthode S256 pour tous les flux OIDC. Un code verifier et un challenge uniques sont générés pour chaque requête d'autorisation, empêchant les attaques d'interception du code d'autorisation même si un attaquant capture l'URL de callback.

Protection CSRF

Un paramètre state aléatoire est généré pour chaque requête d'autorisation. Le serveur valide le state lors du callback pour prévenir les attaques CSRF (Cross-Site Request Forgery). Les states expirent automatiquement après 10 minutes.

Chiffrement du client secret

Le client secret OIDC est chiffré au repos avec AES-256-GCM. La clé de chiffrement est dérivée du secret JWT interne (généré automatiquement, stocké en base de données) — ceci est séparé de STIB_ENCRYPTION_KEY, qui est utilisée pour les autres credentials comme les clés API Claude.

Dépannage

Erreurs OIDC courantes et leurs solutions :

Code d'erreur	Signification	Solution
`OIDC_NOT_ENABLED`	La configuration OIDC existe mais n'est pas activée	Allez dans Paramètres → Configuration OIDC et activez OIDC
`OIDC_CONFIG_INVALID`	Des champs de configuration requis sont manquants	Vérifiez que l'URL de l'émetteur, le Client ID et le Client Secret sont tous renseignés
`OIDC_STATE_INVALID`	Le paramètre state est manquant ou expiré	Réessayez de vous connecter — les states expirent après 10 minutes. Vérifiez que votre navigateur accepte les cookies.
`OIDC_TOKEN_INVALID`	L'ID token du fournisseur est malformé ou invalide	Vérifiez la configuration de votre fournisseur. Assurez-vous que le Client ID correspond.
`OIDC_EMAIL_CONFLICT`	L'email de l'utilisateur SSO correspond à l'email du super administrateur	Le compte super administrateur est toujours local. Utilisez un email différent pour le SSO.

TIP

Utilisez le bouton Tester la connexion dans les paramètres OIDC pour valider votre configuration avant d'activer le SSO. Il vérifie que le document de découverte et le point de terminaison JWKS sont accessibles.

Prochaines étapes

TIP

Maintenant que l'authentification est configurée, consultez ces guides connexes :

Configuration — Configuration générale du serveur et variables d'environnement
Identifiants & Scripts — Gérer les credentials chiffrés et les sauvegardes de base de données
Référence API — Points de terminaison API et en-têtes d'authentification

Authentification ​

Fonctionnement de l'authentification ​

Activer l'authentification ​

Variables d'environnement ​

Configuration OIDC SSO ​

Fournisseurs supportés ​

Paramètres requis ​

Mise en place d'OIDC ​

Guides par fournisseur ​

Google ​

Microsoft Entra ID ​

Keycloak ​

Fournisseur personnalisé ​

Fonctionnement de la connexion SSO ​

Flux de connexion ​

Validation du token ​

Provisionnement des utilisateurs ​

Première connexion ​

Connexions suivantes ​

SSO Mobile ​

Flux de connexion mobile ​

Considérations de sécurité ​

PKCE (Proof Key for Code Exchange) ​

Protection CSRF ​

Chiffrement du client secret ​

Dépannage ​

Prochaines étapes ​

Authentification

Fonctionnement de l'authentification

Activer l'authentification

Variables d'environnement

Configuration OIDC SSO

Fournisseurs supportés

Paramètres requis

Mise en place d'OIDC

Guides par fournisseur

Google

Microsoft Entra ID

Keycloak

Fournisseur personnalisé

Fonctionnement de la connexion SSO

Flux de connexion

Validation du token

Provisionnement des utilisateurs

Première connexion

Connexions suivantes

SSO Mobile

Flux de connexion mobile

Considérations de sécurité

PKCE (Proof Key for Code Exchange)

Protection CSRF

Chiffrement du client secret

Dépannage

Prochaines étapes