What does SSO stand for, and what problem does it solve?

SSO stands for Single Sign-On. It is an authentication pattern that lets a user sign in once with their corporate identity provider and then access multiple downstream applications — including SecureCodingHub — without re-entering credentials. The point is not just convenience; it lets your security team enforce password policy, MFA, and offboarding in one place rather than per-application.

SSO vs SAML — are they the same thing?

No. SSO is the user-facing pattern; SAML is one of the protocols that can implement it. When you compare SSO vs SAML, the cleaner framing is that SAML 2.0 is a federation standard that carries the authentication assertion from your identity provider to the application, and SecureCodingHub speaks it. OIDC (built on OAuth 2.0) is the modern alternative for the same SSO outcome.

SSO vs OAuth — what is the actual difference?

The SSO vs OAuth distinction trips people up because OIDC sits on top of OAuth 2.0. OAuth 2.0 by itself is an authorization framework — it grants an application access to a resource. OIDC adds an identity layer on top, which is what makes OAuth-based SSO possible. So OAuth 2.0 alone does not give you SSO; OIDC over OAuth 2.0 does.

Can I use SSO with an open source identity provider?

Yes. Because SecureCodingHub supports the open standards — SAML 2.0 and OIDC — any open source SSO identity provider that implements them works. Keycloak, Authentik, and Zitadel are common picks for teams that want to self-host the IdP. The configuration steps on the SecureCodingHub side are identical to those for Azure AD or Okta; you supply the metadata or discovery URL and map the attributes.

Vue d'ensemble SSO

SecureCodingHub prend en charge l'authentification unique via OpenID Connect (OIDC) et SAML 2.0. SSO permet à votre équipe de se connecter avec son fournisseur d'identité d'entreprise — aucun mot de passe séparé nécessaire.

Protocoles pris en charge

SecureCodingHub prend en charge deux protocoles SSO standards de l'industrie :

OIDC (OpenID Connect)

Protocole moderne basé sur OAuth 2.0. Recommandé pour Azure AD, Okta et la plupart des fournisseurs d'identité cloud. Utilise le flux de code d'autorisation avec PKCE.

SAML 2.0

Protocole de fédération basé sur XML. Pris en charge pour les fournisseurs d'identité hérités et les environnements d'entreprise.

Comment fonctionne SSO

Lorsque SSO est configuré pour votre organisation, le flux de connexion fonctionne comme suit :

L'utilisateur navigue vers la connexion SecureCodingHub

Atterrit sur le point d'entrée SSO de son organisation (le lien porte le slug de l'organisation ; il n'y a pas de détection automatique du domaine e-mail aujourd'hui)

Le navigateur redirige vers votre fournisseur d'identité (Azure AD, Okta, etc.)

L'utilisateur s'authentifie avec ses identifiants d'entreprise

L'IdP redirige vers SecureCodingHub avec un token d'authentification

SecureCodingHub crée une session et connecte l'utilisateur

Provisionnement JIT

Lorsque SSO est activé, les utilisateurs sont créés automatiquement à la première connexion — c'est ce qu'on appelle le provisionnement Just-In-Time (JIT). Les nouveaux utilisateurs se voient attribuer le rôle Apprenant par défaut. Votre organisation doit avoir des sièges disponibles pour que les nouveaux utilisateurs soient provisionnés.

URL de configuration

Utilisez les URL suivantes lors de la configuration de votre fournisseur d'identité :

Paramètre	Valeur
URL de rappel OIDC	`https://api.limeplate.com/api/sch/auth/sso/callback/oidc`
URL ACS SAML	`https://api.limeplate.com/api/sch/auth/sso/callback/saml`
URL de métadonnées SP	`https://api.limeplate.com/api/sch/auth/sso/metadata`

Note : La configuration SSO nécessite l'accès Administrateur de l'organisation ou Administrateur de plateforme. Voir les guides de configuration Azure AD ou Okta pour commencer.

Choisir entre SAML et OIDC

Si votre fournisseur d'identité prend en charge les deux protocoles, la réponse pratique est de choisir ce que votre équipe de sécurité opère et auquel elle fait déjà confiance. OIDC est le protocole le plus récent, basé sur JSON, construit sur OAuth 2.0. Il est plus convivial pour développer, plus facile à déboguer et l'option par défaut dans la plupart des IdP modernes, y compris Azure AD et Okta. Pour les organisations qui se standardisent sur l'outillage cloud-natif, OIDC est généralement le bon choix.

SAML est le standard de fédération plus ancien, basé sur XML, et il reste le choix le plus courant dans les environnements d'entreprise. La raison est rarement une préférence technique. C'est que l'équipe IdP gère déjà des dizaines d'intégrations SAML, le calendrier de rotation des certificats est établi et le playbook interne pour le dépannage SAML est mature. Si vous déployez dans un environnement avec PingFederate, ADFS ou un IdP SAML hérité, choisir SAML vous permet de réutiliser les schémas existants au lieu de demander à l'équipe IdP de prendre en charge une intégration OIDC unique. L'un ou l'autre protocole fournit une sécurité équivalente ; le choix concerne l'adéquation opérationnelle, non la cryptographie.

Checklist pré-SSO

Avant d'activer SSO en production, planifiez autour de trois réalités. Premièrement, configurez un environnement de test ou utilisez un tenant que vous contrôlez de bout en bout. Un SSO mal configuré peut verrouiller tout le monde dehors, y compris l'administrateur qui l'a configuré. Exécutez le flux de connexion complet contre une organisation non critique d'abord, idéalement avec une application IdP jetable, pour pouvoir itérer sur le mappage d'attributs sans urgence. Deuxièmement, gardez au moins un compte administrateur de secours qui ne dépend pas de SSO. SecureCodingHub honore un chemin d'administrateur local de bris de glace, et le moment de le tester est avant que SSO ne passe en production, pas à 21h un vendredi quand quelque chose a mal tourné.

Troisièmement, réfléchissez à l'impact en aval sur les flux d'invitation par e-mail. Une fois SSO actif, les utilisateurs de votre domaine vérifié sont redirigés vers l'IdP et provisionnés JIT à la première connexion. Cela signifie qu'un administrateur qui invite manuellement des utilisateurs par e-mail et un administrateur d'annuaire qui attribue l'application dans l'IdP peuvent tous deux créer des comptes, et les deux flux entreront en collision si vous n'en choisissez pas un. Le schéma plus propre est de désactiver les invitations manuelles pour le domaine géré par SSO et de laisser l'IdP être la seule source de vérité. Voir le Guide de configuration SAML et les guides spécifiques au protocole pour la prochaine étape.

SSO : questions fréquentes

Que signifie SSO et quel problème résout-il ?

SSO signifie Single Sign-On (Authentification unique). C'est un schéma d'authentification qui permet à un utilisateur de se connecter une seule fois avec son fournisseur d'identité d'entreprise puis d'accéder à plusieurs applications en aval — y compris SecureCodingHub — sans ressaisir les identifiants. Le but n'est pas seulement la commodité ; cela permet à votre équipe de sécurité d'imposer la politique de mot de passe, MFA et la désinscription en un seul endroit plutôt que par application.

SSO vs SAML — sont-ils la même chose ?

Non. SSO est le schéma orienté utilisateur ; SAML est l'un des protocoles qui peuvent l'implémenter. Lorsque vous comparez SSO vs SAML, le cadrage plus propre est que SAML 2.0 est un standard de fédération qui porte l'assertion d'authentification de votre fournisseur d'identité vers l'application, et SecureCodingHub le parle. OIDC (construit sur OAuth 2.0) est l'alternative moderne pour le même résultat SSO.

SSO vs OAuth — quelle est la différence réelle ?

La distinction SSO vs OAuth fait trébucher les gens parce que OIDC est posé sur OAuth 2.0. OAuth 2.0 en soi est un cadre d'autorisation — il accorde à une application l'accès à une ressource. OIDC ajoute une couche d'identité par-dessus, ce qui rend possible le SSO basé sur OAuth. Donc OAuth 2.0 seul ne vous donne pas SSO ; OIDC sur OAuth 2.0 le fait.

Puis-je utiliser SSO avec un fournisseur d'identité open source ?

Oui. Parce que SecureCodingHub prend en charge les standards ouverts — SAML 2.0 et OIDC — tout fournisseur d'identité SSO open source qui les implémente fonctionne. Keycloak, Authentik et Zitadel sont des choix courants pour les équipes qui veulent auto-héberger l'IdP. Les étapes de configuration côté SecureCodingHub sont identiques à celles pour Azure AD ou Okta ; vous fournissez l'URL de métadonnées ou de découverte et mappez les attributs.