Selamlar,

https://youtu.be/41DTY1tXIi4

Bu makale, bundan önce yazılan NodeJs&MongoDb ve NodeJs&Swagger makalelerinin devamıdır. Burada amaç, tüm projeye kapsamlı bir security module’ünü adapte etmektir. Gelin işe önce Login ekranını, Angular projeye eklemek ile başlıyalım. Nede olsa güvenlik denince, ilk akla gelen Login ekranıdır :)

Login.html: Aşağıda görüldüğü gibi, [(ngModel)]=”userName” ve [(ngModel)]=”password” değişkenlere atanmıştır. Giriş button’u tıklandığında, “Redirect()” methoduna gidilmektedir. Login.scss dosyasına, sayfanın sonundaki proje url’inden erişilebilir.

Login.ts: LoginComponent ==> AfterViewInit sınıfından inherit olmuştur. Böylece sayfa yüklendiği zaman, ngAfterViewInit() methodu devreye girmektedir.

• “selector: ‘app-root'” : Artık default olarak açılacak sayfa “app.component” yerine “login” sayfasıdır.
• “this.service.checkToken().subscribe((data: any) => {” : Makalenin devamında anlatılacak olan “checkToken” servisine gidilerek, önceden login olunmuş ise Local Storage’da bulunan JWT token, Nodejs servisine gönderilip, geçerli olup olunmadığına bakılır.
• “this.router.navigateByUrl(‘person’)” :  Eğer gönderilen token son 1 saatden önce girilmiş ise, geçerli olur ve yine makalenin devamında anlatılacak olan app-routing.module‘de tanımlı olan “person” keyword’üne karşılık gelen “AppComponent” sayfasına yönlenilir. Kısaca, sayfa ilk yüklendiğinde 1 saat içinde Login olunmuş ise AppComponent sayfasına yönlenilir. Değil ise, Login sayfasında kalınılır.
• Redirect() : Login button’una basılmış ise, “this.service.login” servisine Username ve password parametre olarak gönderilir.
  • “window.localStorage.setItem(“token”, data.token)” :Username ve Password doğru ise, NodeJs’den dönen “token” LocakStorage’a yazılır.
  • “this.router.navigateByUrl(‘person’)” : Daha sonra da AppComponent sayfasına yönlenilir.

Gelin isterseniz servisden önce, Angular üzerinde routing nasıl yapılıyor onu inceleyelim.

app-routing.module.ts: İlgili sayfa projeye eklenir. Aşağıda görüldüğü gibi pathler ‘ ‘ ve ‘person’ olarak tanımlanmıştır.

• ‘ ‘=> LoginComponent sayfasını yani ilk açılış sayfasını tanımlamaktadır.
•  ‘person’=> ise, AppComponent sayfasını tanımlamaktadır.

Not: Routing amaçlı yeni eklenen app-routing.module sayfasının ayrıca login amaçlı Login ve layout amaçlı Main sayfalarının, app.module.ts‘e aşağıdaki gibi eklenmesi gerekmektedir.

app.module.ts:

Angular Routing Ağacı:

1-) İlk açılan sayfa Index.html: “<app-root></app-root>” body tagları arasında tanımlanan component’dır.

2- ) Yeni eklenen Main.ts sayfasının “selector”‘ü “app-root”‘dır. Tüm sayfaların içinde açılacağı ana bir sayfanın olması gerekmektedir.

3-) Main.html: Yeni sayfanın, yönlendirme sayfası olduğunu eskilerin tabiri ile Main Layout :) olduğunu “router-outlet” tanımlaması ile belirtilir. Tüm açılan sayfalar, bu sayfa içinde açılır. “Login” ve “app.component” sayfaları gibi..

4-) app-routing.module.ts‘de, Url’de hiçbir tanımlama yapılmaz ise kısaca path ‘ ‘ olur ise, Login sayfasına yönlenilir. Yani main.html içinde root page olarak, Login.html sayfası açılır.

Şimdi sıra geldi personSerivce.

Service/personService.ts: Sadece yeni eklenen functionlar, aşağıda tanımlanmıştır.

• login(): NodeJs tarafında login() methoduna, username ve encrypt‘li password parametreleri body içerisinde post edilir. Password’ün şifrelenmesi için, aşağıda tanımlanan el yapımı :) “Encrypt()” methodu kullanılmıştır. Amaç, güvenlik amacı ile giden network trafiğinde şifrenin gözükmemesidir. NodeJs tarafında bu methodun bir karşılığı olan, Decrypt() methodu kullanılmaktadır. Yukarıdaki resimde, post edilen dataya bakıldığında görülen password, şifreli olduğundan dolayı gerçeği ile bir alakası yoktur :)

• checkToken() : Login sayfasına gelinildiğinde, “ngAfterViewInit()” methodunda yani sayfa yüklenmesi bittiği zaman, ilgili method çağrılarak LocalStorage’da var olan token “GetToken()” methodu ile alınıp, header’a başına “Bearer ” konmak sureti ile yukarıda görüldüğü gibi NodeJs’e post edilir. Eğer “true” değeri dönülür ise, Login sayfasından AppComponent sayfasına yönlenilir. Eğer false dönülür ise login sayfasında kalınır.
• GetToken() : Bu method ile, eğer localStorage’da “token” değeri var ise alınıp geri dönülür.

Örnek Service/personService.ts(getPeopleList): Son olarak personService’inde yazılan tüm methodların Header’ına, aynı checkToken() methodunda olduğu gibi, güvenlik amaçlı “‘Authorization’: ‘Bearer ‘ + this.GetToken()” konulması gerekmektedir. Bu şekilde makalenin devamında NodeJs tarafında inceleyeceğimiz, “JWT Token” kontrolünden geçinilmiş olunur. Bu token konmasa idi, ilgili servis Url’ine erişen herkes, ilgili dataları kolayca çekebilirdi. İlgili Token’ın manuel olarak ayarlanan expire süresi, 1 saattir. Bu makalede localStorage tarafından bir expire time yazılmamıştır. Expire işlemi, NodeJs tarafında JWT Token alınır iken yapılmıştır. Eğer süresi geçmiş bir token, localStorage’dan alınıp header’da post edilir ise herhangi bir sonuç alınamıyacaktır.

Sıra geldi AppComponent sayfasında yapılan değişikliklere.

app.component.ts/getPeople(): Aşağıda görüldüğü gibi sayfa ilk yüklendiğinde “ngAfterViewInit()” methodunda, “getPeople()” methodu çağrılır. ==>”data.success” değeri kontrol edilir. Sadece Token hatası durumunda, data.success değeri “false” olarak NodeJs’den dönülür. Bu durumda Login sayfasına yönlendirilir.

• “this.router.navigateByUrl(”)” : Hata durumunda Login sayfasına yönlenilir. ‘ ‘ anlamı, “app-routing.module” sayfasına bakılır ise ==> “{ path: ‘ ‘ ”, component: LoginComponent, pathMatch: ‘full’ }” yani, root sayfanın Login sayfası olduğu görülür.
• “constructor(public service:PersonService, private router:Router) { }” : Routing işlemini yapılabilmesi için Router’ın constructor’da eklenmesi gerekmektedir.
• “import { Router } from ‘@angular/router'” : Sayfanın başına, ilgili Router kütüphanesinin eklenmesi gerekmektedir.

• Next(), Preview(), Save(), Delete() methodlarının tamamında, NodeJs servisine gidildikten sonra eğer “data.success == false” hatası alınır ise ==> “this.router.navigateByUrl(”)” login sayfasına yönlenilir. Aşağıda örnek amaçlı sadece Next() methodu gösterilmiştir. Tüm methodlarda, aynı işlemin yapılması gerekmektedir. Amaç eğer gidilip LocalStorage’dan token silinir ise, ya da Token’ın 1 saatlik süresi geçer ise tekrar login olunmasıdır.

Şimdi sıra geldi Backend NodeJs tarafına.

Image Source: https://t1.daumcdn.net/cfile/tistory/99A2204B5C983E070A

Amaç: Esas amaç veri güvenliğinin sağlanmasıdır. Sadece Login sayfası olan, o kadar çok proje gördüm ki beni hayrete düşürdü. Esas güvenliğin, Client ile erişilen servisler arasında olması gerekmektedir. Aksi takdirde, servis yollarına erişen art niyetli kişiler, datayı elegeçriebilir, silebilir ya da bozabilir.

1. Client taraftan servise, username – password gönderilir. Doğru ise, geriye belli bir zaman geçerli olan yeni bir token oluşturulup dönülür.
2. Nodejs tarafında gönderilen password, hashlenerek MongoDB tarafında saklanır. Doğru olup olmadığı, belli bir key’e göre gene hashlenip 2 encrypted şifre karşılaştırılarak belirlenir. Burada amaç clientların passwordlerinin MongoDB’de görülmemesidir.
3. Client, makalenin başında gördüğümüz gibi kendisine gelen bu token’ı, localStorage veya Cookiede saklar.
4. Artık clientside’dan webservisine bir istekte bulunulacağı zaman, “Authorization Header“‘a kendisine gelen bu token’ın konulması gerekmektedir. Süresi geçmiş, yanlış ya da token’sız tüm istekler, “Token is not valid” hata mesajı ile karşılaşır.
5. Eğer Nodejs tarafında istekler, en başta token kontrolünden başarılı olarak geçer ise, istenen data Client’a geri dönülür.

Bu makalede token üretimi ve kontrolü için JWT kütüphanesi kullanılmıştır.

Yukarıdaki komut ile, jwt kütüphanesi projeye eklenir. Projenin başına “jsonwebtoken” ve gelen password’ü hashlenmesi için “crypto” kütüphaneleri, sayfanın başına aşağıdaki gibi eklenir. crypto kütüphanesi, NodeJs ile default gelen bir kütüphanedir. Ayrıca yüklenmesine gerek yoktur. Son olarak config.js dosyasından, ilgili key’e göre value’nun okunabilmesi için, “config” kütüphanesinin aşağıdaki gibi tanımlanması gerekmektedir. Config.json dosyası, makalenin devamında anlatılacaktır.

MongoDB tarafında yukarıda propertyleri gözüken client collection’ının mongoose şeması, aşağıdaki gibi tanımlanmıştır. Client değişkenine, ilgili döküman, aşağıdaki şeme ile atanır.

Image Source: https://fullstackmark.com/img/posts/19/jwt-flow-using-authentication-server-with-access-token-and-resource-server.png

Sıra geldi NodeJs tarafında Login methoduna:

service.js/login: İlgili kişi doğru username ve password’ü girdi mi diye kontrol edilir. Doğru ise, geriye yeni oluşturulan JWT token dönülür.

• “var password = Decrypt(req.body.password)” : Encrypt’li gönderilen password, makalenin devamında anlatılacak olan Decrypt() function ile çözülür. Amaç, client side tarafdan gönderilen password’ün NodeJs’e gelene kadar okunamamasıdır.
• “this.salt = config.salt” : Password’un hashlene bilmesi için gerekli salt key, config dosyasından okunur.
• “this.hash = crypto.pbkdf2Sync(password, this.salt, 1000, 64, ‘sha512’).toString(‘hex’)” : Gönderilen password, decrypt edildikten sonra mongodb’den kontrol edilebilmesi için hashlenir. Çünkü password mongoDB’de güvenlik amaçlı hash’li olarak tutulmaktadır. Hashleme hakkında daha detaylı bilgiye, bu makaleden erişebilirsiniz.
• “var query = { username: req.body.username, password: this.hash }” : Body içerisinde gönderilen username ve password’ün, mongoDB’de aranması amacı ile query oluşturulur.
• “Client.find(query, function (err, doc) {” : Username ve hash’li password’ün, mongodb’de bir karşılığı olup olmadığına bakılır.
• “if (doc.length > 0) {” : Geçerli bir kaydın bulunması durumunda işlemlere devam edilir.
• “let token = jwt.sign({ username: req.body.username }, config.secret, { expiresIn: ‘1h’ // expires in 1 hour } )” : Login olan kişinin username’ine karşılık, JWT kütüphanesi yardımı ile 1 saatlik token oluşturulur.
  • “config.secret” : JWT için gerekli secret key config.js dosyasından okunur.
  • “expiresIn: ‘1h'” : 1 saat sonra, ilgili token’ın geçersiz olamsı sağlanır.
• “return res.status(200).json({ status: “succesfully login”, token: token, success: true })” : Geriye 200 kodu ve oluşturulan token dönülür.
• “return res.status(401).send(“Username or Password Wrong!”)” : Username veya şifrenin yanlış olması durumunda, 401 hata kodu dönülür.

service.js/Decrypt(): Client Side tarafta, güvenlik amaçlı şifrelenerek gönderilen password, server side tarafta kontrol edilmek amacı ile decrypt edilir.

config.js: Config.js’in kullanılabilmesi için, aşağıdaki komut ile proje eklenmesi gerekmektedir.

• npm i config

  1	npm i config

• salt, gönderilen password’ün hashlenmesi için kullanılır.
• secret ise, Jwt kütüphanesinde ilgili username için oluşturulacak token için kullanılır.

Şimdi sıra geldi service methodları üzerine bir istek geldiği zaman, header’dan gönderilen token’ın kontrol edilmesine.

token.js: Servislerin güvenliği tek bir yerden yönetilmelidir. Bunun için aşağıdaki token.js yazılmıştır.

• let jwt = require(‘jsonwebtoken’)” : JWT Token kütüphanesi kullanılmaktadır.
• “const config = require(‘./config.js’)” : config.js dosyasından, istenen keylerin okunması için kullanılır.
• “let token = req.headers[‘x-access-token’] || req.headers[‘authorization’]” : Gelen requestin Header’ında, “authorization” key var mı diye bakılır? Kısaca token header’a konmuş mu diye kontrol edilir.
• “if (token !=undefined && token.startsWith(‘Bearer ‘)) {” : Gelen Token’ın “Bearer” kelimesi ile başlaması gerekmektedir. Varsa, “Bearer” kelimesi kaldırılıp, sadece token alınır.
• “jwt.verify(token, config.secret, (err, decoded) => {” : JWT kütüphanesi kullanılarak, gelen token’ın config dosyasındaki secret keyi ile decod edilip geçerli olup olunmadığına bakılır :)
• “return res.json({ success: false, message: ‘Token is not valid’ })” : Geçerli değil ise “success: false” ve mesaj olarak da “Token is not valid” mesajı dönülür.Bu cevap dönüldüğünde, client side tarafında Login ekranına yönlenilir.
• “req.decoded = decoded; next()” : Geçerli ise “next()“, NodeJs kütüphanesine özel bir methoddur ve kendi üzerinde çağrılan servisin çalıştırılmasını sağlanır. Not: Bu token.js, tüm servis istekleri üzerinde çalıştırılacaktır. Dolayısı ile next() methodu, hangi servis üzerinde çalıştırılır ise o servis çağrılacaktır.
• “return res.json({ success: false, message: ‘Auth token is not supplied’ })” : Header üzerinde token bulunmaması durumunda,  “success: false” ve mesaj olarak da “Auth token is not supplied” mesajı dönülür. Bu cevap dönüldüğünde, client side tarafında Login ekranına yönlenilir.

Şimdi sıra geldi, service.js üzerinde tüm functionlara bu token.js’i, implemente etmeye. Sayfanın başına, aşağıdaki şekilde token.json dosyası tanımlanır.

Aşağıda tüm servis methodlarından sadece 2 tanesi için örnek verilmiştir. Geri kalan tüm methodlarda, token kontrolü aynı şekilde yapılmaktadır.

“app.get(“/people”, token, function (req, res) {” : Yeni eklenen tek parametre “token“‘dır. Burada, ilgili function’a gelinildiğinde ilk olarak token.json sayfasına gidilir ve hemen yukarıda anlatılan “module.exports = (req, res, next) =>” function’ı çalıştırılır. Dönen sonuca göre yani Header’da gönderilen token’ın geçerli olması durumunda, yukarıda anlatılan “Next()” methodu çağrılarak, ilgili app.get() method’u çalıştırılır. Ya da token’ın geçersiz olması durumunda, geriye “return res.json({ success: false, message: ‘Token is not valid’ })” satırı dönülür ve client side tarafda “Login” sayfasına yönlenilir.

Aynı işlem “app.post(‘/insertPeople’, token, async (req, res) => {” function’ı için de geçerlidir. Header’da gönderilen token geçersiz ise insert işlemi yapılmaz ve Login ekranına dönülür.Token geçerli ise, yeni client mongoDB’deki users document’ine kaydedilir. Yukarıdaki örnekde, test amaçlı var olan token bozulmuştur. Böylece Header ile gönderilen token, NodeJs tarafında insertPeople() methodu çalıştırılmadan önce token.js tarafından karşılanmış ve token invalid olduğu için “return res.json({ success: false, message: ‘Token is not valid’ })” değeri dönülmüştür. Bu cevabı alan client side da, user’ın geçerli bir token alması için Login sayfasına yönlendirmiştir.

Swagger Token Entegrasyonu: Güvenlik amaçlı Header’a eklenen “Authorization: Bearer Token“‘ın, Swagger dökümanı tarafında da, bir karşılığı olması gerekir. Aksi takdirde, test amaçlı çalıştırılan methodlar token.js‘den geçemezler ve ‘Auth token is not supplied‘ hatasını alırlar. Öncelikle uygulamaya Login olunduktan sonra, browser’daki Local Storage’dan token alınarak, yukarıdaki Value kutucuğuna yazılır.

     1.  Bunun olmaması için, swagger.json dosyasının başına aşağıdaki “securityDefinitions” sekmesinin eklenmesi gerekmektedir.

swagger.json:

2.  Her bir method’a, “security”: [ { “Bearer”: [] } ]” sekmesinin eklenmesi gerekmektedir. Aşağıda örnek amaçlı eklenen “people()” methodu görülmektedir. Diğer methodlara da, aynı şekilde “security” sekmesinin eklenmesi gerekmektedir.

Refresh Token

Öncelikle gelin Refresh Token nedir onu inceleyelim. Örnek amaçlı bir senerya belirleyelim. Ali ilgili form üzerinde 1 saatten fazla çalışması durumunda, Token’ın süresi biteceğinden NodeJs’e yapılan ilk istekte, Ali Login sayfasına yönlenecektir. İşte bu durumun olmaması için, kesin bir kural olamasa da bu örnekde, süresi “45< T <60” dakikaları arasında olan tokenların yenilenmesi gerekmektedir. Bunun için Client Side taraftan NodeJs’e, Login olunulduğu zama, “Token“‘ın haricinde yine Login zamanı alınacak olan “Refresh Token“‘ın Header üzerinden gönderilmesi gerekmektedir. Bu, NodeJs tarafında yakalanıldığı zaman, güvenlik amaçlı Token’ın yaşı JWT kütüphanesi yardımı ile tekrardan kontrol edilir ve gerçekten 45 – 60 dakikaları arasında ise, ayrıca gönderilen “Token” ile “Refresh Token” geçerli ise yeni “Token” ve “Refresh Token” oluşturularak geri dönülür. Böylece yeni 1 saatlik token, Ali için kullanıma hazır olur. Sonuç olarak sürekli çalışan Login olmuş bir client’ın, tekrardan Login sayfasına düşmesi engellenir. Ancak T<60 durumunda, yani hiçbir işlem yapılmadan Token’ın expire süresi geçer ise, Login sayfasına yönlenilir.

NodeJs/service.js/Login : Öncelikle gelin, NodeJs tarafında Login() methodunu Refresh Token için güncelleyelim.

Login olunulması durumunda, ilgili user için  token üretilmesi yanında, bir de Refresh Token oluşturulmakta ve geri dönülmektedir. Normal Token’ın süresi 1 saat iken, Refresh Token’ın süresi 2 saattir. Biraz daha uzun olmasının tek nedeni güvenliktir. Sonuçta Refresh Token, var olan Token’ın yenilenmesi için kullanılan 2.cil bir anahtardır. Bundan dolayı expire süresinin, Token’ın süresinden biraz daha fazla olması gayet normaldir.

Şimdi sıra geldi ,ClientSide tarafta bu servisi karşılayan Redirect() function’a.

app/login.ts/Redirect(): Aşağıda görüldüğü gibi login işlemi başarı ile sağlandıktan sonra, token ve refreshToken Local Storage’a kaydedilir. Ayrıca oluşturma tarihi olan CreateDate de, LocalStorage’a kaydedilir.

Şimdi sıra geldi her bir request işleminden, önce token süresini client side tarafta kontrol etmeye.

Service/personService.ts/checkTokenTime(): Burada amaç, kaydedilen token süresi ile şimdiki zaman arasında 45 dakikalık farkın olup olmadığına bakınılmasıdır.

Service/personService.ts/getPeopleList(): İlgili functionlardan, örnek amaçlı getPeopleList() seçilmiştir. Tüm functionlar için aynı işlemin yapılması gerekir. Refresh Token için yapılan değişiklikler, aşağıda maddeler halinde sıralanmıştır. Esas amaç eğer Token’ın süresi 45 dakikayı geçmiş ise, yenilenmesi amacı ile NodeJs tarafına, Header’da RefreshToken’ın gönderilmesidir.

• var refreshToken = (window.localStorage.getItem(“refreshToken”) != null && this.checkTokenTime()) ? window.localStorage.getItem(“refreshToken”) : “” : İlgili refresToken LocalStorage’da var ise ve checkTokenTime() functionından true değeri dönmüş ise yani Token süresi 45 dakikayı geçmiş, ise işleme devam edilir. Ve LocalStoragedaki refreshToken değeri atanır. Değil ise, ” “ yani boş değeri atanır.
• let httpOptions = { headers: new HttpHeaders({ .., ‘RefreshToken’: refreshToken, }), observe: ‘response’ as ‘body’,}: Get işlemi yapılacak servisin header’ına RefreshToken eklenir.

Buradaki en önemli konu httpOptions’a observe: ‘response’ as ‘body’ tagının eklenmesidir. Bu eklenmez ise, geriye dönüş tipi olarak HttpResponse alınamaz. Bu da makalenin devamında anlatılacak olan, gelen cevabın Header’ından yeni Token ve RefreshToken‘ın alınamamasına neden olacaktır. Bu soruna çözümü, gerçekten uzun bir süre aradım :) Özellikle “as ‘body’” kısmını.

• “return this.httpClient.get<any>(url, httpOptions)” : Dönüş tipi httpClient.get<Person>’dan httpClient.get<any>’e çevrilmiştir. Çünkü dönen değer artık bir HttpResponse’dur.
• “map(response => {” : İle araya girilmiş ve gelen kaydın header’ından, datalar çekilmiştir.
  • “var token = response.headers.get(‘token’);var refreshToken = response.headers.get(‘refreshToken’)” : Yeni oluşturulan Token ve RefreshToken, header’dan çekilir.
  • “if (token && refreshToken) {” : Gerçekten yeni tokenların oluşup oluşmadığına bakılır. Çünkü gönderilen refreshToken’ın geçerli olup olmadığı ve Token süresinin 45> dakikadan büyük olup olmadığı, NodeJs tarafında da kontrol edilmektedir. Bu koşullar sağlanmıyor, ise yeni Token ve RefreshToken dönülmez.
  • “window.localStorage.setItem(“token”, token)”; window.localStorage.setItem(“refreshToken”, refreshToken); window.localStorage.setItem(“createdDate”, new Date().toString()) : Yeni oluşturulmuş Token, RefreshToken ve oluşturulma zamanı olan CreatedDate, LocalStorage’da güncellenir.
• “return response.body”: Servis sonucunu bekleyen functionlarda herhangi bir değişikliğe gidilmemesi için, geriye onaların beklediği HttpResponse’un body’sinde taşınan ==> Person[] dönülür.

Şimdi sıra geldi NodeJs tarafında, tüm servislerde middleware’e girerek token kontrolü yapan token.js’e.

NodeJs/token.js : RefreshToken için yapılan değişiklikler kısaca, client’a ait token’in süresinin 45 dakikadan büyük olup olmadığının araştırılması, büyük olması durumunda client’dan gelen refreshTone’ın geçerlilik durumuna bakılıp, yeni refreshToken ve Token’ın yaratılıp, headar’da geri dönülmesidir.

• “var exp = new Date(decoded.exp * 1000)” : Token’ın expire olacağı zaman, JWT kütüphanesi üzerinden alınır.
• “var now = new Date(); var difference = exp.getTime() – now.getTime()” : Şimdiki zaman ve token’ın süresini hesaplamak için, aradaki fark alınır.
• “var resultInMinutes = Math.round(difference / 60000)” : Token’ın süresi, dakika cinsinden resultMinutes’e atanır.
• “if (resultInMinutes < 15) {” : Token’ın expire süresi 15 dakikadan küçük ise, işleme devam edilir.
• “var refreshToken = req.headers[‘refreshtoken’]” : Client side tarafdan gönderilen refresh token, header’dan alınır.
• “if (refreshToken && refreshToken!=”” && refreshToken != “undefined” && refreshToken != undefined) {” : Eğer refreshToken var ise işleme devam edilir.
• “jwt.verify(refreshToken, config.secret, (err, decoded) => {” : Gönderilen refresh token, doğrulanır.
• “var newToken = jwt.sign({ username: decoded.username }” : Yeni bir token oluşturulur.
• “var newRefreshToken = jwt.sign({ username: decoded.username }” : Aynı user için yeni bir refreshToken oluşturulur.
• “res.setHeader(‘Token’, newToken); res.setHeader(‘RefreshToken’, newRefreshToken)” : Var olan yapının bozulmaması adına, token.js’in üzerinde çalıştığı servislerin dönüş tipinin değiştirilmemesi için, en kısa ve en elverişli yol olarak, yaratılan yeni Token’ların HttpResponse.header‘da, ilgili client’a gönderilmesidir. Uzun yol olarak, tüm servilerin geri dönüş tipleri bir base model’den türetilip, bu base modelin propertylerine ilgili token ve refreshTokenlar property olarak atanabilirdi. Ama en iyi ol en kısa olandır. Hem hata riskini azaltır, hem de testi kolaylaştırır.

Not: JWT Token’da, delete ya da remove gibi işlemler yoktur. Yani Logout olma durumunda, user’a ait kayıtlı Token JWT’den silinemez. Ancak Expire olmasının beklenmesi gerekmektedir. Bizim bu örneğimizde de aslında, request çeken client’a geçerli 2 token verilmektedir. Dikkat edilmesi gerekene konu 45<T<60 dakikaları arasında ilgili client’a ait, aslında 4 token bulunmasıdır. Çünkü diğerleri henüz expire olmamıştır. 60. dakikadan sonra eski Token, 120. dakikadan sonra da eski RefreshToken expire olacaktır. Ben JWT Token’ın bu özelliğini, hiç beğenmedim. Çözüm olarak, Logout durumunda LocalStorage’ın temizlenmesi gerektiği söylense de, eski token’ı alan kişi, o token Expire olana kadar, ilgili servisden request çekmeye devam edebilecektir. Bu da bence önemli bir güvenlik açığıdır.

* NodeJs/ service.js: Karşılaştığım bir diğer zorluk, NodeJs’den Client Side’a Header’da istenen propertylerin taşınamaması idi. NodeJs’den gönderilen Token ve RefreshToken, Service/personService.ts‘de HttpRespone.Header’dan ==> “response.headers.get(‘refreshToken’)”‘dan alınamıyordu. Bunun çözümü için, aşağıda görüldüğü gibi NodeJs tarafında cors kütüphanesine, Header’da taşınacak propertylere ayrıca izin verilmesi gerekmektedir. Bunu gerçekten çok üzün süre aradım :)

Geldik bir makalenin daha sonuna. Bu makalede Angular 8, NodeJs ve MongoDB bir projede, sıfırdan Authenticationın nasıl yapılacağı incelenmiştir. Login sayfasının yaratılması, Login sayfasından password gibi kritik verilerin nasıl şifreli gönderilebileceği, Client Side taraftan – Server Side tarafındaki servislere Token ile nasıl erişilebileceği, Token’ın süresinin bitmesine yakın nasıl Refresh Token ile yenilenebileceği ve son olarak ilgili passwordlerin MongoDB’de nasıl Hashli olarak saklanabileceği detaylıca anlatılan konulardandır. Bunun yanında, Angular 8 tarafında routing, NodeJs tarafından dönen datanın RXJS kütüphaneleri kullanılarak, header’dan okunması ve kritik verilerin nasıl şifreleneceği konularına detaylıca değenilmiştir. Bütün bu işlemlerin yanında, var olan kodu değiştirmeden en az test ve refactoring işlemi ile Authentication ve security’nin, projeye implementasyonu, dikkat edilen en önemli unsurlardan biri olmuştur.

Yeni bir makalede görüşmek üzere hepinizi hoşçakalın.

Source Code : https://github.com/borakasmer/NodeJs-Angular8-Security-Authentication

Kaynaklar :

• https://jwt.io/introduction/
• https://medium.com/dev-bits/a-guide-for-adding-jwt-token-based-authentication-to-your-single-page-nodejs-applications-c403f7cf04f4
• https://www.freecodecamp.org/news/securing-node-js-restful-apis-with-json-web-tokens-9f811a92bb52/
• http://www.borakasmer.com/manuel-tokenization-ile-authentication-webservisleri-guvenligi-ve-otomatik-yenileme-part-1/
• https://fullstackmark.com/post/19/jwt-authentication-flow-with-refresh-tokens-in-aspnet-core-web-api