Implementirajte JWT autentifikaciju u Node.js API-jima kao profesionalac

Početna » Piton » Implementirajte JWT autentifikaciju u Node.js API-jima kao profesionalac

Ako gradite API-je s Node.js-om, dodavanje odgovarajuće autentifikacije s JWT-om jedna je od onih stvari koje u početku mogu djelovati zastrašujuće, ali zapravo ne mora biti. S nekoliko dobro odabranih biblioteka, jasnom strukturom i nekim dobrim praksama oko validacije i sigurnosti, možete zaštititi svoje krajnje točke, a i dalje održavati svoju kodnu bazu čistom i održivom.

U ovom vodiču proći ćemo kroz implementaciju JWT-bazirane autentifikacije u Node.js API-ju koristeći Express, MongoDB i alate poput jsonwebtoken, bcrypt, Joi i dotenv, a također ćemo vidjeti kako validirati tokene pomoću JWKS krajnje točke s autorizacijskog poslužitelja u scenarijima orijentiranijim na poduzeća. Naučit ćete kako dizajnirati strukturu projekta, kreirati modele i rute, generirati i provjeravati tokene, dodati middleware za autorizaciju i sve povezati tako da samo autentificirani korisnici mogu pristupiti zaštićenim resursima.

Što JSON web tokeni (JWT) donose vašim Node.js API-jima

JSON web tokeni (JWT) su kompaktni, URL-sigurni tokeni koji nose skup zahtjeva i omogućuju dvjema stranama razmjenu autentificiranih informacija bez zadržavanja stanja sesije na strani poslužitelja. U kontekstu Node.js API-ja to znači da nakon što se korisnik prijavi i izdate JWT, svaki sljedeći zahtjev može biti provjeren od strane vašeg backenda koristeći samo sam token i tajni ili javni ključ, što se skalira puno bolje od tradicionalnih poslužiteljskih sesija.

Tipičan JWT sastoji se od tri dijela: zaglavlja, korisnog tereta i potpisa, svi kodirani u Base64URL formatu i odvojeni točkama, na primjer xxxxx.yyyyy.zzzzz. Zaglavlje obično specificira algoritam i vrstu tokena, korisni teret sadrži korisničke zahtjeve kao što su ID, uloge ili dopuštenja, a potpis osigurava integritet tako da se token ne može neotkriveno mijenjati.

Prilikom implementacije JWT-a u Node.js API-jima, token se obično koristi kao noseći token u Authorization HTTP zaglavlje, kao što je Authorization: Bearer <token>, a zatim ga dekodirajte i validirajte unutar vašeg Express middlewarea ili rukovatelja rutama. Ako je token valjan, dekodirani teret možete priložiti objektu zahtjeva i kasnije ga koristiti za odluke o autorizaciji ili za personalizaciju odgovora.

Jedan snažan aspekt JWT-ova jest to što su jezično agnostični i široko podržani u ekosustavima, što ih čini izvrsnim izborom za osiguranje API-ja koje koriste React, Vue, mobilne aplikacije ili bilo koji klijent treće strane. U kombinaciji s pouzdanom validacijom i pravilnim upravljanjem ključevima, omogućuju Node.js servisima da čisto sudjeluju u arhitekturama temeljenim na OAuth 2.0 i OpenID Connectu.

Pregled projekta: Node.js API s JWT autentifikacijom

Zamislimo jednostavan, ali realističan Node.js API gdje se korisnici mogu registrirati, prijaviti i pristupiti zaštićenim krajnjim točkama tek nakon što predoče valjani JWT. Oslanjat ćemo se na Express za usmjeravanje, Mongoose za integraciju s MongoDB-om, jsonwebtoken za stvaranje i provjeru tokena, bcrypt za sigurno hashiranje lozinki, Joi za validaciju unosa i dotenv za upravljanje konfiguracijom.

Čist raspored mapa pomaže u razumijevanju kako projekt raste, pa umjesto da sve strpamo u jednu datoteku, definirat ćemo osnovnu strukturu s odvojenim modulima za konfiguraciju, bazu podataka, modele, rute i middleware. Ovaj modularni pristup također olakšava jedinično testiranje određenih dijelova toka autentifikacije.

Na visokoj razini, API će otkriti skup REST krajnjih točaka za registraciju i prijavu korisnika, plus barem jedan zaštićeni resurs kojem se može pristupiti samo s valjanim JWT-om u zaglavljima zahtjeva. Usput ćemo vidjeti kako validirati zahtjeve, hashirati i uspoređivati ​​lozinke, generirati tokene koji ugrađuju korisnički ID i integrirati middleware za autorizaciju koji provjerava tokene na dolaznim pozivima.

Isti se obrazac može proširiti na složenije sustave, uključujući one koji se integriraju s vanjskim autorizacijskim poslužiteljem i koriste JWKS krajnje točke za validaciju dolaznih tokena za pristup od OAuth 2.0 klijenata. Taj drugi scenarij je posebno čest kada delegirate autentifikaciju davateljima identiteta ili trebate podržati jednokratnu prijavu na više usluga.

Prije nego što se upustimo u detalje implementacije, navedimo ključne dijelove okruženja na koje ćemo se oslanjati i zašto je svaka ovisnost važna za sigurno rukovanje JWT-om u Node.js-u.

Osnovne ovisnosti za JWT autentifikaciju u Node.js-u

Express je okosnica mnogih Node.js API-ja, pružajući minimalan, ali fleksibilan okvir za usmjeravanje, middleware i rukovanje HTTP-om. U našem slučaju, Express će poslužiti kao platforma na kojoj registriramo rute poput /api/users or /api/auth, i gdje uključujemo JWT verifikacijski middleware koji štiti osjetljive krajnje točke.

Mongoose je biblioteka za modeliranje objektnih podataka (ODM) koja olakšava interakciju s MongoDB-om putem shema i modela, umjesto izravnog rada sa sirovim upitima. Koristit ćemo ga za definiranje User model sa svojstvima kao što su ime, e-pošta i lozinka te pohraniti ili dohvatiti te dokumente iz baze podataka na način siguran za tip.

The jsonwebtoken knjižnica je standardni izbor u Node.js-u za stvaranje i provjeru JWT-ova pomoću tajnog ili javnog ključa. Tijekom prijave potpisat ćemo token koji sadrži korisnički ID (i sve ostale potrebne tvrdnje), a kasnije ćemo provjeriti taj token na zaštićenim rutama, odbacujući svaki zahtjev koji sadrži nevažeći, oštećeni ili istekli token.

Za sigurnost lozinki, bcrypt se koristi za hashiranje lozinki u običnom tekstu prije pohrane i za usporedbu unesenih vjerodajnica s hashiranim vrijednostima tijekom autentifikacije. Ovo je ključno, jer pohranjivanje sirovih lozinki ili korištenje slabih strategija hashiranja izlaže vaše korisnike ogromnim rizicima u slučaju curenja baze podataka, dok bcrypt pruža provjereno, testirano rješenje.

Joi igra veliku ulogu u validaciji dolaznih podataka na granici API-ja, opisujući sheme za objekte i provjeravajući ponaša li se svaki zahtjevni teret kako se očekuje. Na primjer, možemo definirati da e-pošta mora biti ispravno formatirana, da lozinka ima minimalnu duljinu i da su određena polja obavezna, što značajno smanjuje šanse da se loš ili zlonamjeran unos uvuče u našu logiku.

Konačno, dotenv nam omogućuje učitavanje varijabli okruženja iz .env datoteku, čuvajući tajne poput JWT ključeva za potpisivanje, URL-ova baze podataka ili postavki konfiguracije izvan izvornog koda. To pomaže u izbjegavanju kodiranja osjetljivih vrijednosti i potiče bolje odvajanje konfiguracija razvoja, pripremnih i produkcijskih konfiguracija.

Postavljanje Express poslužitelja i okruženja

Ulazna točka našeg API-ja je obično index.js datoteka u kojoj pokrećemo Express, registriramo middleware i montiramo naše definicije ruta. U ovoj datoteci trebat će nam konfiguracija baze podataka, moduli usmjeravanja i globalni middleware poput parsiranja tijela JSON-a ili CORS-a.

Odmah nakon učitavanja ovisnosti, dobra je ideja pozvati require("dotenv").config() pa varijable okruženja iz .env datoteka postaje dostupna putem process.env. To uključuje ključeve poput JWT_PRIVATE_KEY, MONGO_URI ili port na kojem će poslužitelj slušati, što konfiguraciju održava fleksibilnom i sigurnom.

Sama Express aplikacija obično će koristiti app.use(express.json()) za parsiranje tijela JSON zahtjeva i montiranje usmjerivača za određene URL prefikse, kao što su app.use("/api/users", usersRouter) i app.use("/api/auth", authRouter). Ovo odvajanje drži rute povezane s autorizacijom i brige o upravljanju korisnicima izoliranima od ostalih dijelova API-ja.

Nakon što je okruženje konfigurirano i Express pokrenut, sljedeći korak je povezivanje MongoDB baze podataka putem namjenskog modula, često db.js datoteka u kojoj postavljamo logiku povezivanja.

Konfiguriranje MongoDB-a s Mongooseom

u db.js modul, obično uvozimo Mongoose i pozivamo mongoose.connect() s MongoDB nizom za povezivanje pohranjenim u varijabli okruženja. Također možemo konfigurirati opcije poput logike ponovnog pokušaja, ujedinjene topologije ili grupiranja veza kako bismo osigurali stabilno ponašanje u produkcijskim okruženjima.

Uobičajeno je zapisati poruku kada veza uspije i elegantno obraditi pogreške tako da ako MongoDB nije dostupan, API se pokreće s jasnom dijagnostikom. U punoj aplikaciji, možete čak odabrati i izlazak iz procesa ako se veza s bazom podataka prekine, budući da mnoge rute ovise o njoj.

kada je db.js datoteka je implementirana, uvozimo je iz index.js i pozvati ga rano tijekom pokretanja aplikacije, pazeći da je naš API povezan s bazom podataka prije obrade bilo kojeg zahtjeva. Ova odvojenost održava konfiguraciju izoliranom i ponovno upotrebljivom, dok index.js ostaje usredotočen na zabrinutosti Expressa.

Nakon što je baza podataka povezana, možemo prijeći na modeliranje podataka koji pokreću naš sustav autentifikacije, što počinje definicijom korisničke sheme i modela.

Izgradnja korisničkog modela s JWT podrškom

The User model, obično smješten u /models/user.js, definira strukturu korisničkih dokumenata pohranjenih u MongoDB-u i enkapsulira ponašanje vezano uz autentifikaciju. Minimalno ćemo uključiti svojstva kao što su name, email i password, a po potrebi možemo dodati i vremenske oznake, uloge ili druge metapodatke.

Tipičan obrazac je označavanje polja e-pošte kao jedinstvenog i obaveznog, osiguravajući da se dva korisnika ne mogu registrirati s istom adresom e-pošte. Slično tome, polje za lozinku neće pohraniti običnu tekstualnu vrijednost; umjesto toga pohranit ćemo bcrypt hash generiran prilikom registracije ili kada korisnik ažurira svoje vjerodajnice.

Zanimljiva i vrlo praktična dizajnerska odluka je dodavanje metode korisničkoj shemi za generiranje JWT-ova, koja uzima korisnički ID kao korisni teret i potpisuje ga tajnim ključem definiranim u okruženju. Ova se metoda može pozvati tijekom prijave kako bi se generirao token specifičan za tog korisnika, a logika generiranja tokena smještena je u model koji posjeduje podatke o identitetu.

U kombinaciji s Joi-baziranim validacijskim pomagačima, korisnički model postaje središnji dio za sve što je vezano uz identitet: opisivanje oblika korisničkih podataka, validiranje dolaznih korisnih podataka i generiranje tokena koje koristi ostatak API-ja.

Odavde možemo implementirati rute odgovorne za registraciju novih računa i autentifikaciju postojećih korisnika, koristeći korisnički model, bcrypt i Joi zajedno.

Izrada registracijske rute

Logika registracije obično se nalazi u modulu rute kao što je /routes/users.js, gdje definiramo krajnju točku kao što je POST /api/users za obradu dolaznih zahtjeva za prijavu. Ova ruta će validirati korisni teret pomoću Joi-ja, provjeriti je li e-pošta već u upotrebi, hashirati lozinku, kreirati korisnika i spremiti ga u bazu podataka.

Prije nego što bilo što zadržimo, možemo koristiti Joi shemu koja provodi zahtjeve kao što su obavezno ime i e-pošta, ispravan format e-pošte i minimalna duljina lozinke. Ako validacija ne uspije, ruta odgovara odgovarajućim kodom statusa pogreške i porukom, sprječavajući da neispravni podaci dođu do poslovne logike.

Ako e-mail adresa već ne postoji, generiramo bcrypt salt i hashiramo lozinku, zamjenjujući sirovu lozinku njezinom hashiranom verzijom u objektu korisnika. Ova hashirana vrijednost je ono što se u konačnici pohranjuje u MongoDB-u, što značajno ograničava utjecaj potencijalnih povreda podataka.

Nakon spremanja novog korisnika, neke implementacije također odmah generiraju JWT i vraćaju ga u zaglavlju ili tijelu odgovora, tako da se korisnik smatra autentificiranim odmah nakon registracije. Drugi API-ji mogu zahtijevati zaseban korak prijave, ovisno o sigurnosnim zahtjevima sustava.

Nakon što je registracija završena, prateća ruta za prijavu može ponovno koristiti većinu iste logike validacije, a istovremeno se usredotočiti na provjeru vjerodajnica i izdavanje tokena.

Implementacija rute za prijavu i generiranje tokena

Tijek prijave se obično obrađuje u /routes/auth.js, s krajnjom točkom poput POST /api/auth koji u tijelu zahtjeva prima e-poštu i lozinku. Ova ruta ponovno koristi Joi kako bi se osiguralo da su oba polja prisutna i pravilno strukturirana prije pokušaja autentifikacije korisnika.

Nakon validacije, ruta pretražuje bazu podataka za korisnika s navedenom e-poštom i ako ga pronađe, koristi bcrypt za usporedbu navedene lozinke s pohranjenim hashom. Ako usporedba ne uspije, zahtjev se odbija s odgovarajućom porukom o pogrešci; u suprotnom, prelazimo na izdavanje tokena.

U trenutku uspješne autentifikacije, pozivamo metodu za generiranje tokena definiranu na korisničkom modelu, koja stvara JWT s ugrađenim identifikatorom korisnika (i eventualno drugim zahtjevima) i potpisuje ga tajnim ključem. Ovaj token se zatim može poslati klijentu, često u tijelu odgovora ili prilagođenom zaglavlju, gdje ga frontend ili vanjski potrošač pohranjuje i ponovno koristi za buduće zahtjeve.

S klijentske strane, svaki sljedeći poziv zaštićenim krajnjim točkama uključivat će ovaj JWT u Authorization zaglavlje kao token nosioca, što je upravo ono što će naš middleware tražiti. Na strani poslužitelja, namjenski middleware za autorizaciju osigurava da ne ponavljamo logiku provjere tokena u svakoj pojedinoj ruti.

Prije nego što se udubimo u taj middleware, vrijedi napomenuti da se isti obrazac lijepo integrira s Reactom ili drugim SPA okvirima, gdje se JWT-bazirani tokovi obično koriste za autentifikaciju i jednostavne potrebe autorizacije.

Izgradnja Auth Middleware-a za zaštitu ruta

Middleware za autentifikaciju, često implementiran u /middleware/auth.js, djeluje kao čuvar vrata za bilo koju rutu koja zahtijeva autentifikaciju, presrećući zahtjeve prije nego što stignu do rukovatelja rutom. Njegov primarni zadatak je čitati JWT iz Authorization zaglavlje, provjerite ga i ubrizgajte dekodirani korisni teret u objekt zahtjeva za kasniju upotrebu.

Middleware započinje provjerom da je Authorization zaglavlje postoji i slijedi očekivano Bearer <token> format; ako token nedostaje ili je neispravan, odmah odgovara neovlaštenim statusnim kodom. To osigurava da nezaštićeni zahtjevi slučajno ne prođu u zaštićene krajnje točke.

Kada je token prisutan, middleware poziva jwt.verify() (od jsonwebtoken knjižnica), prosljeđujući token i tajni ili javni ključ koji se koristi za potpisivanje. Ako provjera ne uspije zbog isteka, neusklađenosti potpisa ili bilo kojeg drugog problema, middleware odgovara s greškom; u suprotnom, bilježi dekodirani korisni teret.

Mnoge implementacije pridružuju ovaj dekodirani korisni teret req.user ili slično svojstvo, tako da rukovatelji rutama nizvodno mogu pristupiti zahtjevima povezanim s korisnicima bez potrebe za ponovnim parsiranjem ili ponovnom provjerom tokena. Konačno, pozivi middlewarea next() prenijeti kontrolu na sljedeću funkciju u Express cjevovodu.

Kombiniranjem ovog middlewarea s definicijama ruta, možemo jednostavno označiti neke krajnje točke kao javne, a druge kao zaštićene jednostavnim dodavanjem middlewarea u lanac obrade zahtjeva za te rute.

Pristup zaštićenim resursima pomoću JWT-a

Uobičajeni slučaj upotrebe nakon implementacije autentifikacije je pružanje rute koja dohvaća trenutni korisnički profil ili popis korisnika, dostupan samo pozivateljima koji predoče valjani token. Na primjer, u /routes/users.js, moglo bi postojati GET /api/users/me krajnja točka koja vraća informacije o prijavljenom korisniku.

Kako bismo zaštitili ovu rutu, prilažemo middleware za autorizaciju tako da svaki zahtjev koji joj se približi mora nositi valjani JWT; u suprotnom, middleware će prekinuti zahtjev prije nego što se stvarni rukovatelj izvrši. Budući da je dekodirani korisni teret već pričvršćen na req.user, rukovatelj može izravno dohvatiti korisnički ID iz tokena i shodno tome upitati bazu podataka.

Ovaj obrazac osigurava da poslovna logika ne mari za to kako je izvršena autentifikacija; ona jednostavno vjeruje prisutnosti provjerenog korisnog tereta i fokusira se na dohvaćanje ili izmjenu podataka domene. U naprednijim postavkama možete ugraditi i uloge, dopuštenja ili opsege unutar tokena i koristiti ih za pokretanje provjera autorizacije u rukovateljima.

S gledišta korisnika, pozivatelj će prvo pristupiti krajnjoj točki za prijavu kako bi dobio token, a zatim će ga uključiti u sljedeće zahtjeve prema tim zaštićenim krajnjim točkama, često iz SPA-a poput Reacta, mobilne aplikacije ili backend-to-backend integracije. Cjelokupno iskustvo je glatko ako su poruke o pogrešci jasne kada je token istekao ili je nevažeći.

U ovom trenutku smo obradili samostalnu JWT postavku koristeći tajnu pohranjenu u našem .env datoteku, ali mnogi produkcijski sustavi se također integriraju s vanjskim autorizacijskim poslužiteljima i koriste JWKS krajnje točke za validaciju tokena; tu na scenu stupa Express middleware za OAuth-osigurane API-je.

Korištenje JWKS krajnje točke za validaciju JWT-ova u Node.js-u

U naprednijim arhitekturama, posebno onima koje se oslanjaju na OAuth 2.0 i OpenID Connect, Node.js API-ji često primaju pristupne tokene koje izdaje vanjski autorizacijski poslužitelj, umjesto da sami generiraju JWT-ove. U ovom slučaju, API mora validirati tokene potpisane asimetričnim ključevima, obično RSA ili EC, gdje samo autorizacijski poslužitelj posjeduje privatni ključ.

Uobičajeno rješenje je korištenje Express middleware biblioteke koja dohvaća JSON Web Key Sets (JWKS) s konfigurirane krajnje točke koju otkriva Authorization Server. Ta JWKS krajnja točka izlaže javne ključeve u standardnom formatu, omogućujući API-ju da provjeri dolazne JWT potpise bez potrebe za upravljanjem privatnim ključevima.

Na primjer, možete instalirati paket kao što je express-oauth-jwt i konfigurirajte ga s JWKS URL-om, kao što je https://idsvr.example.com/oauth/v2/oauth-anonymous/jwks, a zatim uključite middleware u svoje Node.js API rute. Nakon integracije, middleware automatski obrađuje većinu zadataka validacije tokena niske razine.

S tom konfiguracijom na mjestu, knjižnica pretražuje kid (ID ključa) iz JWT zaglavlja, preuzima odgovarajući javni ključ s JWKS krajnje točke (ako već nije predmemoriran) i provjerava potpis pomoću tog ključa. Također provjerava istek tokena, izdavatelja, publiku i druga standardna polja, ovisno o tome kako konfigurirate njegove opcije.

Nakon uspješne validacije, parsirani JWT i njegovi zahtjevi postaju dostupni na Expressu. request objekt, omogućujući vašim rukovateljima da pregledaju opsege, korisničke identifikatore ili prilagođene atribute u svrhu autorizacije i evidentiranja. Ako nešto pođe po zlu (na primjer, token je istekao ili potpis ne odgovara), middleware odgovara odgovarajućim HTTP kodovima grešaka i uključuje razlog u WWW-Authenticate Zaglavlje.

Opsezi, zahtjevi i logika autorizacije u vašem API-ju

Nakon što vaš Node.js API vjeruje JWT-u, bilo zato što ga je izravno potpisao ili zato što ga je JWKS-bazirani middleware validirao, sljedeći korak je korištenje njegovih zahtjeva i opsega za implementaciju autorizacije. Ovdje idete dalje od jednostavne autentifikacije i počinjete odobravati ili odbijati pristup na temelju onoga što korisnik smije raditi.

Opsezi obično predstavljaju grubozrnate dozvole, kao što su read:users or write:ordersi obično su uključeni u JWT-ove pod tvrdnjom poput scope or scopes. API može provjeriti je li potreban opseg prisutan prije obrade zahtjeva koji se dotiče određenih poslovnih podataka, vraćajući zabranjeni odgovor ako nedostaje.

Slično tome, zahtjevi poput korisničkog ID-a, e-pošte, uloge ili podataka o zakupniku omogućuju vam implementaciju preciznijih pravila; na primjer, osiguravanje da korisnici pristupaju samo vlastitim zapisima ili ograničavanje administrativnih radnji na određene uloge. U Expressu je jednostavno napisati prilagođene middlewareove koji ispituju ove tvrdnje. req.user i primijeniti provjere pravila.

Neke JWT validacijske biblioteke za Express nude ugrađene hooks-ove za provjeru potrebnih opsega kao dio svojih opcija, što olakšava povezivanje svake rute ili usmjerivača s određenim skupom dozvola. Ovaj pristup drži probleme autorizacije blizu definicija ruta, što poboljšava čitljivost i održivost.

S dizajnerske perspektive, općenito je bolje tretirati JWT opsege i tvrdnje kao dio deklarativne politike, nego raspršivati ​​​​tvrdo kodirane nizove po cijelom kodu, kako bi se izbjegle nedosljednosti i olakšale buduće promjene u vašem sigurnosnom modelu.

Testiranje i rješavanje problema s JWT-zaštićenim Node.js API-jima

Nakon što je sve povezano, testirat ćete pozivanje Node.js API-ja sa i bez valjanih JWT-ova kako biste potvrdili da se kontrola pristupa ponaša točno onako kako se očekuje. Jednostavni alati poput curla, HTTPiea ili Postmana savršeni su za to, omogućujući vam jednostavno postavljanje zaglavlja i korisnih podataka.

Tipičan tijek testiranja uključuje prvo pozivanje krajnje točke za prijavu kako bi se dobio token, a zatim slanje drugog zahtjeva zaštićenoj ruti s Authorization: Bearer <token> skup zaglavlja. Ako je vaša implementacija ispravna, autorizirani zahtjevi trebali bi biti uspješni, dok bi pozivi bez tokena ili s nevažećim tokenima trebali biti odbijeni.

Prilikom korištenja Express JWT biblioteke za validaciju integrirane s JWKS krajnjom točkom, svaki problem s tokenom često se signalizira s 401 Unauthorized odgovor i detaljne informacije u WWW-Authenticate zaglavlje odgovora. Na primjer, ako je istekao rok valjanosti pristupnog tokena, to zaglavlje će obično navoditi specifični kod pogreške i opis.

Ove detaljne poruke o pogreškama vrlo su korisne tijekom razvoja i otklanjanja pogrešaka, ali trebali biste paziti da ne otkrijete previše osjetljive interne informacije u produkcijskim zapisnicima ili odgovorima. Često je dobra ideja centralizirati zapisivanje i maskirati ili generalizirati određene poruke, a istovremeno zadržati dovoljno konteksta kako bi operateri mogli dijagnosticirati probleme.

Automatizirani testovi i simulirani JWT-ovi mogu dodatno povećati vaše samopouzdanje, omogućujući vam da provjerite je li ponašanje autorizacije stabilno kada mijenjate rute, dodajete opsege ili refaktorirate logiku middlewarea.

Sve to zajedno, Node.js API koji kombinira Express, MongoDB, bcrypt, Joi i JWT - opcionalno podržan bibliotekom za validaciju temeljenom na JWKS-u - pruža vam robusnu osnovu za osiguranje krajnjih točaka, a istovremeno ostaje dovoljno fleksibilan za integraciju s modernim frontend okvirima, mobilnim aplikacijama i pružateljima identiteta poduzeća.