Quand j’ai commencé ma carrière de développeur, je ne comprenais pas l’utilité d’un SSO. Implémenter un mécanisme de connexion avec e-mail et mot de passe semblait une tâche triviale: quelques heures à peine, et hop, le tour est joué. Mais j’ai rapidement réalisé à quel point j’étais naïf.

DDOS, credential stuffing, SMS toll fraud, phishing… Ce ne sont que quelques-unes des attaques que j’ai eu la (mal) chance de devoir gérer ces dernières années. Bien que désagréables, ces attaques ont déjà des solutions bien documentées et éprouvées. Réimplémenter ces solutions avec du code sur mesure à chaque fois est une perte de temps et d’argent dans bien des cas. Ceci étant dit, il est essentiel d’aligner son modèle d’affaires avec la structure de coûts du fournisseur de SSO. Sinon, le succès de votre produit pourrait rapidement devenir un problème financier!

Abonnement SAAS

Les solutions SaaS utilisent généralement une structure de coûts basée sur un abonnement mensuel. Cette structure est idéale pour l’adoption d’une solution SSO, car les coûts augmentent de manière proportionnelle aux revenus.

Prenons un exemple simple : un SaaS proposant un abonnement mensuel à 7 $ souhaite utiliser le plan Essentiel d’Auth0, qui coûte environ 7 sous par utilisateur actif et par mois. Dans ce cas, il est facile pour le département de finance de budgéter le coût du SSO en fonction de la croissance prévue. De plus, dans la réalité, une proportion des utilisateurs ne sera pas active certains mois : ils paieront l’abonnement mensuel de 7 $, mais vous ne serez pas facturé pour le SSO. Ainsi, le coût moyen réel d’un SSO par utilisateur est généralement inférieur au tarif officiel en raison de cette disparité entre les frais facturés aux utilisateurs et ceux liés au SSO.

Plan gratuit

Les choses se compliquent pour une application qui offre un free tier. En effet, les utilisateurs qui opteront pour le plan gratuit ne généreront pas de revenus directement, mais vous serez tout de même facturé pour le SSO. La majorité de ces plans sont conçus pour inciter les utilisateurs à passer à un plan payant, indépendamment de l’utilisation du SSO. Cependant, il est crucial de maintenir un taux de conversion cohérent au fil du temps.

Par exemple, si vous décidez d’ajouter une fonctionnalité gratuite très attrayante qui augmente significativement le nombre d’utilisateurs gratuits mais réduit le taux de conversion vers le plan payant, ceci pourrait entraîner des conséquences financières désagréables. Si 100 000 utilisateurs gratuits supplémentaires s’inscrivent, votre facture Auth0 augmentera d’environ 10 000 $ par mois!

Application à but non lucratif

Chez Thirdbridge, plusieurs de nos clients souhaitent offrir un produit dont l’objectif principal n’est pas de générer des revenus. Dans ce contexte, il est crucial de choisir une technologie SSO adaptée. Par exemple, pour une OBNL qui souhaite créer un portail sécurisé avec une authentification multifacteur pour environ 10 000 utilisateurs, le coût annuel peut varier considérablement:

• Avec Auth0, ça coûterait environ 16 000 USD par an. • Avec AWS Cognito, ça serait gratuit.

Dans ce cas, le choix logique pour une OBNL est, sans aucun doute, AWS Cognito! Il est également intéressant de noter que d’autres alternatives abordables, telles qu’Azure AD B2C, existent. L’écosystème technologique déjà en place devient alors un facteur clé à considérer dans le processus de prise de décision.

Dans le doute, restez prudent

La réalité est que choisir une technologie de SSO n’est pas une tâche facile. Plusieurs facteurs imprévisibles peuvent invalider la décision prise initialement. De plus, malgré tout l’amour que nous avons pour le produit Auth0 (notre équipe CIAM est certifiée CIC), force est de reconnaître que ce type de technologie est extrêmement invasif. Une fois implémentée, il devient très difficile de migrer vers un concurrent ou de construire une solution interne. C’est probablement pourquoi Auth0 peut se permettre des hausses de prix aussi vertigineuses*.

La meilleure manière de réduire ce risque est de s’aligner autant que possible sur les standards de l’industrie. L’écrasante majorité des solutions SSO s’appuient sur les protocoles OAuth2, OIDC et SAML comme fondations. En utilisant des fonctionnalités standardisées conformes à ces protocoles, une hypothétique migration serait beaucoup plus facile. Cependant, en pratique, il est presque impossible de construire une solution complète uniquement de cette manière. Bref, il faudra faire des compromis et choisir son poison!