lesson 3

Author: wisammechano

module4-authentication-and-security/assets/use-of-jwt.webp

@@ -0,0 +1,268 @@
+# Authentication Persistence
+
+In this lesson, we will tackle how to persist user login, or registration between requests. Learning objectives are:
+
+- Difference between stateful and stateless persistence
+- Implementing stateful persistence using express-sessions
+- Implementing stateless identifiers using JSON Web Tokens (JWT)
+
+## **Stateful Session Storage**
+
+In web servers, sessions are server-side temporary storage tools. They are used for a variety of use cases to store temporary data between requests. They use different storage adapters, like RAM, disk, databases, in-memory cache, etc. to save the temporary data.
+
+They are different than database data persistent in that session data are simple key-value stores that can be invalidated and become redundant easily. They are some handy copies (cache) of the original data from the database that are supposedly easier and faster to access and deleting them won't affect the server.
+
+In Express.js, we can use the library [express-session](https://www.npmjs.com/package/express-session) to create session storage. It can be plugged into the Express app as a middleware that attaches a `session` object to any request that comes to the server.
+
+```js
+// ./app.js
+
+const express = require("express");
+const sessions = require("express-session");
+
+// Init our express app
+const app = express();
+
+// Below is where we introduce encrypted sessions
+// Make sure your app secret is unique and
+// defined by cryptographic random generator.
+// It has in-built ability to parse and use cookies
+app.use(
+  sessions({
+    secret: "MY_APP_SECRET",
+    cookie: { secure: false }, // make sure to change this to true on production code
+  })
+);
+
+let listener = app.listen(5000, function () {
+  console.log("Listening on port " + listener.address().port);
+});
+```
+
+In the code snippet above, we configured the session storage using `app.use()` and created a new session instance with the configuration below:
+
+- `secret`: a token that will be used to encrypt the data and cookies. It can also be a universal `APP_SECRET` defined in the environment variables. This must be a random secret generated by secure random generators.
+- `cookie`: cookie parameters that will be set in the client. Because our development environment doesn't have HTTPs, we turned off `secure`. In a production environment, the cookie should only be sent in secure contexts so secure should be true.
+
+This initialization would eventually activate the `session` object in each request, and a `Set-Cookie` header to each response when a session is created. The cookie will contain the `sessionID` that the server can use to read the session storage and grab the session data.
+
+When a cookie is set in the client or browser, the client will always send that cookie with subsequent requests to the original server that issued the cookie. The cookie will be sent as part of the request headers. That's why it is important to ensure it is only sent in secure contexts, so it is encrypted and an eavesdropper can't [hijack the session](https://en.wikipedia.org/wiki/Session_hijacking).
+
+![Session Diagram](../assets/use-of-session-cookies.webp)
+
+This can be used to persist authentication as well. This is often done when a user logs in and activates the **Remember Me** function. When login validation is carried out successfully, the server should also save a user copy to the session as seen in the previous lesson:
+
+```js
+req.session.user = user;
+```
+
+And when requesting protected resources, we can check if the request session that is tied to the request cookies, has the user or not. If it has the user as stored in our login logic, it means the request is authentic.
+
+> ⚠️ **Warning**: When using `express-session`, the default server-side session storage, `MemoryStore`, is purposely not designed for a production environment. It will leak memory under most conditions, does not scale past a single process, and is meant for debugging and developing.
+
+> 💡 **Tip**: `express-session` comes with lots of adapters to store sessions as plug-in libraries. Check out [this list](https://github.com/expressjs/session#compatible-session-stores).
+
+## **Stateless Session Storage**
+
+In stateless session storage, we don't store any temporary data on the server. Thus, the server is state-less. Instead, we issue a session payload in a token that encapsulates the data and sends it to the client for future use in subsequent requests. JWT is often, the way to carry out this process.
+
+JWT is an encoded string that holds **claims** supposed to authenticate and identify a request.
+
+```
+// Example JSON Web Token
+
+eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTYzMjk0MTc4NCwiZXhwIjoxNjMyOTQ1Mzg0fQ.MVnMhRVLYhaGqtZEX4AiEMrQwFWRvRLp6MATodg6E6A
+```
+
+This is a string that has 3 parts separated by a dot (.) and `base64` encoded. It can be decoded easily using any `base64` decoder.
+
+```js
+const token = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTYzMjk0MTc4NCwiZXhwIjoxNjMyOTQ1Mzg0fQ.MVnMhRVLYhaGqtZEX4AiEMrQwFWRvRLp6MATodg6E6A';
+
+token.split('.').forEach(part => console.log(atob(part)))
+
+/* Output:
+{"typ":"JWT","alg":"HS256"}
+
+{"sub":"1234567890","name":"John Doe","admin":true,"iat":1632941784,"exp":1632945384}
+
+1YÌ�Kb†ªÖD_€"ÊÐÀU‘½éèÀ¡Ø:
+```
+
+The first part defines the _algorithm_ and the type. The second part is called the payload or _claims_, which identifies the user, issue time, expiry time, and other data. The third part is called the _signature_.
+
+When a user logs in, the server will issue this token by first defining the claims, signing them, finally encoding and sending them to the client. The client will persist this token somewhere in the browser, most commonly in the `localStorage`.
+
+To make an authenticated request by the client, it needs to pass this token to the server. Commonly, it is added to the request headers using the `Authorization` header.
+
+![JWT Diagram](../assets/use-of-jwt.webp)
+
+### **JWT Validation**
+
+A middleware library like [express-jwt](https://www.npmjs.com/package/express-jwt) can be used on the server to validate JWTs.
+
+```js
+// ./app.js
+
+const express = require("express");
+const jwt = require("express-jwt");
+
+// Init our express app
+const app = express();
+
+// Below is where we introduce JWT
+// Make sure your app secret is unique and
+// defined by cryptographic random generator.
+app.use(
+  jwt({
+    secret: "MY_APP_SECRET",
+    algorithms: ["HS256"],
+  })
+);
+
+let listener = app.listen(5000, function () {
+  console.log("Listening on port " + listener.address().port);
+});
+```
+
+With this, we've set up a JWT validator for every request, that reads the `Authorization` header, validates the token against the signature and expiration date, scope, etc, and parses the claims to identify the user.
+
+Then e can simply access the user object in the request as follows:
+
+```js
+const user = req.user;
+```
+
+### **Issuing JWT**
+
+To issue JWT, your authentication server can use a library [jsonwebtoken](https://www.npmjs.com/package/jsonwebtoken) to issue the token as follows:
+
+```js
+// ./routes/auth.js
+...
+const jwt = require('jsonwebtoken');
+
+// Signing secret
+const SECRET = 'MY_APP_SECRET';
+
+
+router.post('/login', async (req, res) => {
+  const {username, password} = req.body;
+
+  const user = await User.login(username, password);
+
+  if(user) {
+    // User is valid, issue JWT
+    const claims = {
+      sub: user.id,
+      name: user.name,
+      username: user.username
+    }
+
+    const token = jwt.sign(claims, SECRET, { expiresIn: "2h" });
+
+    res.json({ token })
+  } else {
+    res.status(400).render('login')
+  }
+})
+
+...
+```
+
+> ⚠️ **Warning**: Please note that in the code above, for clarity, the `SECRET` was hard-coded and defined inline. **Never do this**. Usually, your `app-secret` is stored in environment variables and **never** shipped with the code.
+
+> 💡 **TIP**: Always keep your tokens short-lived as they are, by design, harder to revoke. The token by default will stay functional until it expires.
+
+### **JWT Signature**
+
+You're probably wondering: if JWTs can be easily decoded and their payload can be seen, how do we make sure that someone doesn't pass any payload to authenticate a request? The signature is the answer.
+
+When issuing JWTs, we take the claims and encrypt them using the `app-secret` key. Then attach that signature to the JWT as a `base64` encoded string. Remember that the `app-secret` is only known by your app.
+
+When the JWT is passed back to the server in the header, we check the claims, and sign them again using our `app-secret`, then compare this signature with the signature provided by the token. If they match, that means the JWT is indeed issued by this app. Otherwise, it is fake.
+
+## **Pros and Cons of JSON Web Tokens**
+
+JWTs are becoming more and more ubiquitous. Customer identity and access management (CIAM) providers everywhere are pushing JWTs as the silver bullet for everything. JWTs are pretty cool, but let’s talk about some of the downsides of JWTs and some of their strong benefits.
+
+### PRO: JWTs are portable units of identity
+
+That means they contain identity information as JSON and can be passed around to services and applications. Any service or application can verify a JWT itself. The service/application receiving a JWT doesn’t need to ask the identity provider that generated the JWT if it is valid or check any database for it. Once a JWT is verified, the service or application can use the data inside it to take action on behalf of the user. Plus, it works across different clients and domains.
+
+### PRO: Token-based Authentication is more Scalable and Efficient
+
+Imagine your app has billions of users, and each of them creates a session. Eventually, the session storage will become pretty big and harder to maintain.
+
+Tokens on the other hand are required to be stored on the user’s end, they offer a scalable solution.
+
+Moreover, the server just needs to create and verify the tokens along with the information, which means that maintaining more users on a website or application at once is possible without any hassle.
+
+### PRO: Flexibility and Performance
+
+Flexibility and enhanced overall performance are other important aspects when it comes to token-based authentication as they can be used across multiple servers and they can offer authentication for diverse websites and applications at once.
+
+This helps in encouraging more collaboration opportunities between enterprises and platforms for a flawless experience.
+
+### PRO: Tokens Offer Robust Security
+
+Since tokens like JWT are stateless, only a secret key can validate it when received at a server-side application, which was used to create it.
+
+Hence they’re considered the best and the most secure way of offering authentication.
+
+Tokens act as a storage for the user’s credentials and when the token travels between the server or the web browser, the stored credentials are never compromised.
+
+### CON: Compromised Secret Key
+
+The best and the worst thing about JWT is that it relies on just one Key.
+
+Consider that this Key could be leaked by a careless or rogue developer/administrator, and then the whole system is compromised! The attacker (who has access to the Key) can easily access all user data if he has the user-id which can easily be acquired.
+
+The only way to recover from this point is to generate a new Key (Key-pair) that will be used across systems from here on. This would mean that all the existing client tokens are invalidated, and every user would have to login again. Imagine if one day all Facebook users are suddenly logged out.
+
+### CON: JWTs expire at specific intervals
+
+When a JWT is created it is given a specific expiration instant. The life of a JWT is definitive and it is recommended that it is somewhat small (think minutes not hours).
+
+Compared with traditional sessions, JWTs are quite different. Sessions are always a specific duration from the last interaction with the user. This means that if the user clicks a button, their session is extended. If you think about most applications you use, this is pretty common. You are logged out of the application after a specific amount of inactivity.
+
+JWTs, on the other hand, are not extended on user interaction. Instead, they are programmatically replaced by creating a new JWT for the user.
+
+To solve this problem, most applications use refresh tokens. Refresh tokens are opaque tokens that are used to generate new JWTs. Refresh tokens also need to expire at some point, but they can be more flexible in this mechanism because they are persisted in the identity provider or database.
+
+### CON: Data Overhead
+
+The overall size of a JWT is quite more than that of a normal session token, which makes it longer whenever more data is added to it.
+
+So, if you’re adding more claims in the token, it will impact the overall loading speed and thus hamper the user experience.
+
+This situation can be fixed if the right development practices are followed and minimum but essential data is added to the JWT.
+
+### CON: JWTs aren’t easily revocable
+
+This means that a JWT could be valid even though the user’s account has been suspended or deleted. Some solutions around this are available but they mostly require trips to the identity provider or the database, which JWT is essentially developed to minimize.
+
+So if your app has the potential to deactivate or revoke user access frequently, think twice before using JWTs.
+
+## Conclusion
+
+In this lesson, we explored authentication persistence using both server-side sessions and client-side tokens. Each has its pros and cons. Sessions have been used for more than 2 decades now, and they are quite robust. However, their limitation comes from poor portability.
+
+JWTs, on the other hand, are also robust and pretty portable. However, they come with their overhead and access longevity issues.
+
+When building your app, always measure the pros and cons of both of these approaches and take your time to decide which one is best for you.
+
+## Read more
+
+- https://www.hebergementwebs.com/news/use-of-session-cookies-vs-jwt-for-authentication
+- https://supertokens.io/blog/all-you-need-to-know-about-user-session-security
+- https://supertokens.io/blog/the-best-way-to-securely-manage-user-sessions?s=y
+- https://supertokens.io/blog/are-you-using-jwts-for-user-sessions-in-the-correct-way
+- https://curity.io/resources/learn/phantom-token-pattern/
+- https://serengetitech.com/tech/what-to-consider-before-using-jwt/
+
+## References
+
+- https://fusionauth.io/learn/expert-advice/tokens/pros-and-cons-of-jwts/
+- https://www.loginradius.com/blog/start-with-identity/pros-cons-token-authentication/
+- https://news.ycombinator.com/item?id=22354534