Merhaba arkadaşlar, bugün sizlere Nginx'in çok güçlü ama bazen gözden kaçan bir özelliğinden bahsedeceğim: Harici Kimlik Doğrulama (External Authentication) ve bunu bir API Gateway mimarisinin temel taşı haline getirmek. Özellikle mikroservis mimarilerinde veya birden fazla arka uç servisinizin olduğu ortamlarda, tüm kimlik doğrulama ve yetkilendirme yükünü tek bir noktadan (Nginx'ten) yönetmek hem güvenlik hem de yönetilebilirlik açısından müthiş bir rahatlık sağlar. Ben kendi sunucu kümelerimde bu yapıyı sıklıkla kullanıyorum, hadi gelin birlikte nasıl kuracağımıza bakalım.
Neden Harici Kimlik Doğrulama?
Geleneksel yöntemde, her bir web uygulaması veya API endpoint'i kendi içinde kullanıcıyı doğrular. Bu, her servise aynı kodu tekrar tekrar yazmanıza, JWT secret'larını her yere dağıtmanıza ve güvenlik politikalarını merkezileştirememenize neden olur. Harici kimlik doğrulama ile ise, bir kullanıcı herhangi bir istek gönderdiğinde, Nginx bu isteği durdurur ve sizin belirleyeceğiniz bir kimlik doğrulama servisine (örn: bir Python/Go/Node.js uygulaması veya bir auth sunucusu) sorar: "Bu kullanıcı geçerli mi, bu rotaya erişim izni var mı?" Cevap olumlu ise istek arka uç servise iletir, değilse hemen 401 veya 403 hatası döner. Tüm mantık tek yerde toplanır.
Temel Auth Request Yapılandırması
İşin özü, Nginx'in `auth_request` modülünde gizli. Bu modül genellikle varsayılan kurulumlarda gelir. Öncelikle, kimlik doğrulamasından sorumlu olacak harici servisinizin çalıştığından emin olun. Diyelim ki bu servis `
` endpoint'ine POST istekleri bekliyor ve geçerli token'lar için 200, geçersizler için 401 dönüyor.
Ana Nginx konfigürasyonunuzda (`nginx.conf` veya sitenizin konfigürasyon dosyasında) aşağıdaki gibi bir `location` bloğu ve `auth_request` direktifini kullanacağız.
Şimdi, korumak istediğimiz API endpoint'lerimizin olduğu `location` bloğuna bu auth mekanizmasını ekleyelim.
API Gateway ve Yönlendirme (Routing) Mantığı
Artık kimlik doğrulamamız çalışıyor. Peki ya onlarca mikroservisimiz varsa? Nginx'i akıllı bir yönlendirici (router) olarak kullanabiliriz. İsteğin yoluna (path) veya header bilgilerine göre farklı arka uçlara yönlendirelim.
Dikkat Edilmesi Gerekenler ve Optimizasyon
Auth Servis Performansı: Tüm trafik buradan geçeceği için auth servisinizin yüksek performanslı ve resilient (dayanıklı) olması şart. Connection pooling ve caching (örn: Redis ile token cache) mutlaka düşünün.
Hata Yönetimi: Auth servisiniz cevap vermezse ne olacak? `proxy_next_upstream`, `proxy_connect_timeout` ve `proxy_read_timeout` değerlerini dikkatli ayarlayın. Auth servisi down olduğunda tüm sisteminize erişim kapanmasın.
Güvenlik: Auth servisi ile Nginx arasındaki iletişim güvenli olmalı. Mümkünse aynı private network içinde çalıştırın veya mTLS gibi yöntemlerle iletişimi şifreleyin.
Test: Konfigürasyonu canlıya almadan önce mutlaka `nginx -t` ile test edin. Logları (/var/log/nginx/error.log) sıkı takip edin.
Sonuç
Bu yapıyı kurduğunuzda, kimlik doğrulama ve basit yönlendirme mantığını tüm arka uç servislerinizden soyutlamış olacaksınız. Yeni bir servis eklediğinizde, sadece Nginx konfigürasyonuna bir satır eklemeniz yeterli. Güvenlik güncellemeleri ve yetki politikası değişiklikleri için sadece merkezi auth servisinizi güncellemeniz yetecek.
Ben bu mimariyi JWT tabanlı bir auth servisi ile birlikte kullanıyorum ve yönetimi inanılmaz kolaylaştırdı. Siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? Farklı bir auth yöntemi (OAuth, API Key) mi tercih ediyorsunuz? Ya da takıldığınız bir nokta var mı? Sorularınızı ve deneyimlerinizi aşağıdaki yorumlarda paylaşabilirsiniz, elimden geldiğince yardımcı olmaya çalışırım.
Neden Harici Kimlik Doğrulama?Geleneksel yöntemde, her bir web uygulaması veya API endpoint'i kendi içinde kullanıcıyı doğrular. Bu, her servise aynı kodu tekrar tekrar yazmanıza, JWT secret'larını her yere dağıtmanıza ve güvenlik politikalarını merkezileştirememenize neden olur. Harici kimlik doğrulama ile ise, bir kullanıcı herhangi bir istek gönderdiğinde, Nginx bu isteği durdurur ve sizin belirleyeceğiniz bir kimlik doğrulama servisine (örn: bir Python/Go/Node.js uygulaması veya bir auth sunucusu) sorar: "Bu kullanıcı geçerli mi, bu rotaya erişim izni var mı?" Cevap olumlu ise istek arka uç servise iletir, değilse hemen 401 veya 403 hatası döner. Tüm mantık tek yerde toplanır.
Temel Auth Request Yapılandırmasıİşin özü, Nginx'in `auth_request` modülünde gizli. Bu modül genellikle varsayılan kurulumlarda gelir. Öncelikle, kimlik doğrulamasından sorumlu olacak harici servisinizin çalıştığından emin olun. Diyelim ki bu servis `
Bu bağlantı ziyaretçiler için gizlenmiştir. Görmek için lütfen giriş yapın veya üye olun.
Ana Nginx konfigürasyonunuzda (`nginx.conf` veya sitenizin konfigürasyon dosyasında) aşağıdaki gibi bir `location` bloğu ve `auth_request` direktifini kullanacağız.
NGINX:
# 1. Auth isteği için bir iç location oluşturuyoruz.
# Bu location dışarıya kapalıdır, sadece internal auth için kullanılır.
location = /auth-proxy {
internal; # Bu endpoint dışarıdan erişilemez.
proxy_pass http://auth-service:8000/validate;
proxy_pass_request_body off; # Auth servisine body göndermiyoruz (token header'da).
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Original-Method $request_method;
# Authorization header'ını olduğu gibi auth servisine ilet.
proxy_set_header Authorization $http_authorization;
}Şimdi, korumak istediğimiz API endpoint'lerimizin olduğu `location` bloğuna bu auth mekanizmasını ekleyelim.
NGINX:
location /api/ {
# Gelen her istek önce /auth-proxy location'ına yönlendirilip doğrulanacak.
auth_request /auth-proxy;
# Auth servisi 200 dönerse, bu değişkenler ayarlanır (opsiyonel).
auth_request_set $user_id $upstream_http_x_user_id;
auth_request_set $user_role $upstream_http_x_user_role;
# Doğrulanmış kullanıcı bilgilerini arka uç servise ilet.
proxy_set_header X-User-ID $user_id;
proxy_set_header X-User-Role $user_role;
# Arka uç servisinizin adresini yazın.
proxy_pass http://backend-api-service:8080;
# Auth hatası durumunda dönecek hata sayfaları (opsiyonel).
error_page 401 = @error401;
error_page 403 = @error403;
}
# Özel hata sayfaları için location'lar
location @error401 {
return 401 '{"error": "Unauthorized", "message": "Geçersiz veya eksik kimlik bilgisi."}';
add_header Content-Type application/json;
}
location @error403 {
return 403 '{"error": "Forbidden", "message": "Bu kaynağa erişim izniniz yok."}';
add_header Content-Type application/json;
}Artık kimlik doğrulamamız çalışıyor. Peki ya onlarca mikroservisimiz varsa? Nginx'i akıllı bir yönlendirici (router) olarak kullanabiliriz. İsteğin yoluna (path) veya header bilgilerine göre farklı arka uçlara yönlendirelim.
NGINX:
location ~ ^/api/(?<service>\w+)/(?<path>.) {
auth_request /auth-proxy;
auth_request_set $user_role $upstream_http_x_user_role;
# Kullanıcı rolüne göre erişim kontrolü (örnek).
if ($user_role != "admin" && $service = "admin") {
return 403;
}
# Servis ismine göre yönlendirme.
# Servis isimlerinize göre proxy_pass adreslerini düzenleyin.
if ($service = "users") {
proxy_pass http://user-service:3000/$path$is_args$args;
}
if ($service = "orders") {
proxy_pass http://order-service:3001/$path$is_args$args;
}
if ($service = "products") {
proxy_pass http://product-service:3002/$path$is_args$args;
}
# Eşleşmeyen servis isimleri için 404.
return 404 '{"error": "Service not found"}';
}Auth Servis Performansı: Tüm trafik buradan geçeceği için auth servisinizin yüksek performanslı ve resilient (dayanıklı) olması şart. Connection pooling ve caching (örn: Redis ile token cache) mutlaka düşünün.
Hata Yönetimi: Auth servisiniz cevap vermezse ne olacak? `proxy_next_upstream`, `proxy_connect_timeout` ve `proxy_read_timeout` değerlerini dikkatli ayarlayın. Auth servisi down olduğunda tüm sisteminize erişim kapanmasın.
Güvenlik: Auth servisi ile Nginx arasındaki iletişim güvenli olmalı. Mümkünse aynı private network içinde çalıştırın veya mTLS gibi yöntemlerle iletişimi şifreleyin.
Test: Konfigürasyonu canlıya almadan önce mutlaka `nginx -t` ile test edin. Logları (/var/log/nginx/error.log) sıkı takip edin.
SonuçBu yapıyı kurduğunuzda, kimlik doğrulama ve basit yönlendirme mantığını tüm arka uç servislerinizden soyutlamış olacaksınız. Yeni bir servis eklediğinizde, sadece Nginx konfigürasyonuna bir satır eklemeniz yeterli. Güvenlik güncellemeleri ve yetki politikası değişiklikleri için sadece merkezi auth servisinizi güncellemeniz yetecek.
Ben bu mimariyi JWT tabanlı bir auth servisi ile birlikte kullanıyorum ve yönetimi inanılmaz kolaylaştırdı. Siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? Farklı bir auth yöntemi (OAuth, API Key) mi tercih ediyorsunuz? Ya da takıldığınız bir nokta var mı? Sorularınızı ve deneyimlerinizi aşağıdaki yorumlarda paylaşabilirsiniz, elimden geldiğince yardımcı olmaya çalışırım.