Authentification

Méthodes d'authentification

Choisissez la méthode d'authentification qui correspond le mieux à votre organisation :

Flux Magic Code

Le flux d'authentification sans mot de passe par défaut fonctionne comme suit :

Flux SSO

Lorsque SSO est configuré pour votre organisation, le flux d'authentification change :

Tokens JWT

Toutes les sessions authentifiées orientées navigateur sont gérées en utilisant des JSON Web Tokens émis par le backend après que l'étape Magic Code ou SSO réussit.

API Key Bearer (API publique)

La surface REST publique et webhook sous /api/public/v1/* utilise des clés API à longue durée de vie au lieu de JWT. Les clés sont créées depuis la console d'administration sous Organisation → Clés API et envoyées à chaque requête comme un en-tête bearer standard :

Authorization: Bearer scs_live_…

Référence complète à API → Authentification et portées.

Limitation de débit

Chaque clé API publique est limitée par deux fenêtres glissantes qui protègent la plateforme contre les scripts hors contrôle et empêchent un tenant d'en affamer un autre :

Les requêtes qui dépassent l'une ou l'autre fenêtre reçoivent 429 rate_limited avec un en-tête Retry-After en secondes. Un limiteur basé sur IP séparé (5 requêtes / 15 minutes) couvre le formulaire de contact web anonyme. Le trafic de session navigateur interne contre l'API d'administration protégée par JWT n'est pas limité en débit aujourd'hui.

Conseils détaillés sur les réessais et un client de backoff exponentiel d'exemple à API → Limites de débit.

Journalisation d'audit

Chaque action mutante — qu'elle provienne d'un utilisateur administrateur dans le navigateur ou d'une clé API publique — est écrite dans une table de journal d'audit par organisation. Les actions en lecture seule (liste, get, requêtes du tableau de bord) ne sont pas auditées ; l'accent est mis sur les changements qui ont un impact en aval.

Le flux d'audit complet peut être interrogé depuis l'interface admin (Organisation → Journal d'audit) ou par programme via GET /api/public/v1/audit-log. Les deux surfaces prennent en charge le filtrage par action, acteur et plage de dates, et l'interface admin expose un export CSV pour les dossiers de preuves.

Sécurité des sessions

• Les tokens sont validés à chaque requête API
• Les tokens invalides ou expirés sont rejetés
• Les sessions SSO respectent les politiques de session IdP
• Les codes magiques sont à usage unique et limités dans le temps

Choix de conception d'authentification que SecureCodingHub a faits et pourquoi

Le chemin d'authentification par défaut sur SecureCodingHub est sans mot de passe. Nous avons pris cette décision délibérément. La grande majorité des compromissions d'identifiants que nous voyons dans les données de formation client remontent encore à la réutilisation de mots de passe, aux choix de mots de passe faibles et au phishing de secrets statiques. Retirer le mot de passe du flux de connexion principal élimine une classe de modes de défaillance qu'aucune politique ne peut entièrement atténuer. Pour les organisations qui exigent une solution de repli par mot de passe traditionnelle, nous imposons des minimums cohérents avec les directives NIST actuelles : un plancher de longueur plutôt qu'un jeu de règles de complexité, un filtrage par rapport aux corpus de mots de passe connus compromis et pas de rotation forcée en l'absence de preuve de compromission.

La récupération basée sur e-mail est intentionnellement conservée même pour les comptes adossés à SSO. Lorsqu'un fournisseur d'identité devient inaccessible, ou lorsque l'entrée d'annuaire d'entreprise d'un contractant est supprimée en cours de mission, nous avons toujours besoin d'un chemin déterministe et auditable de retour dans le compte pour le propriétaire vérifié. Le canal de récupération est limité en débit, à usage unique et journalisé séparément du flux d'événements de connexion standard pour que les équipes de sécurité puissent détecter une activité de récupération anormale sans qu'elle ne se perde dans le bruit de connexion normal.

Les comptes partagés sont découragés au niveau du produit plutôt que bloqués purement et simplement. Nous affichons un avertissement dans la console d'administration lorsque les schémas d'utilisation suggèrent qu'un seul siège est partagé entre plusieurs humains, car les sièges partagés cassent la responsabilité individuelle, faussent les rapports de progression et compliquent toute enquête d'incident future. Les organisations qui ont besoin d'un accès inter-équipes aux tableaux de bord devraient utiliser l'attribution de rôle et les rôles apprenant provisionnés SCIM décrits dans Sécurité des données plutôt que de réutiliser les identifiants.

Mappage de l'authentification à la conformité

SecureCodingHub se prépare pour SOC 2 Type II et n'a pas encore terminé un audit, donc nous ne revendiquons pas de certification. Cependant, nous concevons le sous-système d'authentification par rapport aux mêmes familles de contrôles qu'une équipe de sécurité attendrait lors de l'évaluation d'un fournisseur pour cet audit. Les attentes SOC 2 CC6.1 concernant l'accès logique — identification unique de chaque utilisateur, élévation multi-facteurs ou équivalente pour les actions sensibles et révocation à la fin du contrat — sont traitées via des comptes par utilisateur, le code magique ou l'identifiant émis par IdP comme deuxième facteur et la désinscription pilotée par SCIM.

Les contrôles de l'Annexe A.9 d'ISO 27001 couvrant la politique de contrôle d'accès, l'enregistrement des utilisateurs et l'accès privilégié sont traités via des définitions de rôle documentées, un enregistrement à portée d'organisation restreint aux domaines vérifiés là où demandé et la séparation explicite des rôles org_admin / learner à l'intérieur de chaque tenant. Pour les organisations soumises à la section 8 de PCI DSS, le contrôle pertinent est que nous ne stockons jamais de données de titulaires de carte et n'authentifions jamais les titulaires de carte contre la plateforme ; SecureCodingHub est un environnement de formation, non un environnement de paiement, donc la surface à laquelle PCI s'applique est intentionnellement étroite.

Rien de ce qui précède ne doit être lu comme un substitut à votre propre évaluation. Des packs de preuves comprenant les listes de sous-traitants, les diagrammes de flux de données et la posture d'audit actuelle sont disponibles sur demande à security@securecodinghub.com.

Ce qui change quand SSO est activé

Activer SSO n'est pas juste un échange d'un écran de connexion pour un autre — cela change plusieurs comportements d'exécution que les équipes de sécurité devraient comprendre avant le déploiement. Une fois votre organisation connectée à un fournisseur d'identité, le chemin de code magique local n'est plus offert aux utilisateurs dont l'e-mail correspond à votre domaine vérifié. Ils sont redirigés vers votre IdP à la place. C'est le défaut correct, mais cela signifie que la récupération pendant une panne IdP se déplace entièrement vers votre équipe IT plutôt que le support SecureCodingHub. Nous recommandons de documenter ce chemin d'escalade en interne avant d'activer SSO pour une grande base d'utilisateurs.

Le comportement de verrouillage se déplace également : les tentatives échouées limitées en débit sur le chemin de code magique local ne s'appliquent plus au même utilisateur une fois SSO en vigueur, car toute la validation d'identifiants se passe chez l'IdP. La politique de verrouillage est alors gouvernée par votre configuration IdP, non par les défauts SecureCodingHub. Les entrées du journal d'audit écrites par les mutations que l'utilisateur effectue après la connexion continuent de porter l'e-mail de l'utilisateur et le rôle org_admin / learner ; la plateforme ne stocke actuellement pas la méthode d'authentification côté IdP (par exemple, si MFA a été satisfait chez l'IdP) sur la ligne d'audit, donc pour ce niveau de détail vous corréleriez contre le flux de journaux de votre fournisseur d'identité central.