J'ai du mal à choisir une stratégie d'authentification décente / sécurisée pour une architecture de microservices. Le seul article SO que j'ai trouvé sur le sujet est celui-ci: Single Sign-On dans Microservice Architecture
Mon idée ici est d'avoir dans chaque service (ex. Authentification, messagerie, notification, profil etc.) une référence unique à chaque utilisateur (assez logiquement alors le sien user_id) et la possibilité d'obtenir l'utilisateur actuel ids'il est connecté.
D'après mes recherches, je vois qu'il y a deux stratégies possibles:
1. Architecture partagée
Dans cette stratégie, l'application d'authentification est un service parmi d'autres. Mais chaque service doit être capable de faire la conversion session_id=> user_iddonc ça doit être très simple. C'est pourquoi j'ai pensé à Redis, qui stockerait la clé: valeur session_id:user_id.
2. Architecture du pare-feu
Dans cette stratégie, le stockage de session n'a pas vraiment d'importance, car il n'est géré que par l'application d'authentification. Ensuite, le user_idpeut être transmis à d'autres services. J'ai pensé à Rails + Devise (+ Redis ou mem-cached, ou cookie storage, etc.) mais il y a des tonnes de possibilités. La seule chose qui compte, c'est que Service X n'aura jamais besoin d'authentifier l'utilisateur.
Comment ces deux solutions se comparent-elles en termes de:
- Sécurité
- robustesse
- évolutivité
- facilité d'utilisation
Ou peut-être suggéreriez-vous une autre solution que je n'ai pas mentionnée ici?
J'aime mieux la solution n ° 1, mais je n'ai pas trouvé beaucoup d'implémentation par défaut qui me garantirait le fait que je vais dans la bonne direction.
J'espère que ma question ne sera pas close. Je ne sais pas vraiment où le demander.
Merci d'avance
