diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000000000000000000000000000000000..600d2d33badf45cc068e01d2e3c837e11c417bc4
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+.vscode
\ No newline at end of file
diff --git a/docs/miscellaneous/authentication&authorization.md b/docs/miscellaneous/authentication&authorization.md
index 2fae0bf7e3bceee53bc0b830bb25c34a3ee06c67..08a10044dd2f8fc994f564f5dea761738bb3bd56 100644
--- a/docs/miscellaneous/authentication&authorization.md
+++ b/docs/miscellaneous/authentication&authorization.md
@@ -208,7 +208,7 @@ This authentication service will then start a process of a couple steps:
 *  Based on the created consumer and thanks to the [JWT plugin](https://docs.konghq.com/hub/kong-inc/jwt/) of Kong, the authentication service will get the JWT Credentials of the user. Those are per user credentials containing a public and private key. If the user does not have credentials yet, the authentication service will generate them using the appropriate endpoint of the Kong JWT plugin.
 *  The service generates a unique random Uuid4 that we name "xsrf token" 
 *  At this point, the authentication service has everything it needs to generate authentication pieces for the user. Using the credentials coming from Kong it will sign a JSON Web Token containing some of the User info (firstname, lastname, username, email) as well as the user encrypted password and the xsrf token.
-* Finally the authentication service will return a response to the front application with the xsrf token and the user info in the body. It will also set a cookie `access_token` containing the JWT for the domaine name hosting the application.
+* Finally the authentication service will return a response to the front application with the user info in the body. It will also set a cookie `access_token` containing the JWT and a second cookie `XSRF-TOKEN` containing the xsrf token.
 
 ```plantuml
 @startuml
@@ -255,13 +255,31 @@ group Login
     auth <-- kong : Ok
     auth -> kong : <b>GET or POST</b> /consumers/:email/jwt (POST if no creadetials exist for this user)
     auth <-- kong : { credentials }
-    front <-- auth : { token: jwt }
+    front <-- auth : { userInfo + COOKIES }
 end
 
 @enduml
 ```
 
-At the end of this process, the front web application has the authentication pieces required to access restricted resources. Let's take the example of the user data accesses.
+At the end of this process, the front web application has the authentication pieces required to access restricted resources. we will see why in a bit but first let's understand why it is secured and how it works.
+
+### Understanding how and why it is secured
+
+There are two well known attacks that can trick a user to perform unwanted actions without him/her knowing: XSS and CSRF.
+
+**Cross-site scripting (or XSS)** allows an attacker to execute arbitrary JavaScript within the browser of a victim user.
+
+**Cross-site request forgery (or CSRF)** allows an attacker to induce a victim user to perform actions that they do not intend to.
+
+Let's imagine we stored our JWT in the localStorage. In the case of an XSS attack, we can easily imagine that the injected Javascript could retrieve the JWT from the localstorage and use it to make an authenticated request. In order to prevent that, instead of storing the jwt in the localStorage we use an HttpOnly cookie set for the full domain of our Api Gateway (ex: api.mydomain.com). Using the HttpOnly option, we make sure that this cookie can't be read by any Javascript and only the browser we be able to pass it along when making Http requests to our services through the Api Gateway. The cookie will only be sent along for requests to the specified domain (or any subdomains). We also make sure that the cookie is sent other HTTPS by using the secure option of the cookie.
+
+> **Warning for Angular**: when using the Angular HTTPClient the cookies aren't sent along by default, you have to use the [WithCredentials](https://angular.io/api/common/http/HttpRequest) option.
+
+At this point we are protected against XSS, however we are still vulnerable to CSRF. For example with injections an attacked could make the user's browser call an endpoint of our API from another website. If the user is authenticated and posses an `acces_token` cookie the browser will send it along and so the user will perform actions unwillingly. To prevent that we will use an XSRF token.
+
+When the user logs in, the authentication service will generate a unique random XSRF Token (UUID4 for example). This token will be added to the payload of the JWT but also set as a `XSRF-TOKEN` cookie. This second cookie wont be HttpOnly and will be set for the domaine name of the web application (the more restrictive is the best but for technical reasons it can be complicated so mydomain.com is fine). This cookie is will be `secure` and will have the `SameSite` option to `Strict`. This means that the cookie will be sent to the server only if the request originates from an application that match the specified domain. As it is accessible by Javascript, our web application will use this cookie to set an `x-xsrf-token` header that will contain the XSRF token. Now on the server side we will juste need to implement a middleware in our services that verifies that the value of the `x-xsrf-token` match with the `xsrfToken` value of the paylod of the JWT from the `access_token` cookie. With this token even if an attacker force a user to make a request to our Api it will only send along the `access-token` cookie and won't have the `x-xsrf-token` header.
+
+Now that we explained the role of the differents tokens and cookies, we will explain what happens on the server side for an authenticated request. Let's take the example of a user accessing the `Data accesses` page.
 
 ```plantuml
 @startuml
@@ -306,14 +324,14 @@ end
 @enduml
 ```
 
-When a user navigates to the data accesses page, the web application makes a call to the middleware through the API gateway: Kong. The JWT plugin of Kong will verify that the request has a valid JWT (not expired, not modifed) in the dedicated cookie. In the failing case, Kong will return a `401` http error, otherwise it will proxify the request to the authentication service.
+When a user navigates to the data accesses page, the web application makes a call to the middleware through the API gateway: Kong passing along the `access_token` cookie and the `x-xsrf-token` header. The JWT plugin of Kong will verify that the cookie contains a valid JWT (not expired, not modifed) in the dedicated cookie. In the failing case, Kong will return a `401` http error, otherwise it will proxify the request to the legacy authentication middleware.
 
 Each endpoints that requires a user identity are protected by a "middleware". You can find the corresponding code in the `decode-jwt-payload.middleware.ts` file of our projects. The main role of this application middleware is to decode the JWT payload in order to get the user identity (username, encrypted password).
 
 However in order to get through the middleware and go on with the incoming request the following criteria must be met:
 * the `x-anonymous-consumer` header value of the request must not be `true` (meaning that kong as identified an existing user)
-* the request contains the two pieces of identity `JWT` and `xsrf-token`
-* the xsrf-token present in the header is the same as the one present in the JWT payload
+* the request contains the two pieces of identity JWT in the `access_token` cookie and the XSRF token in the `x-xsrf-token` header
+* the x-xsrf-token present in the header is the same as the one present in the JWT payload
 If one or more of those verifications fails the middleware will return a `401 Unauthenticated` error.
 
 If the get user resources request passes successfully those tests, the legacy middleware authentication will call the Legacy auth service and return the user resoures.