The express-jwt project is a minimal build of just the essentials to json web token with respect to authentication. it is a portion of my prev express-session-auth, but covers login, logout, and protected route with jwts and passport.js as well.
Like i said earlier in my previous project, the use of tokens as gained a lot of popularity on authentication on the web, and offcourse why not? , it's stateless and can be used as an extension to sessions...
Json web tokens (JWT) is a piece of information encoded with base64 url encoding. It's a stateless form of authentication, that can endure with the help of the client. Unlike session, which is created by the server and unique to that server, JWTs offcourse are unique to a server but have the priviledge of being transferred and communicated over or rather across different varieties of machines , both server to server or client to server.
Think of it as this, with session id, a server creates an id, sends that id to the client mostly a cookie to maintain state and when the client(browser) makes a request, the server checks the id to either know if client is valid or not.. Similiar logic with JWTs , tho people(ME LOL) will always call session , the stateless which turned stateful because by default it always makes use of a cookie when sending information from server to client, tho it holds no information of the client in the cookie. But there are some machines that have poor cookie mamagement(tho they work) , because the cookie was created for the browser and not for any other client device... so transactions like server to server, server to mobile app, wont do well with cookies or rather sessions , so instead we make use of json web tokens and one more thing is that , token sharing works for any machine , even server to client (which sessions dominate or had dominated), the client just needs to have a a feasible location of where to store the token.. imagine storing a token of 2mb(which is pratically unreal tho) in a cookie of 1mb space.....
So basically , that is how it works and we don't need to worry about server remembering the tokens coz we always either use a private and public key to decode the payload we are passing to the client, and with the private key which is secret to the server, the server will always rememeber it's token.
Mostly preferred for browsers, its better to store ids than tokens coz even if the id is stolen, it contains no information talkless of a sensitive information as it's payload, and it is better to store such (token or id) in a HTTP ONLY cookie, than local storage which is vulnerable to XSS Attacks
- dotenv
- express
- MongoDB and mongoose
- Passport and Passport-local and passport-jwt
- Bcrypt
- Crypto
- JOI
- jsonwebtoken
The user logins using the passport local, but session is deactivated coz we dont want to add the user to a session as it will defeat the purpose of jwt stateless, still it won't work coz express session middleware wont be activate.
Using the passport local strategy, the user logins and a token is created for the user, using the json web token library which we will return to the client in a response, with the client deciding what to do with the token(that is, where to store the token).
Then we will use the passport jwt strategy which will extract the jwt from the Authorization header from Bearer ey........token.
Then some keys are created with pem format, using the crypto, fs and path module, which creates a unique private key for a respective publick key or conversely...
To sign the token, we will use the private key while to extract the token we will use the public key, as we are only identifying information and not passing data across some some machines or between some machines, if that was the case, then we will sign the data with a public key and decode with a private (imagine writing a secret message to your crush in class, with some key which you've made public, but only she/he can decrypt the key coz she has a key private which no one has)..
But for our case, we are only identifying identity, so we use a private key to sign that, a key which no one can guess and the identity is unique to the server alone, then anyone with a public key can access the identity and grant permission, which makes sense, coz in real world, the identity from our server wont be sent to one client only but to a ton of them, so these clientS need to have each public key.
Tho, in this case, the server is both handling the private key and public key, probably in future, will build a project that communicates with 2 servers to fully understand..
Credits to ZACH from freecodecamp on youtube on his complete beginners course on user authentication in web apps.