Guide : Comment gérer de manière sécuritaire l’identification des utilisateurs?

Évidemment, à l'ère de l'infonuagique, une panoplie de solutions sont offertes chez les grands fournisseurs de produits infonuagiques et même via des compagnies qui se spécialisent dans ce domaine. On parle ainsi de services de fournisseurs d'identités sous la forme de Software as a Service (ou SaaS).

Le principe est qu'en quelques clics, ou lignes de scripts, on peut avoir à notre disposition un système complet permettant la gestion et l'identification des utilisateurs pour une application web ou mobile. Ces services offrent également une grande quantité de fonctionnalités avancées et la possibilité de s'interconnecter avec des systèmes d'utilisateurs existants, et ce, gratuitement pour plusieurs dizaines de milliers d'utilisateurs.

Guillaume Dussault, architecte de solutions, survole les différentes fonctionnalités offertes avec ces solutions, quelques comparatifs et les principaux défis rencontrés en intégrant ces services à nos applications.

Sommaire :

1. Comprendre les avantages des services infonuagiques
2. L’offre des services infonuagiques payants
3. Quel fournisseur d’identité choisir?
4. Les défis d'intégration à relever

Historiquement, les applications étaient développées en incorporant directement les fonctionnalités de gestion des utilisateurs et de l'identité. Cela apportait plusieurs désavantages :

• Impossibilité de réutiliser les données et les fonctionnalités de gestion d'utilisateurs pour d'autres systèmes
• Trop de responsabilités pour le système
• Des risques d’impact sur le système d’identification à chaque modification des fonctionnalités cœurs du système, et vice versa.

Mais le plus gros danger concerne la sécurité : en tant que développeur ou architecte, je souhaite ne jamais toucher à de l'information sensible telle que le nom d'utilisateur et le mot de passe de l’utilisateur. Le principe est simple : on ne peut exposer au grand jour des données qu'on ne manipule pas. C'est donc le meilleur moyen de mitiger le risque. Ci-bas, j'illustre un diagramme sommaire de l'identification dans ce contexte.

La stratégie couramment employée par les services infonuagiques est de déléguer la responsabilité de ces fonctionnalités à un système tiers dans le but de ne pas manipuler, transmettre et conserver ces données sensibles. On utilise alors des jetons fournis par le fournisseur d'identité à l’étape d’identification d'utilisateur. De plus, les services gérés de fournisseurs d'identités offrent de base le niveau de conformité nécessaire pour SOC, PCI, HIPAA et d'autres. AWS Cognito et Azure AD B2C sont aujourd’hui les deux grands fournisseurs infonuagiques les plus populaires.

Ils offrent également un grand nombre de fonctionnalités telles que :

• L'utilisation du populaire protocole OAuth2
• La réinitialisation du mot de passe
• L'authentification à facteurs multiples (MFA ou authentification par courriel ou SMS)
• Le support pour l'authentification via un tiers comme Google, Facebook, Twitter et Microsoft
• L'utilisation d'interface utilisateur web personnalisable

Le plus beau dans tout ça : le service chez AWS et Azure est gratuit pour une utilisation de moins de 50 000 utilisateurs actifs par mois!

Le diagramme suivant montre le flot d'authentification sans que l'application connaisse les informations sensibles de l'utilisateur en communiquant plutôt le jeton de l'utilisateur.

Plusieurs compagnies offrent aussi des services de fournisseur d'identité, notamment Okta et Auth0 (appartenant aussi à Okta). Ces derniers sont cependant considérablement plus coûteux. En prenant le moins cher des deux, Auth0, il faudra payer la somme d'environ 0,03 $ par utilisateur. Cela représenterait un montant mensuel 300 $ pour 10 000 utilisateurs.

Les différences principales concernent l'interface utilisateur de la console de configuration, qui est plus conviviale et polie, mais aussi l'API, qui est un peu plus riche et qui présente quelques autres fonctionnalités plus marginales.

Au sein de nos projets, on observe que les fonctionnalités offertes par les services gratuits sont amplement suffisantes pour répondre aux besoins de nos clients.

À haut niveau, on constate que l'offre pour ces services est relativement similaire. En revanche, il est certain qu'il existe des cas d'utilisation où l'intégration du service d'un fournisseur particulier aura plus de sens dans la solution – notamment quand il est question d'interagir avec d'autres services infonuagiques.

Dans le cas d'Azure, si vous utilisez déjà Azure Monitor pour l’observabilité et les alertes de vos applications, il serait totalement logique d'opter pour Azure AD B2C pour agréger les événements et possiblement créer des alertes en cas de menaces ou d’interactions suspectes. Pour l’opérationnalisation des systèmes, c’est bien d’avoir une source limitée de données pour vos systèmes, donc les agréger dans Azure Monitor serait une bonne option.

Dans le même sens, si votre infrastructure est sur AWS, AWS Cognito s'intègre aisément avec les autres services d'AWS. Par exemple, vous pouvez contrôler l'accès à des routes d'API Gateway pour les utilisateurs d'AWS Cognito.

Dans tous les cas, tous ces services utilisent le protocole standard OAuth2 permettant l'intégration de l'un avec l'autre des fournisseurs infonuagiques. Donc, par exemple, il est possible d'utiliser Auth0 pour ses fonctionnalités avancées, mais d'y fédérer également un groupe d'utilisateurs sur AWS Cognito. Cela permet d’avoir le meilleur des deux mondes! Plus les frais d'Auth0, bien sûr!

Le défi qui revient le plus fréquemment dans l'intégration d'un fournisseur d'identité n'est pas un défi technique, mais plutôt un débat entre l'aspect sécuritaire et l'expérience utilisateur. Par exemple, demander trop fréquemment à l'utilisateur de s'identifier auprès de l'application créera un irritant pour l'utilisateur.

L'autre défi est de réussir à présenter l'interface de connexion ou d'authentification à l'utilisateur. La différence entre les deux scénarios qui suivent est particulièrement flagrante dans la réalisation d'une application mobile.

Le premier scénario est de proposer une authentification utilisateur pleinement intégrée dans l'application mobile sans en sortir. Cela veut donc dire que l'application doit manipuler brièvement le nom d'utilisateur et le mot de passe de celui-ci afin de l'envoyer au fournisseur d'identité. Cela pourrait comporter une faille de sécurité. Cependant, on obtient une expérience parfaitement intégrée, la possibilité d'utiliser les fonctionnalités de biométries de l'appareil et l'assurance que les applications de gestion de mots de passe seront supportées. Le deuxième scénario possible est de faire afficher une page web à l’intérieur de l'application mobile afin que l'utilisateur se connecte. Cette page est directement hébergée chez le fournisseur d'identité, donc on ne manipule pas les informations de connexion de l'utilisateur. Toutefois, le flot de l'expérience est moins fluide et pourrait sembler moins intégré pour l'utilisateur. Il est possible de masquer le tout afin de paraître davantage intégré dans l’application. On perd également la possibilité d'utiliser la biométrie de l'appareil. Finalement, le coût de développement pour cette option est moindre.

Il n'y a ainsi pas de réponse claire. Comme bien des dilemmes en développement de solution sur mesure, ça dépendra du contexte du projet, des objectifs et des restrictions qui en découlent.

Pour finir, peu importe la solution que vous choisirez pour la gestion des utilisateurs et de l’identité, l’important reste de garder les fonctionnalités qui en découlent hors des autres systèmes d’affaires et des applications afin de séparer la responsabilité des systèmes. Vous pourrez ainsi réutiliser la solution pour l’intégrer à vos futures applications. De plus, il y a fort à parier que les informations contenues dans le service de fournisseur d’identités sont les informations les plus sensibles que vos systèmes échangeront.

Tentez donc de minimiser la manipulation de celles-ci à l’intérieur de vos applications et optez au maximum pour l’utilisation de jetons d’identité. L’implantation d’un service dédié de fournisseur d’identité sera donc bénéfique d’un point de vue de l’architecture de solution et de la sécurité.