Revenons sur la notion d’authentification et voyons ce qui est possible avec une application web monopage.

Session et cookies
Sessions
En plus de ce que nous savons déjà sur le protocol HTTP, il est bon que nous ajoutons que HTTP est un protocole dit « sans état », le serveur traite les requêtes sans garder de traces des précédentes. C’est la qu’intervient le mécanisme dit des sessions qui permet de conserver temporairement une trace de l’utilisateur.
Le principe est simple : à la première connexion établit avec le serveur, un identifiant de sessions nous est attribué, cet identifiant sera par la suite renvoyé au serveur à chaque requête et permettra une association avec un utilisateur.
Pour conserver cette session, client et serveur possèdent différents atouts. Dans un premier temps, coté serveur, on conservera simplement notre sessions en mémoire. Cette approche  est la plus simple mais déconseillé en production (Dans le cas ou le nombre de sessions augmente, la mémoire)
Coté client, il y a deux grandes méthodes pour gérer les sessions : les cookies ou le webstorage. Le webstorage permet quand meêm de stocker un plus grand nombres de données.
Cookies
Nous avons tous déjà eu à faire au cookie, rappelons nous de quoi il s’agit, ce sont de simples fichiers texte non exécutables et bien qu’il ne soit pas limités à cet usage, on s’en sert souvent pour les questions de sessions.

Sécurisation par tokens (jetons)
Il s’agit d’une autre méthode, couramment utilisée dans les services web, il est question ici de tokens ou jetons. La technique est un peu différente, car on ne conserve pas la sessions entre le client et le serveur (On dit que l’authentification par token est donc Stateless)
Pour que nous comprenions mieux les différences, voici une illustrations de connexion d’un utilisateur avec d’une part les sessions et d’autre part son équivalent avec les jetons.
			AuthSessions

			AuthToken
Dans le cas des jetons, nous voyons clairement qu’aucune session n’est conservée. Il va simplement décoder le code renvoyé par le client au format JSON.

Quelles sont les avantages que nous pouvons en tirer ? En effet, les avantages d’une authentification par jeton par rapport aux cookies sont nombreux.
Plus grand découplage possible
Le découplage entre le client et le serveur est totalement claire grâce à l’authentification par jetons. En effet, contrairement aux sessions, les jetons du à leur aspect « sans etat » ne nous obligent pas, à conserver en sessions, les traces de l’utilisateur.
Protection contre les attaques CSRF
Une attaque dite CSRF (Cross-Site Request Forgery ) consiste à se servir des données de session de l’utilisateur attaqué pour contourner une protection.
Prenons un exemple pour mieux vous l’expliquer, Imaginons que l’attaquant possède un lien de suppression d’article sur un blog. Bien entendu, s’il tente lui-même d’effectuer l’action, le serveur lui demandera de s’authentifier.
Il peut outrepasser cette sécurité en envoyant le lien (généralement caché) à une personne possédant une session en cours. Alors l’action s’effectuera au nom de l’utilisateur attaqué.
Tout d’abord dans le cas des jetons, il n’est pas question de session. En plus de ça, les jetons sont générés à la volé et vérifiés parle serveur. Attention, cela n’assure en aucun cas que les jetons fournissent une sécurité parfaite. Mais du moins ce genre d’attaques sont évités.
Meilleur performances
Cela vaut surtout pour de grosse architecture, mais le faite de ne plus devoir aller chercher les données de sessions, il est possible de gagner en performances.
L’authentification par jetons
Finalement, j’ai décidé d’utiliser l’authentification par jetons, pour une meilleure compréhension j’ai décidé de séparer les modifications apportées aux back-end et au front-end.
Le back-end
Pour ce qui est d’intégrer l’authentification par jetons avec rails il suffit d’inclure à ApplicationController deux implémentations Active Record. Pour ce faire nous utilisons les deux lignes suivantes :

		Inc	ludeAuth
Nous avons maintenant accès à deux méthodes très utiles dont nous voyons l’implémentation ci-dessous :

			Implé1
Rien de nouveau, nous faisons une authentification de ce qui a de plus simple avec un email et un mot de passe. Si l’authentification est reussie, nous envoyons au travers d’un objet JSON le token correspondant.
			Implé2
Par contre ici, on vérifie si la session est valide par le token, mais cette méthode est inutile seule car n’est jamais appelé. Il faut ajouter une ligne, pour qu’elle soit appelé à chaque requête.

				Impl3
Ce dernier ajout permet de s’assurer que la vérification par token sera faite avant d’excuter quoi que ce soit. Sauf dans ce cas ci pour la routine token.

Quant à la création, il se fait au moment ou l’ont créé pour la première fois l’utilisateur. Pour ce faire on ajoute ces lignes de code au niveau du modèle Utilisateur.
				Impl4