Authentification

ObjectOS utilise le plugin d'authentification ObjectStack, propulsé par Better Auth. L'authentification est locale au projet : chaque projet possède ses propres tables d'identité et sa propre portée de session.

Ce qui est pris en charge

Selon l'application packagée et les paramètres activés, ObjectOS peut prendre en charge :

• la connexion par e-mail/mot de passe ;
• la gestion des sessions ;
• la réinitialisation du mot de passe et la vérification de l'e-mail ;
• les fournisseurs OAuth sociaux tels que Google, GitHub, Microsoft et Apple ;
• l'OIDC/SSO d'entreprise tel qu'Okta, Entra ID, Keycloak et Ping ;
• l'authentification à deux facteurs ;
• les passkeys/WebAuthn ;
• les liens magiques ;
• le flux d'appareil CLI/navigateur.

Secret requis

Définissez :

OS_AUTH_SECRET=replace-with-a-strong-random-secret

ObjectOS dérive un secret stable propre au projet à partir de cette valeur et de l'identifiant d'environnement du projet. Cela signifie que :

• les sessions survivent aux redémarrages de conteneurs ;
• les jetons d'un projet ne peuvent pas être réutilisés sur un autre projet ;
• la rotation de OS_AUTH_SECRET invalide les sessions.

Consultez Environment variables pour la liste complète des paramètres liés à l'authentification, y compris l'alias hérité AUTH_SECRET.

Isolation des sessions

Dans les déploiements multi-projets, les cookies sont limités au nom d'hôte du projet. ObjectOS évite intentionnellement les cookies de domaine racine larges pour les sessions de projet. Cela empêche une session de fuiter d'un projet client à l'autre.

Connexion sociale

Configurez les identifiants des fournisseurs via des variables d'environnement ou des paramètres système, selon la manière dont le package applicatif expose la configuration de l'authentification.

Les URL de rappel des fournisseurs dépendent du type de fournisseur. ObjectStack expose deux chemins de rappel distincts et ils ne sont pas interchangeables :

Exemples :

https://crm.example.com/api/v1/auth/callback/google
https://crm.example.com/api/v1/auth/callback/microsoft
https://crm.example.com/api/v1/auth/oauth2/callback/okta
https://crm.example.com/api/v1/auth/oauth2/callback/entra

Configurez l'URI de redirection correspondante dans l'enregistrement de l'application du fournisseur d'identité avant d'activer le fournisseur dans ObjectOS.

OIDC/SSO d'entreprise

Les fournisseurs OIDC sont enregistrés comme des fournisseurs OAuth2 génériques et utilisent le chemin /api/v1/auth/oauth2/callback/<provider>. Une configuration typique requiert :

Pour les déploiements clients, préférez les URL de découverte OIDC aux points de terminaison authorization/token/userinfo configurés manuellement.

SSO de plateforme

Dans les déploiements connectés au cloud, ObjectOS peut utiliser la connexion du plan de contrôle comme fournisseur SSO de plateforme. Un constructeur déjà connecté au plan de contrôle peut être provisionné dans le runtime d'un projet sans créer un compte distinct local au projet.

Cela nécessite que le plan de contrôle et ObjectOS partagent le même secret de base OS_AUTH_SECRET. Désactivez le SSO de plateforme uniquement lorsque le client souhaite que chaque projet possède une frontière de connexion complètement distincte.

Vérifications opérationnelles

Avant la mise en production :

• confirmez que les jetons expirés renvoient 401 ;
• confirmez que la déconnexion révoque la session active ;
• confirmez que la réinitialisation du mot de passe révoque les autres sessions si la politique l'exige ;
• confirmez que les URL de rappel correspondent au domaine public du projet ;
• confirmez que les origines de confiance n'incluent que des domaines approuvés ;
• confirmez que OS_AUTH_SECRET est stocké dans un gestionnaire de secrets, et non dans le code source.

Étapes suivantes

L'authentification établit qui est un utilisateur. Pour contrôler ce à quoi il peut accéder une fois connecté, consultez Permissions. Pour les clients non navigateur et l'accès de machine à machine, consultez API access.