Sécurité, sessions, authentification unique et MFA

Des sessions réellement révocables

Une connexion dans le navigateur émet une session de plateforme, et le serveur en conserve la trace : un jeton n'est accepté que tant que sa trace est active. La durée absolue, le délai d'inactivité et la révocation sont donc décidés côté serveur, et non confiés au navigateur.

Sécurité et sessions liste vos sessions actives, vous permet de vous déconnecter partout sauf sur la session en cours, et donne aux propriétaires et administrateurs une vue sur toute l'organisation avec révocation par membre, pour le cas d'un départ ou d'un appareil perdu. Création et révocation de session sont toutes deux écrites dans la piste d'audit.

La politique d'authentification

La page de politique fixe les règles pour toute l'organisation : exiger un second facteur, exiger l'authentification unique, exiger une session gérée par la plateforme, la durée de session, le délai d'inactivité et les méthodes de connexion autorisées.

Deux détails de conception comptent en pratique. Exiger l'authentification multifacteur demande une fenêtre de grâce, afin que l'activer ne bloque pas l'équipe en écriture dans la même minute. Et exiger l'authentification unique est refusé s'il n'existe aucune connexion active, car un réglage qui enferme tout le monde dehors est un défaut, pas une politique. Les refus portent un code lisible par machine - session non gérée, authentification unique requise, second facteur requis ou enrôlement requis - et la console en fait le bon écran plutôt qu'une impasse.

Liste d'adresses autorisées

La politique peut aussi restreindre l'origine des accès : indiquez des adresses IP ou des plages CIDR (IPv4 ou IPv6), et les membres comme les clés API ne peuvent alors atteindre les données de l'organisation que depuis ces réseaux. Une clé API copiée utilisée ailleurs est refusée.

La page affiche l'adresse depuis laquelle vous vous connectez, et une liste qui l'exclurait est refusée : impossible de vous enfermer dehors par erreur. Restreindre la liste est ouvert aux administrateurs ; ajouter une plage ou vider la liste élargit l'accès et demande un propriétaire.

Authentification multifacteur

L'enrôlement renvoie une seule fois le secret et un QR code, confirme avec un code en cours de validité et émet des codes de récupération stockés hachés et utilisables une fois chacun. Un code d'un pas précédent est rejeté comme rejeu, et un pas de dérive d'horloge est accepté.

Dès qu'un compte possède un facteur confirmé, en ajouter un, en retirer un ou régénérer les codes de récupération exigent tous un code valide d'un facteur existant : une session volée ne suffit donc pas à réenrôler un compte. Les codes erronés sont limités par compte et chaque échec est audité, ce qui rend une tentative visible.

Authentification unique

Une connexion configure SAML 2.0 ou OIDC pour l'organisation, dessert les domaines de courriel revendiqués et provisionne les utilisateurs à la première connexion avec le rôle issu des groupes annoncés. Importer les métadonnées du fournisseur d'identité affiche l'empreinte du certificat pour que vous puissiez la confirmer par un autre canal ; la plateforme publie aussi ses propres métadonnées pour le fournisseur.

Les assertions sont vérifiées uniquement contre le certificat configuré, et la partie signée du document est celle qui est lue : une réponse qui encapsule une assertion signée dans une assertion non signée échoue donc. Destinataire, audience, corrélation de requête et fenêtre de validité sont tous contrôlés, et une connexion est à usage unique.

Une limite assumée : la connexion est initiée uniquement par le fournisseur de service. Une réponse qui arrive sans requête de notre part est refusée, ce qui rend impossible le rejeu d'une assertion capturée. Testez le contrôle de préparation de la connexion avant de l'imposer.

Révoquer l'accès d'une personne

1. Ouvrez Utilisateurs et passez le compte en lecteur, ou retirez l'appartenance.
2. Ouvrez Sécurité et sessions et révoquez les sessions de cette personne.
3. Si le provisionnement vient de votre fournisseur d'identité, déprovisionnez le compte là-bas : cela désactive l'utilisateur, retire les appartenances et révoque les sessions actives.
4. Consultez la piste d'audit pour confirmer ce qui s'est passé et quand.

Référence page par page

Ces pages ont été vérifiées dans la console de l'organisation le 8 octobre 2026 avec une organisation de démonstration isolée. Les commandes varient selon le rôle, le forfait, l'état du dossier et les fournisseurs configurés. Les explications pratiques et les noms des commandes ci-dessous suivent l'interface anglaise vérifiée.

Security and sessions (/settings/security)

The page combines this sign-in's method, MFA enrollment, personal and organization sessions, policy controls and security posture.

Review active sessions and MFA enrollment before changing organization sign-in policy. A stricter MFA, SSO, managed-session, or network requirement can affect current members, so check posture and provider readiness first. Save the policy with the appropriate authority, then verify a normal sign-in path and revoke sessions that should no longer remain active.

Relaxing a policy requires the owner; a stricter policy can immediately affect sign-in.

Commandes et options

• Add an authenticator app, confirm a code and store recovery codes securely before relying on MFA.
• Revoke a session or Sign out of other sessions to end unwanted access.
• Set MFA, SSO, managed-session and network rules, session lifetime and idle timeout; Save policy applies allowed changes.
• Inspect Security posture for unmet requirements and organization sessions for active devices.

Single sign-on (/settings/sso)

SSO connects a claimed email domain to a SAML or OIDC identity provider and records linked identities and recent sign-ins.

Claim only domains the organization controls and configure SAML or OIDC values from the identity provider's verified settings. Test a complete sign-in and inspect recent requests before enabling enforcement or automatic member creation. A default role controls starting access, while plan seats and organization policy still limit who can join.

A connected IdP does not prove every user of a domain is authorized for this organization.

Commandes et options

• Choose protocol, name, claimed domains and default role for just-in-time members.
• Enter the IdP endpoint, entity or client data and certificate as required, then Create connection.
• Provision members on first sign-in, require MFA or refuse alternative methods only after testing the connection.
• Use Configured connections and Recent sign-in requests to diagnose redirects and claims.

SCIM provisioning (/settings/provisioning)

SCIM lets an identity provider create, update and deactivate this organization's members using a scoped token.

Create a separate SCIM token for the identity-provider connector and copy it once into the provider's secure configuration. Use the displayed base URL and schemas to test user and group creation, update, and deactivation. Review Team after the first sync for seat limits, role assignment, and account status; rotate or revoke the token when the connector changes.

SCIM cannot change the organization's owner through this connection.

Commandes et options

• Create a named SCIM token and copy it once into the identity provider.
• Use the displayed base URL and schema notes to configure user and group provisioning.
• Rotate or revoke tokens when the connector or operator changes.
• Check Team after a sync to confirm roles, seat use and account status.