Conception d'un système de gestion de One Time Password sur le Cloud

Un One Time Password (OTP) est un mot de passe aléatoire et temporaire, valable pour une seule connexion, utilisé pour vérifier l'identité d'un utilisateur. L'utilisateur reçoit ce mot de passe temporaire via email ou SMS et le saisit pour s'identifier.
Les exigences du système
Dans cet article, on va concevoir un service de gestion d'OTP qui peut être utilisé par les applications tierces pour renforcer l'authentification de leurs utilisateurs. Ce service aura les exigences suivantes:
Exigences fonctionnelles
- Le service génère des mots de passe temporaires et aléatoires à 6 chiffres.
- Le service envoie les mots de passe temporaire aux l'usagers via email ou SMS.
- Le service valide les mots de passe des usagers.
Exigences non fonctionnelles
- Le service doit être toujours disponible.
- Le service doit être capable de traiter 50 millions de transactions par jour
- Le service doit traiter chaque transaction en moins de 100 millisecondes.
- Toute authentification avec un mot de passe temporaire âgé de plus de 5 minutes doit être rejetée.
Conception à haut niveau
L'objectif de la conception à haut niveau est de:
- Identifier les différents composants du système.
- Concevoir les API des différentes fonctionnalités du système.
- Concevoir le schéma des données qu'on utilisera pour stocker les informations.
Les composants du système

Les composants du système sont les suivant:
- Le client: L'application où se fait l'identification de l'usager
- L'équilibreur de charge (Load Balancer) qui distribue le traffic aux serveurs d'APIs
- Les serveurs d'APIs qui vont exposer les fonctionnalités pour créer et valider les mots de passe temporaires. On prévoit que chaque serveur pourra traiter entre 50 à 100 transactions/seconde, donc on aura 6 à 12 serveurs pour gérer le trafic de 50M transactions/jour, soit 600 transactions/seconde.
- La base de données pour stocker les mot de passe.
- Le serveur de Mail pour envoyer les mots de passe par email.
- Le serveur SMS pour envoyer les mots de passe via SMS.
La conception de l'API
Les fonctionnalités que le système va offrir via son API sont les suivantes:
- Générer les mots de passe temporaire
- Vérifier les mot de passes temporaire
Génération de mot de passe
POST /otp
Requête
- type: La méthode d'authentification. Les valeurs possibles sont
SMS
ouEMAIL
. - address: L'adresse de l'usager à vérifier. La valeur de ce champ est soit le numéro de téléphone ou l'adresse email de l'usager à identifier.
Réponse
- opt-uuid: Identificateur unique du mot de passe temporaire de type UUID.
Vérification du mot de passe
POST /opt/{opt-uuid}/validate
URL
- opt-uuid: Identificateur du mot de passe.
Requête
- password: Valeur numérique du mot de passe temporaire à 6 chiffres.
Réponse
- success:
true
si la vérification a réussi,false
sinon. - error_code: Code d'erreur si
success=false
. Les valeurs possibles de ce champ sontEXPIRED
,INVALID
.
La conception du schéma de données
Les mots de passes générés vont être stockés dans la table de mot de passe ayant la structure suivante:
- opt_uuid: L'identifiant du mot de passe. C'est la clé primaire de la table
- password: La valeur du mot de passe temporaire à 6 chiffres.
- expires: La date d'expiration du mot de passe.
Estimons maintenant les besoins de stockage
- opt_uuid: une chaîne de caractères encodée sur 128 bits, soit 16 octets
- password: un nombre à 6 chiffres, donc peut être stocké dans un
INTEGER
, soit 4 octets. - expires une date en millisecondes, donc peut être stocké dans un
LONG
, soit 8 octets.
Donc les besoins de stockage sont:
- 16 octets + 4 octets + 8 octets = 28 octets par mot de passe temporaire.
- 50 millions de transactions par jour x 28 octets = 1.4 Go par jour = 511 Go par an
A haut niveau, le système ressemblera au diagramme suivant:

Generator
qui va générer les mot de passe temporaires et les envoyer aux utilisateurs via email ou SMS.Verifier
qui va vérifier les mots de passe saisis par les utilisateurs.
Conception détaillée
Maintenant qu'on a une bonne idée de ce à quoi le système ressemblera, on va plonger dans les détails.
Choix de la base de données
Le choix simple serait de choisir une base de données relationnelle (Ex: MySQL) pour stocker les mots de passe. Cette base de donnée va croître au rythme de 511 Go par an.
Cependant, on peut considérer qu'on a pas besoin de stocker les mots de passes expirés, donc on aurait besoin uniquement d'une capacité de stockage pour 5 minutes, la durée de vie des mots de passe, soit ( 511 Go par an / 365 jours / 1440 minutes par jour ) * 5 minutes = 4.8 Mo au 5 minutes.
5 Mo de données peut être facilement stocker en mémoire! Pour cela on choisira plutôt de stocker les mots de passe dans une cache mémoire (Ex: Redis ou Memcached), qui offre un accès rapide aux données (car les accès se font en mémoire) et purge automatiquement les données expirées, ce qui va maintenir la quantité de données constante.

Génération des mots de passe
Le processus génération des mots de passe se fait en 2 étapes:
- La génération du mot de passe à 6 chiffres et le stockage en cache
- L'expédition du mot de passe via email ou SMS en utilisant des APIs externes.
On va expédier les mots de passe de façon asynchrone, ce qui va rendre l'opération de génération des mots de passe plus rapide car elle ne sera pas impactée par la latence d'expédition via email ou SMS.

Donc le processus va être divisé en 3 étapes:
- La génération du mot de passe à 6 chiffres et stockage dans la cache.
- Le stockage d'un évènement dans un Message Queue contenant l'adresse, le mot de passe et le type d'expédition.
- La réception asynchrone de l'événement par le
Sender
qui va expédier le mot de passe via SMS ou email.
Vérification des mots de passe

Pour vérifier les mot de passe,
- Le client fournit
otp_uuid
retourné lors de la création du mot de passe, et le mot de passe reçu via email ou SMS - Le système va récupérer le mot de passe généré de la cache.
- Le système va comparer les mots de passe et retourne la réponse appropriée.
L'architecture finale du système ressemblera à ceci:

Implémentation
Nous avons une architecture qui est indépendante du langage de programmation et de la plateforme de cloud. Il faut maintenant choisir la plateforme cloud et les services pour les différents composants de l'architecture.
Implementation AWS
AWS est la plateforme cloud d'Amazon, qui offre plus de 200 services.

Les services AWS à utiliser sont:
- Elastic Load Balancer (ELB) comme équilibreur de charge.
- EC2 pour les serveurs d'APIs.
- Simple Queue Service (SQS) comme Message Queue.
- AWS Lambda pour faire les envois des mots de passe de façon asynchrone.
- ElastiCache comme base de données.
- Simple Email Service (SES) pour l'expédition des emails.
- Simple Notification Service (SNS) pour l'expédition des SMS.
Implementation Google Cloud Platform
Google Cloud Platform (GCP) est la plateforme cloud de Google

Les services GCP à utiliser sont:
- Cloud Load Balancing comme équilibreur de charge.
- AppEngine pour les serveurs d'APIs.
- Pub/Sub comme Message Queue.
- Cloud Function pour faire les envois des mots de passe de façon asynchrone.
- Memorystore comme base de données.
Malheureusement, GCP n'offre pas de service de email ou SMS, donc il faudrait utiliser des services externes:
- SendGrid pour l'expédition des emails.
- MTN SMS API pour l'expédition des SMS.
A ce point, tout est prêt pour l'équipe de programmeurs qui peut commencer à coder!