A Node.js RESTful API-k biztosítása JSON web tokenekkel

Gondolkodott már azon, hogyan működik a hitelesítés? Mi áll a bonyolultság és az absztrakciók hátterében. Valójában semmi különös. Ez az érték titkosításának módja, viszont létrehoz egy egyedi tokent, amelyet a felhasználók azonosítóként használnak. Ez a token igazolja személyazonosságát. Ez hitelesítheti, hogy ki vagy, és hitelesít különféle forrásokat, amelyekhez hozzáférsz. Ha véletlenül sem ismeri ezeknek a kulcsszavaknak, legyen türelmes, az alábbiakban mindent elmagyarázok.

Ez lépésről lépésre bemutatja, hogyan adhat hozzá token alapú hitelesítést egy meglévő REST API-hoz. A szóban forgó hitelesítési stratégia JWT (JSON Web Token). Ha ez nem sokat mond, akkor rendben van. Ugyanolyan furcsa volt számomra, amikor először hallottam a kifejezést.

Mit jelent valójában a JWT egy földi szempontból? Bontjuk le, amit a hivatalos meghatározás állít:

A JSON Web Token (JWT) egy kompakt, URL-ben biztonságos eszköz a két fél között átruházandó követelések megjelenítésére. A JWT állításai JSON objektumként vannak kódolva, amelyet JSON Web Signature (JWS) struktúra hasznos terheként vagy JSON Web Encryption (JWE) struktúra sima szövegeként használnak, lehetővé téve a követelések digitális aláírását vagy integritásvédelmét. MAC (Message Authentication Code) kóddal és / vagy titkosítva.

- Internetes mérnöki munkacsoport (IETF)

Ez egy falat volt. Fordítsuk le ezt angolra. A JWT egy kódolt karakterlánc, amelyet két számítógép között biztonságosan lehet elküldeni, ha mindkettőjük rendelkezik HTTPS-sel. A token olyan értéket képvisel, amelyhez csak az a számítógép férhet hozzá, amely hozzáfér a titkos kulcshoz, amellyel titkosították. Elég egyszerű, igaz?

Hogy néz ki ez a való életben? Tegyük fel, hogy egy felhasználó be akar jelentkezni a fiókjába. Kérést küldenek a szükséges hitelesítő adatokkal, mint például e-mail és jelszó a szerverhez. A szerver ellenőrzi, hogy a hitelesítő adatok érvényesek-e. Ha igen, akkor a kiszolgáló létrehoz egy tokent a kívánt teher és egy titkos kulcs felhasználásával. Ezt a titkosításból származó karakterláncot tokennek nevezzük. Ezután a szerver visszaküldi az ügyfélnek. Az ügyfél viszont elmenti a tokent, hogy felhasználhassa a felhasználó által küldött minden más kérelemben. A token hozzáadása a kérés fejlécéhez az a módszer, amely felhatalmazza a felhasználót az erőforrások elérésére. Ez egy praktikus példa a JWT működésére.

Oké, ez elég beszélgetés! Az oktatóanyag többi része kódolás lesz, és nagyon szeretném, ha követnél és kódolnál velem, ahogy haladunk. Minden kódrészletet magyarázat követ. Úgy gondolom, hogy a helyes megértés legjobb módja az, ha maga kódolja útközben.

Mielőtt elkezdeném, néhány dolgot tudnia kell a Node.js-ről és néhány EcmaScript-szabványról, amelyeket használni fogok. Nem fogom használni az ES6-ot, mivel nem annyira kezdőbarát, mint a hagyományos JavaScript. De arra számítok, hogy már tudja, hogyan kell felépíteni egy RESTful API-t a Node.js segítségével. Ha nem, akkor megtehet egy kitérőt, és ezt ellenőrizheti a folytatás előtt.

Ezenkívül az egész bemutató a GitHubon található, ha teljes egészében szeretné megtekinteni.

Kezdjük el írni a kódot, igaz?

Nos, valójában még nem. Először fel kell állítanunk a környezetet. A kódnak még legalább pár percet kell várnia. Ez a rész unalmas, ezért a gyors felinduláshoz klónozzuk a tárat a fenti oktatóanyagból. Nyisson meg egy terminálablakot vagy parancssori parancsot, és futtassa a következő parancsot:

git clone //github.com/adnanrahic/nodejs-restful-api.git

Látni fogja, hogy megjelenik egy mappa, és nyissa meg. Vessünk egy pillantást a mappa szerkezetére.

> user - User.js - UserController.js - db.js - server.js - app.js - package.json

Van egy felhasználói mappánk egy modellel és egy vezérlővel, valamint az alapvető CRUD már megvalósítva. Az app.js tartalmazza az alapvető konfigurációt. A db.js biztosítja, hogy az alkalmazás csatlakozzon az adatbázishoz. A server.js biztosítja, hogy szerverünk felpörögjön .

Folytassa, és telepítse az összes szükséges Node modult. Váltson vissza a terminálablakára. Győződjön meg róla, hogy a ' nodejs-restful-api ' nevű mappában van, és futtassa npm install. Várjon egy-két másodpercet a modulok telepítéséig. Most hozzá kell adnia egy adatbázis-kapcsolati karakterláncot a db.js fájlba .

Ugorjon az mlab-ra, hozzon létre egy fiókot, ha még nincs, és nyissa meg az adatbázis irányítópultját. Hozzon létre egy új adatbázist, nevezze el tetszése szerint, és lépjen a konfigurációs oldalra. Adjon hozzá egy adatbázis-felhasználót az adatbázisához, és másolja a kapcsolati karakterláncot az irányítópultról a kódjába.

Most csak annyit kell tennie, hogy megváltoztatja a és a helyőrző értékeit . Cserélje ki az adatbázis számára létrehozott felhasználó felhasználónevével és jelszavával. A folyamat részletes, lépésről lépésre történő elmagyarázása megtalálható a fent hivatkozott oktatóanyagban.

Tegyük fel, hogy a felhasználó hoztam létre az adatbázis neve wallya jelszó theflashisawesome. Ezt szem előtt tartva a db.js fájlnak most valami ilyennek kell kinéznie:

var mongoose = require('mongoose'); mongoose.connect('mongodb://wally:[email protected]:47072/securing-rest-apis-with-jwt', { useMongoClient: true });

Menjen előre, és pörgesse fel a szervert, vissza a terminálablak típusába node server.js. Látnia kell, Express server listening on port 3000hogy bejelentkezik a terminálba.

Végül egy kis kód.

Kezdjük azzal, hogy ötletelünk, mit akarunk építeni. Mindenekelőtt hozzá akarjuk adni a felhasználói hitelesítést. Jelentése: egy rendszer bevezetése a felhasználók regisztrálásához és bejelentkezéséhez.

Secondly, we want to add authorization. The act of granting users the permission to access certain resources on our REST API.

Start out by adding a new file in the root directory of the project. Give it a name of config.js. Here you’ll put configuration settings for the application. Everything we need at the moment is just to define a secret key for our JSON Web Token.

Disclaimer: Have in mind, under no circumstances should you ever, (EVER!) have your secret key publicly visible like this. Always put all of your keys in environment variables! I’m only writing it like this for demo purposes.

// config.js module.exports = { 'secret': 'supersecret' };

With this added you’re ready to start adding the authentication logic. Create a folder named auth and start out by adding a file named AuthController.js. This controller will be home for our authentication logic.

Add this piece of code to the top of the AuthController.js.

// AuthController.js var express = require('express'); var router = express.Router(); var bodyParser = require('body-parser'); router.use(bodyParser.urlencoded({ extended: false })); router.use(bodyParser.json()); var User = require('../user/User');

Now you’re ready to add the modules for using JSON Web Tokens and encrypting passwords. Paste this code into the AuthController.js:

var jwt = require('jsonwebtoken'); var bcrypt = require('bcryptjs'); var config = require('../config');

Open up a terminal window in your project folder and install the following modules:

npm install jsonwebtoken --save npm install bcryptjs --save

That’s all the modules we need to implement our desired authentication. Now you’re ready to create a /register endpoint. Add this piece of code to your AuthController.js:

router.post('/register', function(req, res) { var hashedPassword = bcrypt.hashSync(req.body.password, 8); User.create({ name : req.body.name, email : req.body.email, password : hashedPassword }, function (err, user) { if (err) return res.status(500).send("There was a problem registering the user.") // create a token var token = jwt.sign({ id: user._id }, config.secret, { expiresIn: 86400 // expires in 24 hours }); res.status(200).send({ auth: true, token: token }); }); });

Here we’re expecting the user to send us three values, a name, an email and a password. We’re immediately going to take the password and encrypt it with Bcrypt’s hashing method. Then take the hashed password, include name and email and create a new user. After the user has been successfully created, we’re at ease to create a token for that user.

The jwt.sign() method takes a payload and the secret key defined in config.js as parameters. It creates a unique string of characters representing the payload. In our case, the payload is an object containing only the id of the user. Let’s write a piece of code to get the user id based on the token we got back from the register endpoint.

router.get('/me', function(req, res) { var token = req.headers['x-access-token']; if (!token) return res.status(401).send({ auth: false, message: 'No token provided.' }); jwt.verify(token, config.secret, function(err, decoded) { if (err) return res.status(500).send({ auth: false, message: 'Failed to authenticate token.' }); res.status(200).send(decoded); }); });

Here we’re expecting the token be sent along with the request in the headers. The default name for a token in the headers of an HTTP request is x-access-token. If there is no token provided with the request the server sends back an error. To be more precise, an 401 unauthorized status with a response message of No token provided. If the token exists, the jwt.verify() method will be called. This method decodes the token making it possible to view the original payload. We’ll handle errors if there are any and if there are not, send back the decoded value as the response.

Finally we need to add the route to the AuthController.js in our main app.js file. First export the router from AuthController.js:

// add this to the bottom of AuthController.js module.exports = router;

Then add a reference to the controller in the main app, right above where you exported the app.

// app.js var AuthController = require('./auth/AuthController'); app.use('/api/auth', AuthController); module.exports = app;

Let’s test this out. Why not?

Open up your REST API testing tool of choice, I use Postman or Insomnia, but any will do.

Go back to your terminal and run node server.js. If it is running, stop it, save all changes to you files, and run node server.js again.

Open up Postman and hit the register endpoint (/api/auth/register). Make sure to pick the POST method and x-www-form-url-encoded. Now, add some values. My user’s name is Mike and his password is ‘thisisasecretpassword’. That’s not the best password I’ve ever seen, to be honest, but it’ll do. Hit send!

See the response? The token is a long jumbled string. To try out the /api/auth/me endpoint, first copy the token. Change the URL to /me instead of /register, and the method to GET. Now you can add the token to the request header.

Voilà! The token has been decoded into an object with an id field. Want to make sure that the id really belongs to Mike, the user we just created? Sure you do. Jump back into your code editor.

// in AuthController.js change this line res.status(200).send(decoded); // to User.findById(decoded.id, function (err, user) { if (err) return res.status(500).send("There was a problem finding the user."); if (!user) return res.status(404).send("No user found."); res.status(200).send(user); });

Now when you send a request to the /me endpoint you’ll see:

The response now contains the whole user object! Cool! But, not good. The password should never be returned with the other data about the user. Let’s fix this. We can add a projection to the query and omit the password. Like this:

User.findById(decoded.id, { password: 0 }, // projection function (err, user) { if (err) return res.status(500).send("There was a problem finding the user."); if (!user) return res.status(404).send("No user found."); res.status(200).send(user); });

That’s better, now we can see all values except the password. Mike’s looking good.

Did someone say login?

After implementing the registration, we should create a way for existing users to log in. Let’s think about it for a second. The register endpoint required us to create a user, hash a password, and issue a token. What will the login endpoint need us to implement? It should check if a user with the given email exists at all. But also check if the provided password matches the hashed password in the database. Only then will we want to issue a token. Add this to your AuthController.js.

router.post('/login', function(req, res) { User.findOne({ email: req.body.email }, function (err, user) { if (err) return res.status(500).send('Error on the server.'); if (!user) return res.status(404).send('No user found.'); var passwordIsValid = bcrypt.compareSync(req.body.password, user.password); if (!passwordIsValid) return res.status(401).send({ auth: false, token: null }); var token = jwt.sign({ id: user._id }, config.secret, { expiresIn: 86400 // expires in 24 hours }); res.status(200).send({ auth: true, token: token }); }); });

First of all we check if the user exists. Then using Bcrypt’s .compareSync() method we compare the password sent with the request to the password in the database. If they match we .sign() a token. That’s pretty much it. Let’s try it out.

Cool it works! What if we get the password wrong?

Great, when the password is wrong the server sends a response status of 401 unauthorized. Just what we wanted!

To finish off this part of the tutorial, let’s add a simple logout endpoint to nullify the token.

// AuthController.js router.get('/logout', function(req, res) { res.status(200).send({ auth: false, token: null }); });

Disclaimer: The logout endpoint is not needed. The act of logging out can solely be done through the client side. A token is usually kept in a cookie or the browser’s localstorage. Logging out is as simple as destroying the token on the client. This /logout endpoint is created to logically depict what happens when you log out. The token gets set to null.

With this we’ve finished the authentication part of the tutorial. Want to move on to the authorization? I bet you do.

Do you have permission to be here?

To comprehend the logic behind an authorization strategy we need to wrap our head around something called middleware. Its name is self explanatory, to some extent, isn’t it? Middleware is a piece of code, a function in Node.js, that acts as a bridge between some parts of your code.

When a request reaches an endpoint, the router has an option to pass the request on to the next middleware function in line. Emphasis on the word next! Because that’s exactly what the name of the function is! Let’s see an example. Comment out the line where you send back the user as a response. Add a next(user) right underneath.

router.get('/me', function(req, res, next) { var token = req.headers['x-access-token']; if (!token) return res.status(401).send({ auth: false, message: 'No token provided.' }); jwt.verify(token, config.secret, function(err, decoded) { if (err) return res.status(500).send({ auth: false, message: 'Failed to authenticate token.' }); User.findById(decoded.id, { password: 0 }, // projection function (err, user) { if (err) return res.status(500).send("There was a problem finding the user."); if (!user) return res.status(404).send("No user found."); // res.status(200).send(user); Comment this out! next(user); // add this line }); }); }); // add the middleware function router.use(function (user, req, res, next) { res.status(200).send(user); });
A köztes szoftver függvények olyan funkciók, amelyek hozzáféréssel rendelkeznek a kérésobjektumhoz ( req), a válaszobjektumhoz ( res) és nextaz alkalmazás kérés-válasz ciklusában található funkcióhoz. A nextfüggvény az Express útválasztó egyik funkciója, amely meghíváskor a köztes szoftvert az aktuális köztes program után váltja ki.

- Középprogram használatával, expressjs.com

Ugorj vissza a postáshoz, és nézd meg, mi történik, ha eléred a /api/auth/mevégpontot. Meglep, hogy az eredmény pontosan ugyanaz? Kellene lennie!

Jogi nyilatkozat : Folytassa és törölje ezt a mintát, mielőtt folytatnánk, mivel csak a használat logikájának bemutatására szolgál next().

Let’s take this same logic and apply it to create a middleware function to check the validity of tokens. Create a new file in the auth folder and name it VerifyToken.js. Paste this snippet of code in there.

var jwt = require('jsonwebtoken'); var config = require('../config'); function verifyToken(req, res, next) { var token = req.headers['x-access-token']; if (!token) return res.status(403).send({ auth: false, message: 'No token provided.' }); jwt.verify(token, config.secret, function(err, decoded) { if (err) return res.status(500).send({ auth: false, message: 'Failed to authenticate token.' }); // if everything good, save to request for use in other routes req.userId = decoded.id; next(); }); } module.exports = verifyToken;

Let’s break it down. We’re going to use this function as a custom middleware to check if a token exists and whether it is valid. After validating it, we add the decoded.id value to the request (req) variable. We now have access to it in the next function in line in the request-response cycle. Calling next() will make sure flow will continue to the next function waiting in line. In the end, we export the function.

Now, open up the AuthController.js once again. Add a reference to VerifyToken.js at the top of the file and edit the /me endpoint. It should now look like this:

// AuthController.js var VerifyToken = require('./VerifyToken'); // ... router.get('/me', VerifyToken, function(req, res, next) { User.findById(req.userId, { password: 0 }, function (err, user) { if (err) return res.status(500).send("There was a problem finding the user."); if (!user) return res.status(404).send("No user found."); res.status(200).send(user); }); }); // ...

See how we added VerifyToken in the chain of functions? We now handle all the authorization in the middleware. This frees up all the space in the callback to only handle the logic we need. This is an awesome example of how to write DRY code. Now, every time you need to authorize a user you can add this middleware function to the chain. Test it in Postman again, to make sure it still works like it should.

Feel free to mess with the token and try the endpoint again. With an invalid token, you’ll see the desired error message, and be sure the code you wrote works the way you want.

Why is this so powerful? You can now add the VerifyTokenmiddleware to any chain of functions and be sure the endpoints are secured. Only users with verified tokens can access the resources!

Wrapping your head around everything.

Don’t feel bad if you did not grasp everything at once. Some of these concepts are hard to understand. It’s fine to take a step back and rest your brain before trying again. That’s why I recommend you go through the code by yourself and try your best to get it to work.

Again, here’s the GitHub repository. You can catch up on any things you may have missed, or just get a better look at the code if you get stuck.

Remember, authentication is the act of logging a user in. Authorization is the act of verifying the access rights of a user to interact with a resource.

Middleware functions are used as bridges between some pieces of code. When used in the function chain of an endpoint they can be incredibly useful in authorization and error handling.

Hope you guys and girls enjoyed reading this as much as I enjoyed writing it. Until next time, be curious and have fun.

Do you think this tutorial will be of help to someone? Do not hesitate to share. If you liked it, please clap for me.