Que faire alors de ce mot de passe en attendant sa potentielle disparition ? Comment réduire l’impact de ce qui est aujourd’hui le principal point de friction du parcours utilisateur, tout en sécurisant mieux ses services ?

Pourquoi le mot de passe est-il si répandu ?

Les mots de passe sont utilisés depuis longtemps comme un moyen d’accès, par exemple aux clubs secrets et/ou clandestins. Ce système historique de gestion des accès « si j’ai le secret, alors j’ai le droit d’entrer » s’est transformé lors de son passage dans le monde informatique en un moyen de prouver son identité – « si j’ai le secret, alors je suis qui je dis que je suis ». L’insertion de caractères dans un certain ordre connu uniquement de l’utilisateur ayant droit d’accès, est ainsi devenue la solution pour lui permettre de prouver son identité.

Si les faiblesses de ce système se sont très vite révélées, tant que les systèmes informatiques n’étaient pas connectés et nécessitait donc un accès physique, la surface d’attaque restait limitée. Le mot de passe est donc devenu un pilier de la sécurité IT et est utilisé dans quasiment tous les services demandant une gestion de l’utilisateur.

Cependant, l’arrivée des réseaux, notamment internet, et par conséquent l’agrandissement de la surface d’exposition ont fait évoluer ces faiblesses en de réelles vulnérabilités.

Comment en est-on arrivé à mettre sur le chemin de l’utilisateur une telle complexité ?

Le nombre élevé de possibilités d’attaque sur les mots de passe ont petit à petit amené les experts de la sécurité à multiplier les mesures de protection censées sécuriser l’utilisation des mots de passe.

Ainsi, sont apparus un certain nombre de mesures autour du mot de passe et des processus associés complexifiant toujours plus les parcours utilisateurs. Par exemple:

• Nombre de caractères minimum
• Complexité (1 chiffre, une lettre, un caractère spécial, etc.)
• Liste de mots interdits
• Recommandation d’unicité du mot de passe entre les services
• Renouvellement périodique & historique

Ces règles, en grande partie issues des recommandations passées du National Institute of Standards and Technology (NIST), NIST.SP.800-63-2, 2015, et que l’on retrouvait dans la plupart des frameworks de sécurité (UK, français, etc.) impactent négativement l’expérience utilisateur. Souvent peu intuitives et différentes d’un service à l’autre, leur compréhension par l’utilisateur peut relever du défi : manque d’explication claire sur la complexité attendue, pas de compteur de tentatives erronés avant le verrouillage du compte, ou encore expérience variant en fonction du canal d’accès utilisé (l’accessibilité de certains caractères spéciaux variant grandement d’un terminal à l’autre, par exemple : le caractère « § » sur un iPhone ou un iPad).

Et pour quelle efficacité ?

Malgré toutes ces mesures, le mot de passe reste largement décrié pour son faible niveau de sécurité, car il repose sur deux principes peu compatibles avec un fort niveau de sécurité.

Le principe même sur lequel le mot de passe repose, le secret partagé, entraine deux vecteurs d’attaque :

• Données en transit – transmettre le secret régulièrement : le mot de passe peut alors fuiter/être volé via un proxy trop informatif dans ses logs, une mise en cache dans la mémoire partagée d’un Smartphone, ou des malwares de type keylogger.
• Données au repos – stocker le mot de passe entreprise pour le vérifier : l’utilisation de méthodes de stockage avec des niveaux de sécurité faible reste trop répandu (chiffrement réversible au lieu de hash non-réversible, protocole ancien type sha-1, pas de salage, ou pire, stockage en clair).

Et même des protocoles de hachage plus récents restent potentiellement faillibles face aux puissances de calcul actuelles. Par exemple, même avec un protocole récent de hashage type sha256, retrouver un mot de passe de 8 caractères depuis son hash prendra… moins d’une journée.

Les attaquants peuvent ainsi récupérer directement le mot de passe faisant fi de sa complexité (si ce n’est la longueur pour le brute force et le stockage si utilisation d’un protocole de hash récent, robuste et régulièrement mise à jour).

La place prépondérante de l’humain dans le système et sa capacité à commettre des impairs – error humanum est – a un impact encore plus important :

• Nous sommes de mauvais générateurs d’aléatoire : cela explique notamment les listes de mots de passe les plus courants paraissant chaque année. De plus, les contraintes de création trop fortes, réduisant les possibilités de variations, limitent la création de mot de passe différent, baissant le niveau d’entropie. La complexité devient contre-productive.
• Nous avons mauvaise mémoire : favorisant des pratiques abaissant le niveau de sécurité (utilisation d’un dérivé voir du même mot de passe – 63% des utilisateurs admettant cette pratique – post-it sur le bureau, fichier .txt non chiffré, etc.)
• Nous sommes faciles à tromper : le phishing, le spearphishing et l’ingénierie sociale sont ainsi des vecteurs d’attaque largement répandue et toujours très efficaces.

Si l’utilisateur fournit son mot de passe à l’attaquant, il ne fait aucune importance qu’il fasse 60 caractères de long ou soit composé de lettre de différents alphabets.

La complexité du mot de passe n’a ainsi pas d’influence pour les types d’attaque les plus courants, et n’induit donc que du désagrément pour l’utilisateur.

Que faire ?

Les problématiques autour des mots de passe n’étant pas récentes, il existe plusieurs solutions possibles et combinables pour réduire les problèmes et leurs impacts. La délégation de l’authentification vers des services tiers (social login, IAM d’entreprise, etc.), et la mise en place de Single Sign-On ont ainsi facilité les parcours utilisateurs et limité les rejeux / transitions du mot de passe et les endroits où le mot de passe est stocké au repos.

L’utilisation de seconds facteurs d’authentification (OTP SMS ou mail, notification push, hard tokens, etc.), les plus récents étant moins intrusifs et moins perturbateurs, est indispensable pour élever le niveau de sécurité.

En plus de ces solutions, déjà éprouvées et largement déployées, et dans l’attente d’être prêt à entrer dans le monde du passwordless qui représente un projet à part entière, le NIST et d’autres frameworks ont récemment révisé leurs recommandations concernant la complexité requise autour des mots de passe (NIST.SP.800-63b, 2017, NCSC UK, Password policy : updating your approach, 2018 par exemple).

Ainsi, d’un point de vue utilisateur, les contraintes sur les mots de passe ont été réduites à un nombre de caractères minimal (8) et la blacklist des mots de passe courant/compromis. En contrepartie, des mesures offrant plus de liberté à l’utilisateurs sont recommandés :

• Tous les caractères Unicode, incluant l’espace doivent être autorisés, sans être forcés
• La limite de taille maximale doit être au moins de 64 caractères
• Les rotations ne doivent plus se faire sur une notion de temps, mais uniquement en cas de compromission
• L’utilisateur doit avoir au moins 10 tentatives avant d’être bloqué
• Différents agréments de parcours sont à prendre en compte (information sur la complexité attendues, capacité d’afficher le mot de passe en cours de saisie, capacité de coller des valeurs)

Ces nouvelles recommandations visent à orienter les utilisateurs vers l’utilisation de mot de passe plus long et surtout plus aléatoires en réduisant les contraintes. Elles peuvent être accompagnées par la mise en place / la sensibilisation à l’utilisation de coffre-fort de mot de passe, évitant à l’utilisateur d’avoir à se souvenir de trop de mot de passe.

Les autres recommandations, indispensables pour ne pas abaisser le niveau de sécurité, affinent certains aspects précédemment évoqués. Ces mesures visent également à renforcer la transmission (chiffrement, etc.) et le stockage (hashage, salage) afin d’augmenter le niveau de sécurité des activités de l’entreprise et d’empêcher l’utilisation de certaines pratiques qui diminuent la sécurité (utilisation de questions secrètes pour la réinitialisation du mot de passe, etc.)

Conclusion

Si la disparition du mot de passe est un objectif, sa réalisation est encore loin d’être effective. Il est nécessaire, avant d’en arriver à ce Graal, de mettre en œuvre les mesures visant à la fois à sécuriser les données de l’utilisateur. Par exemple en implémentant de l’authentification multi-facteur sur les services sensibles, tout en facilitant les parcours et en encourageant l’utilisateur à se protéger lui-même. Cela passe par la mise en place d’éléments évitant à l’utilisateur de se connecter trop souvent ou de créer trop de mots de passe, mais également par une refonte de la complexité des mots de passe, afin d’augmenter la part d’aléatoire, et par une mise à niveau technique des moyens de transmissions et de stockage.

L’utilisation des processus existants pour préparer les facteurs de demain est aussi indispensable. Ainsi, refondre le parcours de récupération du mot de passe pour orienter l’utilisateur vers de l’authentification passwordless peut aider à une transition en douceur vers plus de sécurisation tout en améliorant l’expérience utilisateur.

Cet article L’évolution des règles de complexité des mots de passe du NIST : une étape indispensable en attendant un monde sans mot de passe ? est apparu en premier sur RiskInsight.

Notamment, avec l’explosion des IoT et les réglementations tels que la DSP2, le besoin de déclencher des authentifications décorrélées du medium d’accès de l’utilisateur se fait de plus en plus présent : en effet, ce dernier ne dispose peut-être pas des interfaces nécessaires, ou peut ne pas être reconnu comme un support suffisamment sécurisé.

La cinématique additionnelle CIBA, Client Initiated Backchannel Authentication Flow a pour but de définir les échanges et les appels permettant de déclencher des tels authentifications. Ce premier article a pour but de décrire brièvement le fonctionnement haut niveau de cette cinématique, et de présenter les apports et les cas d’usage supplémentaire qu’il peut couvrir.

C’est quoi CIBA ?

CIBA signifie Client Initiated Backchannel Authentication. Il s’agit d’un nouveau flux d’authentification et d’autorisation du standard OpenID Connect définit par la fondation Open ID.

Le flux CIBA est le premier flux d’OpenID qualifié de « découplé » car il introduit la notion de Consumption Device (CD) et d’Authentication Device (AD). Le CD est l’appareil sur lequel l’accès à un service (Relying Party, RP) est demandé tandis que l’AD est l’appareil sur lequel l’utilisateur s’authentifie auprès de l’OpenID Provider (OP) et autorise l’accès qui est demandé sur le CD, en donnant son consentement.

Contrairement aux autres flux du standard OIDC, CIBA considère donc que l’utilisateur peut s’authentifier sur un appareil différent de celui sur lequel il veut accéder au service. Par exemple, un utilisateur cherche à accéder à son compte en banque depuis son ordinateur et s’authentifie pour autoriser l’accès depuis son smartphone.

Quels apports ?

Le flux CIBA présente plusieurs intérêts significatifs pour l’authentification des utilisateurs.

Les flux d’authentification OIDC aujourd’hui sont conçus autour de la notion de redirections web entre le service accédé (Relying Party) et le fournisseur d’identité. Ces redirections peuvent se montrer inconfortables et perturbantes pour l’utilisateur qui voit son navigateur ou son application passer d’un site à un autre sans forcément comprendre ce comportement. Avec CIBA, l’appareil que l’utilisateur utilise pour accéder à un service reste sur la page du service demandé en attendant que l’authentification soit réalisée sur l’AD. Cette disparition des redirections améliore également l’acceptation des Relying Party qui ne perdent plus le contrôle et la visibilité des actions de l’utilisateur lorsque ce-dernier doit s’authentifier auprès de l’OP.

Bénéfice par population

L’authentification multi-facteur (MFA) est de plus en plus répandue et recommandée pour accéder à des services sur Internet. Les SMS, les soft-token ou encore les Out-Of-Band push notification sont divers exemples de facteurs d’authentification additionnels, utilisés aujourd’hui en complément d’un mot de passe. Avec CIBA, la présence de ce facteur fait naturellement partie de l’authentification puisque celle-ci s’effectue sur un appareil enregistré comme AD. En demandant à l’utilisateur de s’authentifier sur l’AD avec un mot de passe, un code PIN, un facteur biométrique, … on permet de centraliser les actions d’authentification sur un seul et même appareil tout en permettant de faire du MFA.

Exemples de cas d’usage

Le call center

Lorsqu’un client appelle aujourd’hui un centre d’aide ou de services, l’opérateur vérifie le plus souvent l’identité du client avec diverses questions personnelles (date et lieu de naissance, numéro de sécurité sociale) ou bien à l’aide des questions de sécurité. Cette méthode d’authentification est particulièrement vulnérable à des attaques telles que l’ingénierie sociale.

Grâce à CIBA, il est possible pour l’opérateur de déclencher une demande d’authentification de l’appelant sur son Authentication Device et ainsi s’assurer de façon plus sécurisée de l’identité du client.

Les assistants virtuels

La DSP2 impose aux organismes bancaires de s’assurer de l’identité de la personne effectuant une opération au-dessus de certain montant, ce qui passe obligatoirement par une phase d’authentification (2 facteurs) lors d’un transfert par exemple. Néanmoins, les IoT tels que les assistants vocaux ne disposent pas d’interface permettant à l’utilisateur de saisir leurs identifiants, et forcer le client à valider une demande de transfert sur un portail web via son smartphone ou son pc n’est pas l’expérience utilisateur idéale. CIBA permet de s’affranchir de cette contrainte, car la banque du client est alors en capacité d’envoyer une demande d’authentification directement sur le bon terminal (AD), limitant l’impression de rupture de parcours pour le client.

Conclusion

La cinématique d’authentification CIBA comble de vraies faiblesses du protocole OpenID Connect, tant au niveau de la couverture fonctionnelle que de l’expérience utilisateur. Sa mise en œuvre dans le monde réel devrait se faire rapidement, et de nombreux acteurs du marché regardent déjà comment l’implémenter.

Cet article FAPI-CIBA : Comment authentifier mon utilisateur sans interface ! est apparu en premier sur RiskInsight.

Ces dernières années, les entreprises ont fait face à un élargissement du champ d’action de l’Identity and Access Management. Cette discipline n’est plus uniquement centrée sur les problématiques de provisioning utilisateur et d’authentification ; elle s’est tournée non seulement vers des problématiques de revue et de certification des comptes mais aussi vers l’utilisation des mécanismes de fédération d’identités (eg. SAML). Ces changements concernent aussi bien les applications SaaS que les applications restées en interne. Ces évolutions ont chacune permis une ouverture du SI toujours plus large, et nécessitent par conséquent d’être correctement implémentées pour limiter les failles de sécurité.

Cette évolution de l’IAM se fait en parallèle de la généralisation des services Cloud, qui ne cessent de donner naissance à de nouveaux usages pour plus de flexibilité et de souplesse dans l’accès et l’utilisation du SI. Les utilisateurs internes accédant au SI le font de plus en plus majoritairement depuis l’extérieur du réseau de l’entreprise, et ce depuis des terminaux de plus en plus variés.

En outre, les nouvelles technologies agiles et DevOps poussent le SI à évoluer différemment, intégrant beaucoup plus rapidement de nouvelles technologies (IoT, etc.) et de nouveaux usages.

Toutes ces évolutions font aujourd’hui du SI une bulle parmi d’autres interagissant avec son environnement et devant maîtriser, à distance, des interactions entre des composants décentralisés.

… rendant les APIs incontournables

Ce nouveau modèle décentralisé du SI donne naissance à la problématique d’interconnexion des services et des applications : comment assurer l’accès aux données à chaque instant et en chaque endroit ?

Aujourd’hui les APIs (Application Programmable Interface) représentent déjà un mécanisme de communication prépondérant et incontournable pour toute entreprise lancée dans sa transformation numérique. Elles sont utilisées dans  les traitements réalisés non seulement sur des données publiques (adresses d’agences, horaires des transports, etc.) mais aussi sur des données personnelles (tracking fitness, application Ameli et CAF, etc.) et des données sensibles (DSP2, achat en ligne, informations industrielles en mobilité, etc.).

Quelle recette pour sécuriser ses API ?

La sécurisation des API passe par une recette à base de 4 ingrédients à doser finement.

Une base de security as usual

Selon un benchmark Wavestone sur le sujet de la sécurité des applications web, sur 128 applications auditées, des failles graves sont observées dans 60% des cas et la situation est très similaire pour les APIs. À cet effet, les recommandations habituelles de la sécurité web, par exemple celles d’OWASP doivent être prises en compte de la même manière.

Il s’agit essentiellement de s’assurer de couvrir les principales zones à risques d’une application web et de déterminer les mesures de sécurité appropriées.

Une pincée d’OAuth

OAuth est un framework de délégation d’autorisation qui permet à une application d’obtenir l’autorisation d’accès à une ressource au nom d’un utilisateur.

OAuth se propose de couvrir un large éventail de cas d’usages (applications web, mobile, accès ou non à un navigateur, accès serveur-à-serveur, etc.) et offre à cet effet 4 cinématiques principales pour obtenir un jeton. Combiné à une spécification détaillant l’utilisation de ce jeton, un document détaillant le threat model, et enfin une surcouche dédiée à l’authentification (OpenID Connect), il s’agit d’un corpus documentaire équivalent à 250 pages, laissant une place certaine à un grand nombre d’options et de choix d’implémentation.

Et c’est bien cette abondance d’options et ce manque de contraintes qui entraînent les failles de sécurité observées régulièrement dans la mise en place d’OAuth2.0 : usurpation d’identité d’une application, accès aux données personnelles d’un utilisateur tiers, vol de cookie Facebook/Google lors d’un social login ou encore compromission de compte utilisateur.

Les six recommandations suivantes sont essentielles pour une mise en place sécurisée du Framework :

• Secret local : L’application est munie d’identifiants lui permettant de s’authentifier auprès du serveur OAuth : ne pas mettre ce secret (identifiant du service) dans l’application mobile ou le considérer compromis
• Redirect URI: Valider strictement les URLs de redirection vers l’application, sans wildcard
• Implicit: Éviter le « Implicit grant » dans la mesure du possible (et se tourner vers le proxy pattern)
• Authorization code: Valider strictement les authorization codes et clients associés
• State and PKCE: À utiliser pour garantir l’intégrité d’une cinématique complète
• Authorization ≠ Authentication: Utiliser OpenID Connect pour authentifier, OAuth pour déléguer l’accès

Limitez les additifs

À peine cette première pincée d’OAuth digérée, il faut déjà réfléchir à des solutions de sécurité permettant de répondre aux besoins que nous rencontrons le plus fréquemment.

Le Single Sign-On mobile, ou comment permettre à des employés en mobilité ou des clients d’accéder aisément aux applications sans se réauthentifier ?

Qu’il s’agisse d’un agent terrain en contact clientèle ou en tournée d’intervention qui peut utiliser plus d’une dizaine d’applications par jour ou qu’il s’agisse d’un client ayant installé plusieurs applications sur le store public, le besoin d’accéder à l’ensemble des applications sans avoir à se réauthentifier sur chacune est aujourd’hui très présent. Si, depuis 2008, les techniques le permettant ont varié au gré des possibilités offertes par les OS mobiles (KeyChain iOS, paramètres d’URL, Mobile Device Management…), Apple et Google ont convergé vers une solution commune en 2015 : utiliser le navigateur système comme point d’ancrage d’une session SSO. C’est maintenant une bonne pratique officielle matérialisée par la BCP « OAuth2 for native applications »

L’authentification contextuelle, ou comment adapter le niveau d’accès à une donnée en fonction de la criticité de celle-ci ?

Un des nombreux enjeux concernant l’authentification est de simplifier au maximum l’accès des utilisateurs à leurs données tout en garantissant un niveau de sécurité satisfaisant. L’authentification contextuelle permet de répondre à cet enjeu, en adaptant le niveau d’accès à la nature de la transaction, à ses caractéristiques, aux habitudes utilisateurs, à son contexte…. On parle de LOA (Level of Assurance). Dans le cadre d’une application mobile bancaire, cela permet à l’utilisateur de consulter son compte en banque, de bénéficier de la météo de ses comptes sans avoir à se réauthentifier à chaque accès. L’application requerra toutefois une authentification au moment de réaliser une opération sensible (un virement interne par exemple), et une authentification forte au moment de réaliser une opération très sensible (ajout d’un bénéficiaire par exemple).

Les solutions du marché proposent aujourd’hui des solutions pensées selon une logique où le client applicatif est responsable d’initier la demande de LOA correspondant à la donnée ou au service auquel il souhaite accéder. Mais le vrai besoin consiste à définir et appliquer ces politiques d’accès aux données de manière centralisée, au sein du serveur d’autorisation. Il s’agit notamment d’un besoin essentiel lorsque l’on veut appliquer une authentification liée au niveau de risque du contexte (géolocalisation, terminal connu ou non, habitudes de transactions, etc.)

Propagation de l’identité, ou comment transmettre un jeton d’accès entre deux applications (ou plus) ?

Il est courant qu’un appel vers une API déclenche une cascade d’appels vers d’autres API, notamment dans le cadre d’une architecture de type micro-service. La transmission de l’identité de l’utilisateur doit alors être assurée sans créer de risque de sécurité. Et les trois premières solutions qui viennent à l’esprit présentent des limites :

• La transmission du token initial est évidement à proscrire, à la vue du risque de fraude interne très élevé que cela entrainerait.
• L’authentification de l’appelant seule n’est pas suffisante non plus, car un composant compromis dans la chaîne peut usurper l’identité de n’importe quel utilisateur et compromet le reste de la chaîne.
• La génération d’un token pour l’appelant transmis avec le token de l’utilisateur initial ne permet pas d’assurer l’intégrité de la combinaison utilisateur/API et ne permet pas de vérifier la chaine.

Une ébauche avancée de solution existe aujourd’hui, proposant un nouveau grant type : Token Exchange. Ce mécanisme permet à l’appelant de demander un jeton intermédiaire, composé notamment de l’identité de l’utilisateur, de l’identité de l’appelant et de la chaine d’appel déjà effectuée. Cette nouvelle cinématique permet de centraliser la politique d’appel entre micro-service et l’application de cette politique, et d’assurer la traçabilité des appels.

Protection contre le vol de jeton, ou comment se prémunir du vol d’un ou d’une base de jetons ?

Par principe, le jeton contient de nombreuses informations sur son porteur, ce qui entraîne un risque important en cas de vol. Plus impactant encore, dans certains contextes (e.g. DSP2), un tiers (agrégateur) peut se retrouver en possession de très nombreux jetons, et le propriétaire de l’API se retrouve à la merci de ce tiers et de son niveau de sécurité. La détection du vol étant très difficile, il a fallu trouver d’autres solutions comme le Token Binding, un mécanisme de négociation à deux ou trois composants, permettant de lier un jeton à une paire de clés cryptographiques, et dans lequel le client doit prouver qu’il possède la clé privée constituant une partie de cette paire en établissant une connexion TLS mutuelle avec l’API.

Écrire la recette

Dernier ingrédient de la recette, il convient de décliner une architecture de référence de OAuth pour l’adapter au contexte du SI de l’entreprise. Pour cela, il faut définir le cadre d’utilisation des API en :

• Définissant et partageant les règles de sécurité : Les cinématiques autorisées et le cadre d’application, les checklists sécurité et l’architecture de référence doivent être formalisées.
• Formant et outillant les développeurs: Des sessions de formation et de présentations des principes adoptés doivent être organisées. Les équipes projets peuvent être rendues autonomes dans leur intégration au reste du SI.
• Intégrant les ressources sécurité dans les sprints agiles: Les ressources agissant en tant que coach sécurité doivent être identifiées pour accompagner la conception applicative et apporter des solutions prêtes à l’emploi et être un accélérateur

En synthèse

Au final, comme la recette du bon miel, sécuriser des APIs nécessite une succession d’ingrédients allant du plus basique jusqu’au plus élaboré tout en tenant compte du besoin et du contexte.

Cet article La sécurité des APIs ou la recette du bon miel est apparu en premier sur RiskInsight.

Il est aujourd’hui indispensable pour les entreprises de connaitre au mieux leurs clients afin de leur proposer des services toujours plus personnalisés et ainsi augmenter leurs taux de transformation.

En quoi l’arrivée de systèmes centralisés de gestion des identités clients (Customer Identity and Access Management ou CIAM) peut être une première réponse à cette problématique.

Vers une gestion unifiée des données clients

Une organisation historiquement en silos

De par la spécificité des métiers de l’entreprise, de nombreuses solutions de gestion de la relation client ont émergé ces dernières années : CRM, email et vidéo marketing, e-commerce, mobile et web analytics…

Cette multiplicité des technologies a entraîné un silotage des données des clients ; en d’autres termes, il est aujourd’hui difficile pour une entreprise de disposer d’une vue unique de ses clients. En effet, une entreprise européenne posséderait en moyenne 4,5 solutions marketing^[1], soit autant de vues de chaque client.

Avoir une vision unifiée des clients est une première étape indispensable pour les entreprises afin d’être en mesure de leur proposer des offres pertinentes.

Par ailleurs, le taux de transformation depuis les canaux numériques reste faible du fait d’un ciblage incomplet, d’offres en décalage avec les intérêts du client et d’un manque de confiance envers la marque.

Afin d’allier la transformation numérique et business, positionner l’identité du client au centre de l’organisation est une manière de traiter ces points défaillants.

Le client au centre de l’organisation

Aujourd’hui, le nombre important de solutions marketing tend à multiplier les sources de données : points de vente, canaux numériques (sites web, mobiles), service après-vente…

Le client se retrouve alors dans un modèle en « toile d’araignée » : plusieurs sources, plusieurs systèmes, plusieurs bases de données et donc plusieurs identités.

Afin d’améliorer la connaissance de leurs clients, les entreprises doivent adopter un modèle plus unifié, combinant facilité d’accès et partage des données clients : le modèle « centralisé ».

Ce modèle vise à mettre une interface unique (CIAM) entre les sources de données et les solutions marketing qui aura pour objectifs de centraliser les données clients, améliorer leur qualité et créer de la valeur business en les agrégeant dans une même identité.

Une solution CIAM couvre 3 briques technologiques :

• Enregistrement et accès: fournit des services d’enregistrement et de connexion, indépendamment du moyen d’accès (site web, mobile…) : API/SDK, fédération d’identité, social login…
• Stockage et traitement: fournit des services de stockage et de traitement des données : profiling, mise en qualité, agrégation…
• Intégration: fournit des connecteurs permettant au CIAM d’échanger des données avec les différentes solutions marketing de l’entreprise.

Un tel modèle permettra à l’entreprise de mieux connaitre ses clients et les fidéliser (Know Your Customers, ou KYC).

Mieux connaitre ses clients grâce au CIAM

Globalement, l’ensemble des services offerts par le CIAM répond à des besoins business importants : mieux connaitre les clients, simplifier leur parcours et créer une relation de confiance.

Un CIAM pour… mieux connaitre les clients

Un client satisfait est un client fidèle, mais pour le satisfaire, encore faut-il le connaitre et anticiper ses attentes. Pour cela, le CIAM vise à contribuer à l’amélioration de la connaissance des clients que nous découpons en 4 grandes étapes :

Étape 1 : client anonyme

L’entreprise ne connait pas le client mais uniquement un utilisateur qui accède à ses services. Elle ne peut donc récupérer des informations restreintes (cookie).

L’objectif est alors de proposer un moyen simple d’identifier l’utilisateur (ex : inscription à une newsletter).

Étape 2 : client identifié

Le client crée un compte utilisateur par le biais d’un compte d’un réseau social ou en remplissant un formulaire. À cette étape, l’entreprise présente les conditions d’utilisation de ses données pour consentement, récupère des informations de contact (nom, prénom, date de naissance, e-mail, téléphone) et rattache les informations récupérées en étape 1 à l’identité du client.

L’objectif est alors de le faire revenir via une newsletter ou l’envoi d’offres en lien avec son historique de navigation pour établir son profil.

Étape 3 : client connu

Au fur et à mesure des échanges avec le client, le CIAM va récupérer ses préférences (via les produits consultés, l’affichage d’un bouton « J’aime » à l’instar des réseaux sociaux qui permet au client d’indiquer simplement son intérêt pour le produit, etc.). Le profil du client commence à se dessiner et des actions de marketing plus ciblées peuvent commencer.

L’objectif est maintenant de connaitre au mieux le client et faire vivre ses données.

Étape 4 : client fidélisé

La mise à jour des préférences du client va permettre de cibler davantage les actions marketing et de le fidéliser en proposant des offres personnalisées et attractives.

Cette étape se réalise sur le long-terme, dans une approche de construction dynamique du profil du client.

Un CIAM pour… simplifier le parcours client

Un des principaux intérêts du CIAM est de simplifier le parcours client, élément fondamental à la transformation numérique.

À l’enregistrement : faire simple, faire vite !

La première raison de perte de clients potentiels est un processus d’enregistrement compliqué (trop d’informations demandées, CAPTCHA à saisir…).

Afin de simplifier ce processus, les solutions de CIAM proposent des fonctionnalités d’enregistrement en 3 clics basés sur les comptes des réseaux sociaux (ex : Facebook, Twitter, LinkedIn, Google…).

Les réseaux sociaux seront privilégiés comme source d’information du client.

À l’usage : éviter l’effet RELOU !

S’il y a une chose à ne pas retenir dans la mise en place d’un CIAM, c’est d’imposer un nouveau mot de passe au client.

Les solutions CIAM facilitent l’accès aux services en proposant des méthodes de connexion également basées sur les réseaux sociaux. Mais attention, les clients ne doivent pas avoir à se rappeler du réseau social qu’ils ont utilisé lors de l’enregistrement.

C’est à ce moment-là que les solutions CIAM permettent de rendre le plus transparent possible l’accès des clients en apportant la capacité de rattacher tous comptes de réseaux sociaux d’un client à son identité (ex : si le client s’enregistre avec Facebook, il devra pouvoir se connecter plus tard avec Twitter).

Se connecter en 1 clic pour éviter l’effet RELOU (« Réellement, Encore un Login à OUblier ! »), voilà de quoi retenir vos clients.

Un CIAM pour… créer une relation de confiance

La fidélisation d’un client passe par l’instauration d’une relation de confiance avec ce dernier en respectant le bon usage de ses données.

Aujourd’hui, le cadre légal est en pleine évolution, particulièrement en Europe avec l’arrivée de la GDPR (General Data Protection Reglementation).

L’un des points important de la GDPR est l’obligation faite d’obtenir le consentement de l’utilisateur pour tout usage de ses données.

En conséquence, le client doit à tout moment pouvoir :

• Être tenu informé des termes d’utilisation de ses données
• Accéder à ses données et pouvoir les rectifier
• Restreindre l’accès d’un service à tout ou partie de ses donnée
• Être oublié

Le respect de ces réglementations est donc primordial pour augmenter la confiance des clients qui, in fine, sont devenus la source de données principale des solutions CIAM. Cette confiance permet à l’entreprise de recueillir le maximum d’informations sur le client et d’ainsi augmenter ses taux de transformation.

CIAM et IAM traditionnel : est-ce différent ?

Bien que les solutions IAM traditionnelles et CIAM proposent des briques fonctionnelles proches (gestion des identités, authentification, publication de données…), elles présentent néanmoins des différences technologiques et d’usages significatives :

En conséquence, l’extension d’un IAM traditionnel pour gérer les identités des clients n’est évidemment pas judicieuse et induirait immanquablement un projet coûteux, la mise en place d’un système hybride non agile et ne garantirait pas l’atteinte des besoins couverts nativement par un CIAM.

En synthèse

Fidéliser un client nécessite de le connaitre. Les solutions de CIAM apportent des moyens technologiques pour centraliser et unifier la vision d’un client au sein d’une organisation, tout en respectant les évolutions des réglementations actuelles et en simplifiant le parcours client.

Malgré leurs bases communes à l’IAM traditionnel, les solutions CIAM restent des outils à enjeux marketing. Leur mise en place nécessite de sortir du cercle IT pour inclure les métiers (marketing, communication, services supports) ainsi que le juridique.

[1] PAC, No more Silos – Towards a Holistic Customer Experience Strategy, 2016

Cet article Customer IAM : l’IAM, pilier de la transformation business ? est apparu en premier sur RiskInsight.