Next.js JWT Kimlik Doğrulama: 2026’da Uygulamanızı Güvenceye Almak İçin Kapsamlı Bir Rehber
Modern web uygulamaları geliştirmenin vazgeçilmez aracı Next.js, sunduğu performans ve geliştirici deneyimiyle öne çıkarken, kullanıcı güvenliğini sağlamak da en kritik önceliklerden biridir. 2026 yılına doğru ilerlerken, güvenlik standartları ve tehdit vektörleri sürekli evrilmekte. Bu kapsamlı rehberde, Next.js uygulamalarınızı JSON Web Token (JWT) kullanarak nasıl güvenli bir şekilde kimlik doğrulayacağınızı, en güncel mimari yaklaşımları ve en iyi güvenlik uygulamalarını ele alacağız. Amacımız, uygulamanızın sadece işlevsel değil, aynı zamanda geleceğin güvenlik gereksinimlerine uygun olmasını sağlamaktır.
Neden Next.js ve JWT Kimlik Doğrulama?
Next.js’in popülaritesi ve JWT’nin modern kimlik doğrulama çözümlerindeki yeri, bu ikilinin neden ideal bir kombinasyon olduğunu anlamakla başlar. Her iki teknoloji de web geliştirmenin geleceğini şekillendiren önemli bileşenlerdir.
Next.js’in Modern Web Geliştirmedeki Yeri
Next.js, React tabanlı uygulamalar için geliştirilmiş bir framework olup, sunucu tarafı renderlama (SSR), statik site oluşturma (SSG) ve yeni App Router ile birlikte gelen sunucu bileşenleri (Server Components) gibi özellikleriyle performans, SEO ve geliştirici verimliliğini önemli ölçüde artırır. Bu özellikler, dinamik ve etkileşimli uygulamalar geliştirmek için güçlü bir temel sunar. 2026’da, Next.js’in sunduğu hibrit renderlama yetenekleri, hem hızlı yüklenen hem de dinamik içeriğe sahip uygulamalar için standart haline gelmeye devam edecektir.
JWT Nedir ve Neden Tercih Edilir?
JSON Web Token (JWT), taraflar arasında güvenli bir şekilde bilgi iletmek için kullanılan, kompakt ve URL güvenli bir token formatıdır. Özellikle API tabanlı uygulamalarda ve mikroservis mimarilerinde popülerdir çünkü durumsuz (stateless) yapısı sayesinde sunucunun her istekte oturum bilgisi tutmasına gerek kalmaz. Bu, sunucu yükünü azaltır ve uygulamaların yatayda ölçeklenmesini kolaylaştırır. JWT’ler, bir kullanıcının kimliğini doğruladıktan sonra istemciye verilen ve sonraki tüm isteklerde bu kimliği kanıtlamak için kullanılan şifreli anahtarlar gibidir.
Geleneksel Oturum Yönetimi vs. JWT
Geleneksel oturum yönetimi, sunucu tarafında oturum kimlikleri (session IDs) tutarak çalışır. Kullanıcı giriş yaptığında, sunucu bir oturum oluşturur ve bu oturum kimliğini bir çerez (cookie) aracılığıyla istemciye gönderir. Her istekte istemci bu çerezi gönderir ve sunucu oturum kimliğini doğrulayarak kullanıcının yetkisini kontrol eder. JWT ise durumsuz bir yaklaşımdır; sunucu, token’ı doğrulayarak kullanıcının kimliğini anlar ve herhangi bir oturum verisini sunucu tarafında saklamaz. Bu durumsuz yapı, özellikle dağıtık sistemlerde ve API ağ geçitlerinde büyük avantaj sağlar.
2026 ve Gelecekteki Güvenlik Trendleri
2026’ya doğru, siber güvenlik tehditleri daha sofistike hale gelecek. Bu durum, kimlik doğrulama mekanizmalarımızın daha sağlam olmasını gerektiriyor. JWT, doğru uygulandığında güçlü bir güvenlik katmanı sunar. Özellikle, kısa ömürlü erişim token’ları (access tokens) ve uzun ömürlü yenileme token’ları (refresh tokens) kombinasyonu, çalınan token’ların kötüye kullanım riskini minimize eder. Ayrıca, sunucu bileşenlerinin (Server Components) kullanımı, hassas verilerin istemciye gönderilmeden sunucuda işlenmesine olanak tanıyarak yeni güvenlik paradigmaları sunmaktadır.
JWT Kimlik Doğrulama Temelleri
JWT’nin nasıl çalıştığını ve temel bileşenlerini anlamak, güvenli bir uygulama geliştirmek için kritik öneme sahiptir. Yapısı, kullanım mekanizmaları ve potansiyel güvenlik açıkları bu bölümde ele alınacaktır.
JWT Yapısı: Header, Payload, Signature
Bir JWT üç ana bölümden oluşur ve noktalarla ayrılır: header.payload.signature.
* Header (Başlık): Token’ın türünü (örneğin, JWT) ve kullanılan imzalama algoritmasını (örneğin, HS256 veya RS256) belirtir. Base64url ile kodlanmıştır.
* Payload (Yük): Token’ın iddialarını (claims) içerir. Bu iddialar, kullanıcı hakkında bilgiler (örneğin, kullanıcı ID’si, rolü) ve token’ın son kullanma tarihi gibi meta veriler olabilir. Base64url ile kodlanmıştır.
* Signature (İmza): Header ve Payload’ın kodlanmış halleri ile sunucu tarafında tutulan gizli bir anahtar kullanılarak oluşturulur. Bu imza, token’ın bütünlüğünü ve kimliğini doğrulamak için kullanılır; yani token’ın yol boyunca değiştirilmediğini garanti eder.
// Örnek JWT Payload
{
"sub": "1234567890",
"name": "Kullanıcı Adı",
"admin": true,
"iat": 1516239022, // Issued At
"exp": 1516242622 // Expiration Time
}Access Token ve Refresh Token Mekanizması
Güvenli bir JWT uygulaması genellikle iki tür token kullanır:
1. Access Token (Erişim Token'ı): Kısa ömürlüdür (genellikle 15 dakika - 1 saat). Kullanıcının korunan kaynaklara erişimini sağlar. Her API isteğiyle birlikte gönderilir. Kısa ömürlü olması, çalınması durumunda kötüye kullanım süresini sınırlar.
2. Refresh Token (Yenileme Token'ı): Uzun ömürlüdür (genellikle günler, haftalar veya aylar). Access token süresi dolduğunda yeni bir access token almak için kullanılır. Refresh token'lar genellikle HttpOnly ve Secure çerezlerde saklanır ve daha sıkı güvenlik önlemleriyle korunur.
Bu ayrım, hem kullanıcı deneyimini kesintiye uğratmadan sürekli erişim sağlamayı hem de güvenlik risklerini minimize etmeyi amaçlar.
Güvenlik Açıkları ve En İyi Uygulamalar (XSS, CSRF, Depolama)
JWT kullanırken dikkat edilmesi gereken bazı önemli güvenlik açıkları ve bunlara karşı alınacak önlemler şunlardır:
* XSS (Cross-Site Scripting): Kötü niyetli komut dosyalarının kullanıcı tarayıcısında çalıştırılmasıyla token'ların çalınması riskini taşır. Access token'ları localStorage yerine HttpOnly çerezlerde saklamak bu riski büyük ölçüde azaltır.
* CSRF (Cross-Site Request Forgery): Saldırganların kullanıcı adına istenmeyen eylemler gerçekleştirmesine neden olabilir. CSRF koruması için SameSite=Lax veya SameSite=Strict çerez öznitelikleri kullanmak ve/veya özel bir CSRF token'ı uygulamak önemlidir.
* Token Depolama: Access token'ları localStorage veya sessionStorage'da saklamak XSS saldırılarına karşı savunmasızdır. HttpOnly ve Secure çerezler, bu tür token'lar için daha güvenli bir depolama yöntemidir. Refresh token'lar kesinlikle bu şekilde saklanmalıdır.
Next.js Mimarisi ve JWT Entegrasyonu
Next.js'in benzersiz mimarisi, JWT kimlik doğrulamasını entegre ederken bazı özel yaklaşımlar gerektirir. Özellikle App Router, Server Components ve Middleware, bu süreçte önemli rol oynar.
Next.js API Routes ile Backend Entegrasyonu
Next.js'in API Routes özelliği, uygulamanızın aynı proje içinde bir backend API'si oluşturmasına olanak tanır. Bu, kimlik doğrulama işlemlerini (kullanıcı girişi, token yenileme, kullanıcı kaydı) yönetmek için ideal bir yerdir.
// pages/api/login.js veya app/api/login/route.js (App Router)
import jwt from 'jsonwebtoken';
import { serialize } from 'cookie';
export default async function handler(req, res) {
if (req.method !== 'POST') {
return res.status(405).json({ message: 'Method Not Allowed' });
}
const { username, password } = req.body;
// Kullanıcı doğrulama (örneğin, veritabanından)
if (username === 'test' && password === 'password') {
const accessToken = jwt.sign({ userId: 1, role: 'admin' }, process.env.JWT_SECRET, { expiresIn: '15m' });
const refreshToken = jwt.sign({ userId: 1 }, process.env.REFRESH_TOKEN_SECRET, { expiresIn: '7d' });
// Refresh token'ı HttpOnly çereze ayarla
res.setHeader('Set-Cookie', serialize('refreshToken', refreshToken, {
httpOnly: true,
secure: process.env.NODE_ENV !== 'development', // HTTPS'te Secure olmalı
sameSite: 'Lax',
path: '/',
maxAge: 60 * 60 * 24 * 7 // 7 gün
}));
return res.status(200).json({ accessToken });
} else {
return res.status(401).json({ message: 'Invalid credentials' });
}
}Server Components ve Client Components'ta Kimlik Doğrulama
Next.js 13+ ile gelen App Router ve Server Components, kimlik doğrulama mantığını farklı şekillerde ele almamızı sağlar:
* Server Components: Hassas verileri doğrudan sunucuda işleyebilir ve istemciye asla göndermeyebilir. Örneğin, bir kullanıcının yetkili olup olmadığını sunucuda kontrol edip, buna göre UI'ı render edebilirsiniz. Bu, XSS riskini azaltır.
* Client Components: Kullanıcı etkileşimi gerektiren kısımlar (giriş formu, çıkış butonu) için kullanılır. Access token'ın istemci tarafında yönetilmesi gerekiyorsa (örneğin, API isteklerinin Authorization başlığına eklenmesi), bu bileşenler içinde mantık yürütülebilir. Ancak, token depolama yine güvenli çerezler aracılığıyla yapılmalıdır.
Middleware Kullanımıyla Erişim Kontrolü
Next.js Middleware, bir istek tamamlanmadan önce kod çalıştırmanıza olanak tanır. Bu, kimlik doğrulama kontrolü ve yönlendirme için mükemmel bir yerdir. Kullanıcının bir sayfaya veya API rotasına erişim yetkisinin olup olmadığını kontrol etmek için kullanılabilir.
// middleware.js
import { NextResponse } from 'next/server';
import jwt from 'jsonwebtoken';
export function middleware(request) {
const accessToken = request.headers.get('authorization')?.split(' ')[1];
const refreshToken = request.cookies.get('refreshToken')?.value;
// Public rotalar için bypass
if (request.nextUrl.pathname.startsWith('/login') || request.nextUrl.pathname.startsWith('/register')) {
return NextResponse.next();
}
// Access token kontrolü
if (accessToken) {
try {
jwt.verify(accessToken, process.env.JWT_SECRET);
return NextResponse.next();
} catch (error) {
// Access token geçersiz veya süresi dolmuş
// Refresh token ile yeni access token almayı dene
if (refreshToken) {
// Yenileme token'ı ile API'ye istek gönder ve yeni access token al
// Bu kısım genellikle bir API rotası üzerinden yapılır
// Örnek: return NextResponse.redirect(new URL('/api/refresh-token', request.url));
// Şimdilik sadece yetkisiz olarak işaretleyelim
}
}
}
// Hiçbir token yok veya geçersiz, login sayfasına yönlendir
return NextResponse.redirect(new URL('/login', request.url));
}
export const config = {
matcher: ['/((?!api|_next/static|_next/image|favicon.ico).*)'], // Belirli yolları koru
};Güvenli Token Depolama Stratejileri
Daha önce belirtildiği gibi, token'ları güvenli bir şekilde saklamak hayati önem taşır:
* Access Token: Genellikle istemci tarafında API isteklerinin Authorization başlığına eklenmek üzere tutulur. Kısa ömürlü olduğu için, memory (bellek) veya geçici sessionStorage gibi yerlerde tutulabilir, ancak en güvenlisi HttpOnly olmayan bir çerezde saklayıp JavaScript ile erişmektir. Eğer HttpOnly çerezde saklanırsa, JavaScript doğrudan erişemez, bu durumda API isteklerini sunucu tarafında (Server Components veya API Routes) proxy'lemek gerekebilir.
* Refresh Token: Kesinlikle HttpOnly, Secure ve SameSite=Lax veya Strict özelliklerine sahip çerezlerde saklanmalıdır. Bu, JavaScript'in token'a doğrudan erişmesini engeller ve XSS saldırılarına karşı koruma sağlar.
Adım Adım Next.js JWT Kimlik Doğrulama Uygulaması
Şimdi, yukarıdaki teorik bilgileri pratik bir uygulama senaryosuna dönüştürelim. Bu bölümde, temel bir Next.js JWT kimlik doğrulama akışını adım adım nasıl uygulayacağınızı göreceksiniz.
Backend Kurulumu (Örnek: Node.js/Express ve jsonwebtoken)
Basit bir Node.js/Express backend'i ile JWT oluşturma ve doğrulama işlemlerini gösterelim.
1. Gerekli Paketler:
npm install express jsonwebtoken cookie-parser dotenv
2. server.js (Basit bir örnek):
// server.js
require('dotenv').config();
const express = require('express');
const jwt = require('jsonwebtoken');
const cookieParser = require('cookie-parser');
const app = express();
app.use(express.json());
app.use(cookieParser());
const JWT_SECRET = process.env.JWT_SECRET || 'supersecretjwtkey';
const REFRESH_TOKEN_SECRET = process.env.REFRESH_TOKEN_SECRET || 'supersecretrefreshkey';
app.post('/api/login', (req, res) => {
const { username, password } = req.body;
if (username === 'test' && password === 'password') {
const accessToken = jwt.sign({ userId: 1, role: 'user' }, JWT_SECRET, { expiresIn: '15m' });
const refreshToken = jwt.sign({ userId: 1 }, REFRESH_TOKEN_SECRET, { expiresIn: '7d' });
res.cookie('refreshToken', refreshToken, {
httpOnly: true,
secure: process.env.NODE_ENV === 'production',
sameSite: 'Lax',
maxAge: 7 * 24 * 60 * 60 * 1000 // 7 gün
});
return res.json({ accessToken });
}
res.status(401).json({ message: 'Invalid credentials' });
});
app.post('/api/refresh', (req, res) => {
const refreshToken = req.cookies.refreshToken;
if (!refreshToken) return res.status(401).json({ message: 'No refresh token' });
jwt.verify(refreshToken, REFRESH_TOKEN_SECRET, (err, user) => {
if (err) return res.status(403).json({ message: 'Invalid refresh token' });
const newAccessToken = jwt.sign({ userId: user.userId, role: user.role }, JWT_SECRET, { expiresIn: '15m' });
res.json({ accessToken: newAccessToken });
});
});
app.get('/api/protected', (req, res) => {
const authHeader = req.headers['authorization'];
const token = authHeader && authHeader.split(' ')[1];
if (!token) return res.sendStatus(401);
jwt.verify(token, JWT_SECRET, (err, user) => {
if (err) return res.sendStatus(403);
res.json({ message: Welcome ${user.userId}, you have access! });
});
});
app.listen(5000, () => console.log('Backend listening on port 5000'));Next.js Frontend Kurulumu ve Giriş Formu
Next.js projenizde bir giriş sayfası oluşturun.
// app/login/page.js (App Router)
'use client'; // Bu bir Client Component olacak
import { useState } from 'react';
import { useRouter } from 'next/navigation';
export default function LoginPage() {
const [username, setUsername] = useState('');
const [password, setPassword] = useState('');
const [error, setError] = useState('');
const router = useRouter();
const handleSubmit = async (e) => {
e.preventDefault();
setError('');
try {
const res = await fetch('http://localhost:5000/api/login', { // Backend API'nize yönlendirin
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ username, password }),
});
if (res.ok) {
const data = await res.json();
localStorage.setItem('accessToken', data.accessToken); // Geçici olarak localStorage'da tutalım
router.push('/dashboard');
} else {
const errorData = await res.json();
setError(errorData.message || 'Giriş başarısız.');
}
} catch (err) {
setError('Bir hata oluştu. Lütfen tekrar deneyin.');
}
};
return (
Giriş Yap
);
}Login İşlemi ve Token Alma
Yukarıdaki LoginPage bileşeni, kullanıcı adı ve şifre ile backend'e POST isteği gönderir. Başarılı olursa, backend accessToken'ı döndürür ve refreshToken'ı HttpOnly bir çerez olarak ayarlar. Frontend, accessToken'ı alır ve örneğin localStorage'a (daha güvenli bir yöntem için çerezler tercih edilmeli) kaydeder ve kullanıcıyı korunan bir sayfaya yönlendirir.
Korunan Rotalara Erişim ve Token Doğrulama
Middleware veya Server Components kullanarak korunan rotalara erişimi kontrol edebiliriz.
// app/dashboard/page.js (Bu bir Server Component olabilir)
import { cookies } from 'next/headers'; // Sadece Server Components'ta kullanılabilir
import { redirect } from 'next/navigation';
async function getProtectedData(accessToken) {
try {
const res = await fetch('http://localhost:5000/api/protected', {
headers: {
'Authorization': Bearer ${accessToken},
},
cache: 'no-store', // Her zaman güncel veri çek
});
if (!res.ok) {
if (res.status === 401 || res.status === 403) {
// Token geçersiz veya süresi dolmuş, yenileme veya giriş sayfasına yönlendir
return null;
}
throw new Error('Veri çekilemedi');
}
return res.json();
} catch (error) {
console.error('Korunan veri çekilirken hata:', error);
return null;
}
}
export default async function DashboardPage() {
const cookieStore = cookies();
const accessToken = cookieStore.get('accessToken')?.value; // Eğer access token'ı da çerezde tutuyorsanız
// Alternatif olarak, client component'ta localStorage'dan alabilirsiniz:
// const accessToken = typeof window !== 'undefined' ? localStorage.getItem('accessToken') : null;
if (!accessToken) {
redirect('/login');
}
const data = await getProtectedData(accessToken);
if (!data) {
redirect('/login'); // Yenileme başarısız veya token tamamen geçersiz
}
return (
Gösterge Paneli
{data.message}
{/* Diğer dashboard içeriği */}
);
}
Yukarıdaki örnekte accessToken'ı da çerezde tuttuğumuzu varsaydık. Eğer localStorage'da tutuluyorsa, Client Component içinde useEffect ile çekilmelidir.
Refresh Token Mekanizması Uygulaması
Access token'ın süresi dolduğunda, istemci bir API rotasına (örneğin /api/refresh-token) istek göndererek yeni bir access token talep etmelidir. Bu API rotası, HttpOnly çerezdeki refreshToken'ı okur, doğrular ve yeni bir accessToken oluşturup istemciye geri gönderir.
// app/api/refresh-token/route.js (Next.js API Route)
import { NextResponse } from 'next/server';
import { cookies } from 'next/headers';
import jwt from 'jsonwebtoken';
export async function POST(request) {
const cookieStore = cookies();
const refreshToken = cookieStore.get('refreshToken')?.value;
if (!refreshToken) {
return NextResponse.json({ message: 'No refresh token provided' }, { status: 401 });
}
try {
const decoded = jwt.verify(refreshToken, process.env.REFRESH_TOKEN_SECRET);
const newAccessToken = jwt.sign({ userId: decoded.userId, role: decoded.role }, process.env.JWT_SECRET, { expiresIn: '15m' });
return NextResponse.json({ accessToken: newAccessToken });
} catch (error) {
// Refresh token geçersiz veya süresi dolmuş
// Kullanıcıyı tekrar giriş yapmaya zorlamak için çerezi temizleyebiliriz
cookieStore.delete('refreshToken');
return NextResponse.json({ message: 'Invalid refresh token' }, { status: 403 });
}
}
Client tarafında, API istekleri yaparken access token'ın süresinin dolduğunu fark ettiğinizde (genellikle 401 hatası alarak), bu /api/refresh-token rotasına bir istek gönderebilir ve yeni access token ile orijinal isteği tekrarlayabilirsiniz.
Güvenlik İpuçları ve En İyi Uygulamalar (2026 Perspektifi)
Uygulamanızın 2026'da ve sonrasında güvende kalması için ek güvenlik önlemleri ve en iyi uygulamaları benimsemek şarttır.
Token Geçerlilik Süreleri ve Yenileme Stratejileri
* Access Token: Mümkün olduğunca kısa ömürlü olmalı (15-60 dakika). Bu, çalınması durumunda kötüye kullanım süresini sınırlar.
* Refresh Token: Daha uzun ömürlü olabilir (birkaç gün, birkaç hafta). Ancak, refresh token'lar da belirli bir süre sonra sona ermeli ve kullanıcının yeniden giriş yapması istenmelidir.
* Token İptali: Özellikle refresh token'lar için sunucu tarafında bir iptal listesi (blacklist) veya veritabanında token'ları takip etme mekanizması oluşturmak, çalınan token'ların kullanımını engellemek için kritik öneme sahiptir.
Güvenli Çerezler (HttpOnly, Secure, SameSite)
* HttpOnly: JavaScript'in çerezlere erişmesini engeller. Refresh token'lar için mutlak bir gerekliliktir.
* Secure: Çerezin yalnızca HTTPS üzerinden gönderilmesini sağlar. Üretim ortamında her zaman etkin olmalıdır.
* SameSite=Lax veya SameSite=Strict: CSRF saldırılarına karşı koruma sağlar. Lax varsayılan olarak çoğu tarayıcıda iyi bir denge sunarken, Strict daha katıdır ancak bazı kullanıcı deneyimi sorunlarına yol açabilir (örneğin, farklı bir siteden gelen bağlantılarla).
Şifreleme ve Veri Bütünlüğü
* Gizli Anahtarlar: JWT imzalamak için kullanılan JWT_SECRET ve REFRESH_TOKEN_SECRET anahtarları çok güçlü ve tahmin edilemez olmalı, ortam değişkenlerinde saklanmalı ve asla kaynak kodda olmamalıdır.
* HTTPS Kullanımı: Tüm iletişim HTTPS üzerinden yapılmalıdır. Bu, aktarım sırasındaki verilerin şifrelenmesini sağlar ve MITM (Man-in-the-Middle) saldırılarını önler.
Hata Yönetimi ve Loglama
* Ayrıntılı Hata Mesajlarından Kaçınma: Kimlik doğrulama hatalarında genel mesajlar (örneğin, "Geçersiz kimlik bilgileri") dönülmelidir. Saldırganlara sistem hakkında ipuçları verecek ayrıntılı hata mesajlarından kaçınılmalıdır.
* Güvenlik Logları: Başarısız giriş denemeleri, token yenileme girişimleri ve diğer güvenlik olayları loglanmalıdır. Bu loglar, potansiyel saldırıları tespit etmek ve analiz etmek için önemlidir.
Alternatifler: NextAuth.js ve Diğer Çözümler
JWT'yi manuel olarak uygulamak karmaşık olabilir. Next.js için popüler bir kimlik doğrulama kütüphanesi olan NextAuth.js (şimdiki adıyla Auth.js), birçok kimlik doğrulama stratejisini (OAuth, e-posta/şifre, JWT) kolayca entegre etmenizi sağlar. NextAuth.js, çoğu güvenlik endişesini sizin yerinize yönetir ve özellikle JWT'nin güvenli depolanması ve yenilenmesi gibi konularda güçlü bir soyutlama katmanı sunar. Daha büyük ve karmaşık uygulamalar için Auth0, Firebase Authentication gibi üçüncü taraf kimlik doğrulama hizmetleri de değerlendirilebilir.
Sıkça Sorulan Sorular (SSS)
Next.js ve JWT kimlik doğrulama hakkında sıkça sorulan bazı sorular ve yanıtları:
JWT'ler neden Local Storage'da saklanmamalıdır?
localStorage, XSS (Cross-Site Scripting) saldırılarına karşı savunmasızdır. Eğer uygulamanızda bir XSS güvenlik açığı varsa, saldırganlar localStorage'daki tüm verilere (JWT dahil) erişebilir ve bunları çalabilir. HttpOnly çerezler ise JavaScript tarafından erişilemediği için bu tür saldırılara karşı daha güvenlidir.
Refresh token'lar nasıl güvenli tutulur?
Refresh token'lar her zaman HttpOnly, Secure ve SameSite=Lax veya Strict özelliklerine sahip çerezlerde saklanmalıdır. HttpOnly özelliği, JavaScript'in token'a erişmesini engellerken, Secure özelliği sadece HTTPS üzerinden gönderilmesini sağlar. SameSite ise CSRF saldırılarına karşı koruma sağlar.
Next.js Server Components'ta kimlik doğrulama nasıl yapılır?
Server Components'ta kimlik doğrulama, next/headers modülünden cookies() fonksiyonunu kullanarak çerezlere erişimle yapılır. Sunucu tarafında çerezlerden token'ı okuyabilir, doğrulayabilir ve kullanıcının yetkisine göre sayfa içeriğini render edebilirsiniz. Bu yaklaşım, hassas token bilgilerinin istemciye gönderilmesini önler.