Au chapitre précédent, je vous avais dit qu’on mettrait en œuvre un formulaire de connexion. Cette opération peut être réalisée de différentes manières, et vous devez les connaître avant de vous lancer.
Lorsque vous vous enregistrez sur le site de votre banque, vous partez du principe que vous êtes le seul à pouvoir accéder à vos informations, non ? Il serait malvenu que quelqu’un se connecte à votre compte en se faisant passer pour vous. En vous connectant à votre espace personnel sur le site de votre banque, l’application web vous authentifie, et garantit que vous êtes vous. Lorsque vous consultez une page sur votre compte – vos relevés bancaires, par exemple – l’application vous autorise à accéder à cette page. Ces deux principes – l’authentification et l’autorisation – constituent le cœur de Spring Security.
En sécurité, nous parlons de contrôle d’accès. Il s’agit de contrôler l’accès à une application web nécessitant un mécanisme de connexion. Le contrôle d’accès se compose de deux étapes. Vous avez deviné ?
Authentification et autorisation ?
C’est ça !
Nous allons nous servir de Spring Security pour intégrer un contrôle d’accès à votre application Spring Boot, mais avant ça, plongeons-nous dans les détails de l’authentification et de l’autorisation.
Comprenez le principe d'authentification
Si vous vous êtes déjà rendu dans les bureaux d’une grande entreprise, vous avez pu remarquer qu'il y avait une sécurité à l'entrée : des vigiles vérifient les cartes d’identité, ou alors il faut scanner un badge. Il s’agit d’un contrôle physique d’accès : on s’assure de vous identifier avant de vous laisser entrer.
Dans le cadre d’une application web, comment pensez-vous que le site vous authentifie ?
Par ma connexion à l’aide du mot de passe ?
Voilà !
En principe, vous vous authentifiez sur une application web grâce à votre nom d’utilisateur et votre mot de passe. Un nom d’utilisateur vous identifie. Le mot de passe est uniquement connu par vous. Il s’agit d’une authentification à facteur unique, car votre identification ne relève que d’une seule information (votre mot de passe).
Parfois, il peut vous être demandé de fournir des éléments supplémentaires, comme des empreintes, une preuve physique ou un badge. Il s’agit alors d’une authentification à facteurs multiples, car vous devez, d’une part, connaître votre mot de passe, et d’autre part, prouver que vous êtes bien la personne que vous prétendez être.
Sélectionnez une option parmi les multiples formes d’authentification
Nous venons de voir qu'il existe différentes manières de s'authentifier :
l’authentification à facteur unique, qui permet de se connecter grâce à un mot de passe ;
et l’authentification à facteurs multiples, qui requiert la livraison de plusieurs éléments pour prouver votre identité.
Eh bien, sachez que votre navigateur peut également gérer l’authentification de différentes manières :
l'authentification par session ;
l'authentification par jeton (ou token, en anglais).
Authentification par session
Dans l’authentification par session, les utilisateurs se connectent d’abord grâce à leurs identifiants. Ils sont alors authentifiés et commencent une session. Une session représente la période entre la connexion et la déconnexion de l’utilisateur. Le serveur sauvegarde les informations de session de l’utilisateur, et écrit une copie de ces informations dans un petit fichier (un cookie), également sauvegardé dans le navigateur de l’utilisateur. Ces informations contiennent généralement les identifiants de l’utilisateur, la durée de la session et un numéro de session. Chaque fois que l’utilisateur envoie une requête via l’application web, le serveur consulte le cookie pour s’assurer que les identifiants de la session correspondent à ceux du serveur, et sont encore valides.
Authentification par token
Dans le cadre de l'authentification par token, l’utilisateur s'authentifie sur le serveur, et ce dernier écrit les informations de la session dans un petit fichier (un token) pour effectuer la sauvegarde uniquement sur le navigateur ou l’ordinateur de l’utilisateur. Un token a la même fonction qu’un cookie, mais ces deux processus présentent tout de même des différences significatives. Une authentification par session avec cookie sauvegarde les identifiants sur le serveur et sur le navigateur de l’utilisateur. Tandis que lors d’une authentification par token, un token web JSON (JWT) dispose déjà des informations nécessaires pour valider l’utilisateur ; ainsi, il n’est pas nécessaire de sauvegarder les informations de la session sur le serveur. En cela, cette authentification est qualifiée comme étant sans état (en anglais Stateless).
C’est quoi exactement, ce token web JSON ?
JSON signifie JavaScript Object Notation. Le token web JSON est un objet JavaScript qui encode et transmet vos informations d’authentification. Il valide l’authentification de l’utilisateur, car il détient des informations codées que seul le serveur d'autorisation comprend. Les procédures sont alors plus performantes et sécurisées qu’avec le cookie ; c’est pourquoi la plupart des applications web Java utilisent JWT.
Comprenez le principe d’autorisation
Revenons à notre comparaison avec les bureaux d’une grande entreprise, pour nous aider à comprendre la différence entre l’authentification et l’autorisation. Disons que vous avez déjà pénétré dans les lieux après avoir été authentifié. Vous êtes à l’intérieur du bâtiment, et vous souhaitez désormais aller dans votre service. Votre bureau est situé au cinquième étage, avec tous les autres développeurs. Vous entrez dans l'ascenseur, appuyez sur le bouton du cinquième, mais il ne s’allume pas. 😕
Vous vous rappelez alors que vous devez scanner votre badge avant de pouvoir sélectionner votre étage. Vous êtes authentifié, mais il y a également des contrôles à l’intérieur du bâtiment, pour s’assurer que vous êtes autorisé à accéder à d’autres parties des lieux. L’autorisation s’applique après l’authentification. L’application web prend une autre mesure pour s’assurer que vous êtes autorisé à accéder à certaines de ses parties.
Les applications web fonctionnent majoritairement sur un scénario où l’on trouve des utilisateurs et des administrateurs. Lorsqu’un administrateur est authentifié sur un site, l’application web octroie une série de droits à cette personne, droits dont ne disposent pas les utilisateurs lambda. C’est alors qu’intervient l’autorisation.
Récapitulons ce que nous avons appris concernant les différentes manières de mettre en œuvre l’authentification et l’autorisation, dans le cadre des formulaires de connexion d’une application web.
En résumé
L'authentification permet de s’assurer que l’utilisateur dispose des bonnes informations pour prouver qu’il est bien la personne qu’il prétend être.
L’autorisation permet de s’assurer que l’utilisateur authentifié se rend uniquement sur les pages qu’il est autorisé à consulter.
L’authentification par session utilise des cookies pour stocker les informations de l’utilisateur de la session. Ces cookies sont stockés dans le navigateur de l’utilisateur et sur le serveur d’autorisation.
L’authentification par token utilise un JWT transmis par le serveur d’autorisation. Ce JWT est utilisé pour valider la connexion de l’utilisateur, et peut être stocké directement dans le navigateur ou l’ordinateur de l’utilisateur.
Mettons les théories de ce chapitre en pratique, en créant un formulaire de connexion par défaut de Spring Security dans le prochain chapitre. Nous construirons également une chaîne de filtres Spring Security, pour définir sa configuration de sécurité. C’est parti !
