Back4App + Incognia – Protection des connexions aux applications

Les données de localisation sont puissantes et il est étonnant de voir le nombre d’applications différentes qu’elles peuvent avoir : médias, engagement, études de marché, mobilité urbaine, etc. Mais avez-vous déjà réfléchi à la façon dont la technologie de localisation précise peut permettre de nouvelles stratégies dynamiques pour rendre les applications plus sûres tout en éliminant les frictions du processus d’authentification ? C’est à partir des réponses à cette question qu’Incognia a été créé.

Incognia a créé une plateforme d’identité basée sur la localisation pour protéger les utilisateurs d’applications et, en même temps, réduire les frictions, en supprimant le besoin de mots de passe et autres authentifications. Jusqu’à présent, Incognia a été déployé sur plus de 100 millions de dispositifs et permet une authentification sans friction dans plus de 90 % des cas.

Chaque personne a un modèle unique de comportement de localisation, comme une empreinte digitale de localisation, qu’Incognia utilise comme une identité privée pour protéger les comptes des utilisateurs sur les applications mobiles. Sur la base du comportement de localisation unique de l’utilisateur, certains endroits sont très fréquentés par cet utilisateur et cet appareil.

Les lieux les plus fréquents sont classés comme les lieux de confiance de l’utilisateur, qui font partie de sa routine, comme l’adresse de son domicile et celle de son travail. Grâce à ces informations, Incognia peut identifier les scénarios d’authentification à faible risque. Lorsqu’Incognia détecte qu’un utilisateur se trouve dans un lieu de confiance, la probabilité que la transaction soit légitime est plus élevée et le risque de fraude plus faible, ce qui permet d’exiger moins de frictions.

Grâce à cette solution, vous pouvez procéder à une authentification sans mot de passe pour toute transaction ou connexion pertinente en faisant correspondre l’emplacement historique des utilisateurs avec celui de l’appareil actuellement utilisé, sans avoir à recourir à des étapes à forte friction comme la reconnaissance faciale ou les OTP.

Protéger les connexions aux applications

Dans ce mode d’emploi, vous apprendrez à intégrer l’API de transaction Incognia pour améliorer la reconnaissance des utilisateurs de confiance lors de la connexion sans ajouter de friction à l’expérience utilisateur. Vous serez en mesure d’approuver automatiquement les tentatives de connexion de confiance, de déclencher une authentification renforcée et de bloquer les connexions suspectes.

Conditions requises

• Un compte Incognia. Inscrivez-vous  ici si vous n’avez pas de compte.
• Une application avec le SDK d’Incognia initialisée. Suivez le SDK getting started pour cela.
• Les informations ​API credentials pour pouvoir faire des demandes aux API d’Incognia.

Etape par étape

• Définition de l’ID utilisateur sur l’application

Afin de vérifier une tentative de connexion, Incognia doit associer un appareil et un identifiant de compte unique. L’identifiant du compte est utilisé à cette fin.

Cette association doit se faire en deux temps :

1. Chaque fois que l’application s’initialise

Ceci couvre le scénario où l’application est mise à jour avec le SDK d’Incognia et l’utilisateur est déjà connecté. L’application.onCreate() sur Android et l’application [AppDelegate application:didFinishLaunchingWithOptions :] sur iOS sont de bons endroits pour le faire.

Si l’identifiant du compte n’est pas disponible dans ces endroits, il est important de transmettre la valeur au SDK d’Incognia dès qu’elle est disponible. L’action importante ici est d’appeler setUserId à chaque fois que l’application s’initialise, afin de garantir que nous savons toujours qu’un utilisateur spécifique est associé à un appareil spécifique.

2. Chaque fois que l’utilisateur se connecte et se déconnecte

Il est nécessaire d’appeler la méthode setUserId lorsque l’utilisateur termine sa connexion et clearUserId lorsque l’utilisateur se déconnecte. Cela se fait généralement dans le callback de ces deux actions.

ALERTE : Si des données telles que l’adresse électronique et le numéro de téléphone sont des exemples d’identifiants, leur utilisation dans le SDK est interdite. Envisagez d’utiliser des informations non personnelles, telles que les UUID et le hachage, pour générer et définir l’ID utilisateur de manière sécurisée.

• Transfert de l’identifiant d’installation de l’appareil à votre serveur

Le SDK d’Incognia collecte des données de localisation et d’appareil pour établir un profil comportemental pour les utilisateurs mobiles. Ces données sont marquées d’un identifiant appelé Installation ID, qui est automatiquement généré par le SDK.

Pour vérifier une tentative de connexion, Incognia doit recevoir un d’installation ID pour identifier l’appareil d’où provient la connexion. Comme votre serveur demandera à l’API d’Incognia d’évaluer le risque de cette connexion, il doit recevoir cette information de votre application mobile.

L’installation ID peut être transmis à votre serveur de deux manières.

• Option 1 : Envoi de l’ID de l’installation en tant qu’en-tête

Avant d’envoyer une demande de connexion de votre application mobile à votre serveur, appelez Incognia.getInstallationId et définissez sa valeur comme en-tête de la demande. Nous vous encourageons à choisir un nom clair pour cet en-tête, comme Incognia-Installation-ID, afin de pouvoir l’identifier facilement du côté du serveur.

Cette option présente un avantage certain si votre application utilise plus d’une solution Incognia, car vous n’aurez pas besoin de modifier les propriétés de chaque demande, comme l’inscription, la connexion, le paiement, le changement de mot de passe, etc.

Kotlin

Java

Swift

Objective-C

• Option 2 : Envoi de l’ID d’installation dans le corps de la demande

Avant d’envoyer la demande de connexion de votre application mobile à votre serveur, appelez Incognia.getInstallationId et envoyez-le comme information supplémentaire sur cette connexion. Nous vous suggérons de choisir un nom clair pour cette propriété, comme Incognia-Installation-ID, afin de pouvoir l’identifier facilement du côté du serveur.

Traitement de la demande de connexion de l’utilisateur

Lorsque votre serveur reçoit une demande de connexion, vous pouvez utiliser l’intelligence d’Incognia pour évaluer le risque de cette tentative de connexion dans ce cycle demande/réponse.

Pour évaluer ce risque de tentative de connexion, votre serveur demandera l’API de transaction informant qu’une tentative de connexion a été effectuée ainsi que son  Installation ID et l’Identifiant du compte auquel l’appareil tente d’accéder.

Exemple de mise en œuvre d’un contrôleur/manipulateur

Considérons un exemple de jouet comme backend avec le contrôleur ci-dessous:

Il vous est demandé de vous authentifier lorsque vous utilisez l’API d’Incognia. Pour les détails de l’authentification, voir Authentification dans les API d’Incognia.

Utilisation de l’évaluation des risques d’Incognia

Lorsque votre serveur envoie une demande au  Transaction API endpoint, il reçoit une réponse comme la suivante:

La réponse contient l’identifiant de l’entité créée (dans ce cas, un login), l’évaluation du risque fournie par Incognia sur la base du comportement de l’appareil, et les preuves qui soutiennent cette évaluation. Vous pouvez en savoir plus sur toutes les données renvoyées dans cet article : Comprendre l’évaluation des risques.

L’évaluation renvoyée peut être utilisée avec d’autres données relatives au risque, par exemple dans un moteur de risque, pour décider si ce login doit être accepté. Les évaluations de risques d’Incognia comprennent :

• risque_élevé : la connexion effectuée par le dispositif peut être frauduleuse et nous vous conseillons de prendre des mesures préventives dans ces scénarios, comme exiger une authentification complémentaire ou simplement bloquer cette tentative de connexion;

• faible_risque : la connexion effectuée par le dispositif semble pouvoir être acceptée sans risque;

• risque_inconnu : nous ne sommes pas en mesure de fournir une évaluation précise au moment de la demande. Vous devez exiger une authentification supplémentaire (par exemple, 2FA).

Conclusion

Après ces étapes, votre application est prête à reconnaître les utilisateurs de confiance lors de la connexion, sans friction et en empêchant les prises de contrôle de comptes.