Backend API Kimlik Doğrulama

Backend API çağrılarına otomatik olarak kimlik doğrulama bilgisi ekleyebilirsiniz. Basic, Digest, Base64 ve API Auth gibi farklı kimlik doğrulama yöntemlerini kullanabilirsiniz

Bu doküman spesifik bir politikanın detaylı kullanımını anlatır. Eğer Apinizer politika yapısını ilk kez kullanıyorsanız veya politikaların genel çalışma prensiplerini öğrenmek istiyorsanız, öncelikle Politika Nedir? sayfasını okumanızı öneririz.

​

Genel Bakış

Backend API Authentication politikası, API Gateway’in backend servislerine erişim sağlarken kullanacağı kimlik doğrulama bilgilerini tanımlar. Plain-Text, Basic, API Key ve Digest gibi farklı authentication yöntemlerini destekleyerek backend sistemlere güvenli bağlantı kurar. Mikroservis mimarilerinde her servisin farklı authentication gereksinimlerini merkezi olarak yönetmek için idealdir.

​

Amacı Nedir?

• Backend API servislerine yapılan çağrılarda kimlik doğrulama bilgilerinin otomatik olarak eklenmesini sağlar, böylece her istek için manuel credential yönetimi gerekmez.
• Basic, Digest, Base64 ve özel API Authentication olmak üzere dört farklı kimlik doğrulama türünü destekler ve koşullu kullanıcı adı/şifre tanımlarına izin verir.
• Kimlik doğrulama bilgilerinin HTTP Header, URL Parametresi, Body Message veya Body Injection yöntemleriyle backend’e iletilmesini sağlar.
• XML ve JSON formatlarında mesaj içeriği desteği sunarak hem SOAP hem de REST servisleriyle uyumlu çalışır.
• Koşul bazlı credential yönetimi sayesinde farklı senaryolarda (örn: environment, endpoint, header değerine göre) farklı kullanıcı bilgileri kullanılabilir.

​

Çalışma Prensibi

1. İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, istemin backend servise yönlendirilmeden önce kimlik doğrulama bilgisinin eklenmesi gerekip gerekmediği kontrol edilir.
2. Politika Kontrolü: API Authentication politikası aktif ise, sistem aşağıdaki sırayla kontrol yapar:
   • Condition (koşul) tanımlı mı? Varsa koşul sağlanıyor mu?
   • Politika aktif mi (active=true)?
   • Variable kullanılıyor mu yoksa Apinizer default mı?
3. Kimlik Doğrulama Türü Seçimi: Tanımlanan Auth Type’a göre (API, BASIC, BASE64, DIGEST) uygun kimlik bilgisi hazırlanır. Eğer Conditional Expression tanımlıysa, koşullara göre doğru username/password seçilir.
4. Karar Verme:
   • Koşul Sağlanırsa: İlgili credential bilgisi seçilen Send Type metoduyla (Header, Param, Body Message, Body Injection) backend çağrısına eklenir ve istek iletilir.
   • Koşul Sağlanmazsa veya Credential Bulunamazsa: İstek reddedilir ve özelleştirilebilir hata mesajı döndürülür.
5. Hata İşleme: Politika kuralına uymayan istekler için özelleştirilebilir HTTP durum kodu ve hata mesajı döndürülür.

​

Özellikler ve Yetenekler

​

Temel Özellikler

• Dört Farklı Kimlik Doğrulama Türü: API (hazır auth servisi), Basic Authentication, Base64 encoded Authorization, Digest Authentication desteği.
• Koşullu Credential Yönetimi: Her username/password çifti için ayrı koşullar tanımlayarak ortam, endpoint veya header değerine göre dinamik credential seçimi yapabilme.
• Dört Farklı Gönderim Yöntemi: Kimlik bilgilerini HTTP Header, URL Parametresi, Body Message veya Body Injection yöntemleriyle backend’e gönderebilme.
• XML ve JSON Desteği: Body tabanlı kimlik doğrulamada hem XML (SOAP) hem de JSON (REST) formatlarını destekleme ve XPath/JSONPath injection yapabilme.
• API Authentication Entegrasyonu: Hazır tanımlı Authentication API servislerini kullanarak merkezi credential yönetimi yapabilme.
• Aktif/Pasif Durum Kontrolü: Politikanın aktif veya pasif durumunu kolayca değiştirme (active/passive toggle). Pasif durumda politika uygulanmaz ancak yapılandırması saklanır.
• Koşul Bazlı Uygulama: Query Builder ile karmaşık koşullar oluşturarak politikanın ne zaman uygulanacağını belirleme (örn: sadece belirli endpoint’lere veya header değerlerine göre).

​

İleri Düzey Özellikler

• Dinamik Field Name ve Injection Path Tanımlama: Header, parametre veya body injection için field name ve path’leri özelleştirerek esnek kimlik doğrulama yapılandırması oluşturma.
• Digest Authentication Desteği: Nonce, Created timestamp gibi gelişmiş güvenlik parametreleriyle Digest authentication yapabilme (SOAP WS-Security uyumlu).
• Body Message Template Desteği: XML ve JSON için hazır body message template’leri kullanarak hızlı SOAP/REST kimlik doğrulama konfigürasyonu oluşturma.
• XPath ve JSONPath Test Aracı: Body injection ve message path’lerini canlı olarak test edebilme ve doğrulama yapabilme.
• Username Expression Table: Birden fazla username/password çifti tanımlayıp her biri için farklı koşullar belirleyerek çok senaryolu credential yönetimi yapabilme.
• Export/Import Özelliği: Politika yapılandırmasını ZIP dosyası olarak export etme. Farklı ortamlara (Development, Test, Production) import etme. Versiyon kontrolü ve yedekleme imkanı.
• Policy Group ve Proxy Group Desteği: Birden fazla politikayı Policy Group içinde yönetme. Proxy Group’lara toplu politika atama. Merkezi güncelleme ve deploy işlemleri.
• Deploy ve Versiyonlama: Politika değişikliklerini canlı ortama deploy etme. Hangi API Proxy’lerde kullanıldığını görme (Policy Usage). Proxy Group ve Policy Group kullanım raporları.

​

Kullanım Senaryoları

Senaryo	Durum	Çözüm (Politika Uygulaması)	Beklenen Davranış / Sonuç
Backend SOAP Servisine WS-Security ile Bağlanma	SOAP backend servisi Basic Authentication ile korumalı ve WS-Security header’ı bekliyor	Auth Type: BASIC Send Type: BODY_MESSAGE Message Type: XML Username/Password: Conditional Expression ile tanımlanmış Body Message: WS-Security template kullan	Gateway, tüm SOAP isteklerine otomatik olarak WS-Security header’ı ekler. Backend servis kimlik doğrulamasını geçer ve cevap döner.
Ortam Bazlı Farklı Credential Kullanımı	Test ortamında test_user, Production ortamında prod_user kullanılması gerekiyor	Auth Type: BASIC Send Type: HEADER Conditional Expression 1: Header X-Environment = test → username: test_user Conditional Expression 2: Header X-Environment = prod → username: prod_user	Gateway, gelen istekteki X-Environment header’ına göre doğru credential’ı seçer ve backend’e iletir.
REST API’ye Base64 Authorization Header Ekleme	REST backend servisi “Authorization: Basic base64string” header’ı bekliyor	Auth Type: BASE64 Send Type: HEADER Password Field Name: Authorization Conditional Expression: İlgili username/password tanımlanmış	Gateway, username ve password’ü otomatik olarak Base64 encode eder ve Authorization header’ına ekleyerek backend’e gönderir.
Hazır Authentication API Kullanımı	Merkezi bir OAuth/OIDC servisi üzerinden token alınıp backend’e gönderilmesi gerekiyor	Auth Type: API Auth API ID: Seçilen Authentication API servisi Send Type ve diğer parametreler API konfigürasyonuna göre	Gateway, tanımlı Authentication API’yi çağırır, aldığı token’ı kullanarak backend servisine kimlik doğrulamalı istek gönderir
JSON REST API’ye Digest Authentication	JSON backend servisi digest authentication bekliyor ve nonce/created bilgisi istiyor	Auth Type: DIGEST Send Type: BODY_INJECTION Message Type: JSON Field Names: username, password, nonce, created Injection Paths: JSONPath ile belirlenen path’ler	Gateway, digest authentication için gerekli nonce ve created değerlerini oluşturur, JSON body’ye inject eder ve backend’e gönderir.
URL Parametresi ile Kimlik Doğrulama	Legacy backend servisi kimlik bilgilerini query string parametresi olarak bekliyor	Auth Type: BASIC Send Type: PARAM Username Param Name: api_user Password Param Name: api_key Conditional Expression: İlgili credential tanımlanmış	Gateway, kimlik bilgilerini URL query string’ine ekler: ?api_user=xxx&api_key=yyy
Endpoint Bazlı Farklı Credential	/admin endpoint’i admin credential, /user endpoint’i user credential gerektiriyor	Koşul (Policy Condition): Path starts with /admin → Admin API Authentication Policy Koşul (Policy Condition): Path starts with /user → User API Authentication Policy	Gateway, gelen isteğin path’ine göre doğru politikayı uygular ve ilgili credential’ı kullanır. İki ayrı policy veya tek policy içinde conditional expression kullanılabilir.

​

Politika Parametrelerini Yapılandırma

Bu adımda, kullanıcı yeni bir politika oluşturabilir ya da mevcut politika parametrelerini yapılandırarak erişim kurallarını belirleyebilir. Tanımlanan parametreler, politikanın çalışma şeklini (örneğin hangi IP’lerin izinli olacağı, coğrafi kısıtlamalar, koşullu aktivasyonlar vb.) doğrudan etkiler. Bu sayede politika hem kuruma özel gereksinimlere göre özelleştirilebilir hem de merkezi olarak yönetilebilir.

​

Yeni API Authentication Politikası Oluşturma

​

Yapılandırma Adımları

Adım	Açıklama / İşlem
Adım 1: Oluşturma Sayfasına Gitme	- Sol menüden Development → Global Settings → Global Policies → API Authentication bölümüne gidin. - Sağ üstteki [+ Create] butonuna tıklayın.
Adım 2: Temel Bilgileri Girme	Policy Status (Politika Durumu): Aktif/Pasif durumu gösterir. Yeni politikalar varsayılan olarak aktiftir. Name (İsim) Zorunlu: Örnek: Production_Backend_Auth - Benzersiz isim girin, boşlukla başlamaz. - Sistem otomatik kontrol eder. Yeşil tik: kullanılabilir. Kırmızı çarpı: mevcut isim. Description (Açıklama): Örnek: “Production ortamı için backend servislerine kimlik doğrulama bilgisi ekler” - Maks. 1000 karakter. - Politikanın amacını açıklayın.
Adım 3: Variable Kullanımı	- Sayfanın üst kısmındaki işlem butonları alanında, [<> Variable] butonunu kullanarak dinamik değer seçebilirsiniz. - Context/global variable ifadeleri sayesinde politika parametrelerini sabit değer yerine değişken tabanlı yönetebilirsiniz. - Bu kullanım, değişen değerlerde manuel güncelleme ihtiyacını azaltır ve operasyonel kolaylık sağlar. - Detaylı bilgi için Dinamik Değişkenler sayfasını inceleyebilirsiniz.
Adım 4: Kimlik Doğrulama Türü Seçimi (Auth Type)	Auth Type Dropdown (Zorunlu): Seçenekler: - API: Önceden tanımlı Authentication API servisi kullanır (OAuth, OIDC vb.) - BASIC: Kullanıcı adı ve şifre ile temel kimlik doğrulama - BASE64: Base64 encoded authorization header - DIGEST: Digest authentication (nonce, created ile güvenli kimlik doğrulama) Not: - API seçilirse: “Select Authentication API” butonu görünür, hazır auth servisi seçilir. - BASIC/BASE64/DIGEST seçilirse: Username/Password Expression Table görünür.
Adım 5: Username/Password Expression Tanımlama (Auth Type: BASIC, BASE64 veya DIGEST için)	Bu bölümde, koşullu kullanıcı adı ve şifre tanımları yapılır. Birden fazla credential tanımlanabilir ve her biri için farklı koşullar belirlenebilir. Username/Password Expression Table: - [+ Add] butonuna tıklayın. - Username: İlgili kullanıcı adını girin (örn: backend_user, ${variable.username}) - Password: İlgili şifreyi girin (örn: backend_pass123, ${variable.password}) - Condition (Koşul): Query Builder ile koşul tanımlayın - Örnek: Header[X-Environment] Equals production - Örnek: Path Starts With /admin Not: - En az bir username/password tanımı zorunludur. - Koşullar sırayla değerlendirilir, ilk eşleşen kullanılır.
Adım 6: Gönderim Yöntemi Seçimi (Send Type) (Auth Type: BASIC, BASE64 veya DIGEST için)	Send Type Dropdown (Zorunlu): HEADER: Kimlik bilgileri HTTP header’larında gönderilir - Username Header Name: Kullanıcı adı header adı (örn: X-Username) - Password Header Name: Şifre header adı (örn: X-Password) - Digest için: Created Header Name, Nonce Header Name PARAM: Kimlik bilgileri URL parametresi olarak gönderilir - Username Param Name: Kullanıcı adı parametre adı (örn: user) - Password Param Name: Şifre parametre adı (örn: pass) - Digest için: Created Param Name, Nonce Param Name BODY_MESSAGE: Hazır mesaj template’i body’ye eklenir - Message Content Type: XML veya JSON seçin - Body Message: Otomatik template yüklenir (WS-Security için XML, JSON için username/password object) - Body Message Injection Path: Template’in nereye ekleneceği (XPath veya JSONPath) BODY_INJECTION: Mevcut body’ye field injection yapılır - Message Content Type: XML veya JSON seçin - Username Field Name: Kullanıcı adı field adı (örn: username) - Username Injection Path: XPath veya JSONPath (örn: $.credentials.username) - Password Field Name: Şifre field adı (örn: password) - Password Injection Path: XPath veya JSONPath (örn: $.credentials.password) - Digest için: Created Field Name, Created Injection Path, Nonce Field Name, Nonce Injection Path
Adım 7: Koşul Tanımlama (İsteğe Bağlı)	- Condition sekmesine geçin. - Koşullar, politikanın hangi durumda aktif olacağını belirler. Örnekler: - Ortam bazlı: Header = X-Environment, Operator = Equals, Value = production - API Key bazlı: Header = X-API-Key, Starts With = PROD- - Endpoint bazlı: Path = /api/admin/* Koşul tanımlamazsa politika her zaman aktif
Adım 8: Hata Mesajı Özelleştirme (İsteğe Bağlı)	- Error Message Customization sekmesine gidin. - Erişim reddedildiğinde dönecek mesajı özelleştirin. Varsayılan: { "statusCode": 401, "message": "Unauthorized: Authentication credentials are missing or invalid" } Özel: { "statusCode": 401, "errorCode": "AUTH_FAILED", "message": "Backend kimlik doğrulama başarısız. Lütfen sistem yöneticisi ile iletişime geçin." }
Adım 9: Kaydetme	- Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: - Benzersiz isim - Zorunlu alanlar dolu - En az bir username/password tanımı mevcut Sonuç: - Politika listeye eklenir. - API’lere bağlanabilir. - Global politikaysa otomatik uygulanır.

Koşullar ve Hata Mesajı Özelleştirme panellerinin açıklaması için Politika Nedir? sayfasındaki Koşullar ve Hata Mesajı Özelleştirme (Error Message Customization) bölümlerini inceleyebilirsiniz.

Hata mesajı yapılandırmasının tüm katmanları, öncelik sırası ve senaryo örnekleri için Hata Mesajı Yapılandırma Rehberi sayfasına bakın.

​

Politikayı Silme

Bu politikanın silme adımları ve kullanımdayken uygulanacak işlemler için Politika Yönetimi sayfasındaki Akıştan Politika Kaldırma bölümüne bakabilirsiniz.

​

Politikayı Dışa/İçe Aktarma

Bu politikanın dışa aktarma (Export) ve içe aktarma (Import) adımları için Export/Import sayfasına bakabilirsiniz.

​

Politikayı API’ye Bağlama

Bu politikanın API’lere nasıl bağlanacağına ilişkin süreç için Politika Yönetimi sayfasındaki Politikayı API’ye Bağlama bölümüne bakabilirsiniz.

​

İleri Düzey Özellikler

Özellik	Açıklama ve Adımlar
Variable Expression Kullanımı	- Username ve password alanlarında değişken ifadeleri kullanın (örn: ${env.backend_user}, ${vault.db_password}) - API Proxy veya Global Settings → Variables bölümünden ilgili değişkenleri tanımlayın - Değişkenler runtime’da çözümlenir ve güvenli credential yönetimi sağlanır Fayda: Credential’lar kod içinde hardcoded olmaz, merkezi yönetim ve güvenlik artar.
XPath ve JSONPath Test Aracı	- Send Type olarak BODY_MESSAGE veya BODY_INJECTION seçin - Field Name ve Injection Path alanlarının yanındaki [Test] butonuna tıklayın - Test penceresinde sample XML/JSON mesajınızı girin - Tanımladığınız XPath/JSONPath ifadesinin doğru çalışıp çalışmadığını görün Fayda: Canlı ortama almadan önce injection path’lerinizi test edebilir, hata riskini azaltırsınız.
Authentication API Entegrasyonu	- Global Settings → Authentication API bölümünden OAuth, OIDC veya Custom Auth servisi tanımlayın - API Authentication politikasında Auth Type = API seçin - “Select Authentication API” butonuna tıklayarak tanımlı auth servisini seçin - Backend çağrılarında otomatik olarak token alınıp kullanılır Fayda: OAuth/OIDC gibi karmaşık auth flow’larını merkezi yönetim ve token yenileme otomatik yapılır.

​

İpuçları ve En İyi Uygulamalar

​

Yapılması Gerekenler ve En İyi Uygulamalar

Kategori	Açıklama / Öneriler
Credential Yönetimi	Kötü: Kullanıcı adı ve şifreleri politika içinde hardcode etmek: username: admin, password: 12345 İyi: Variable expression kullanmak: username: ${backend.user}, password: ${backend.pass} En İyi: Variable expression + Vault entegrasyonu kullanmak: username: ${vault.backend_user}, password: ${vault.backend_password} - Güvenlik maksimum düzeyde, credential rotation kolay
Koşul Tanımlama	Kötü: Tek bir global politikada tüm ortamlar için aynı credential kullanmak İyi: Her ortam için ayrı politika oluşturmak (Dev_Auth, Test_Auth, Prod_Auth) En İyi: Tek politika içinde conditional expression kullanarak ortam bazlı credential yönetimi: Header[X-Environment] = prod → prod_user - Merkezi yönetim, daha az politika, daha kolay bakım
Send Type Seçimi	Kötü: Legacy sistemler için BODY_MESSAGE/BODY_INJECTION kullanmak (performans düşer) İyi: Modern REST API’ler için HEADER kullanmak (standart ve hızlı) En İyi: Backend’in beklentisine göre uygun yöntemi seçmek: SOAP WS-Security için BODY_MESSAGE, REST için HEADER, Legacy için PARAM - Uyumluluk ve performans dengesi
Test ve Deploy Stratejisi	Kötü: Global politikayı doğrudan production’da oluşturup test etmek İyi: Önce local politika olarak test etmek, sonra global yapmak En İyi: Dev ortamında global politika oluşturup test etmek → Export → Test ortamına import → Test → Prod ortamına import - Risk minimize, kontrollü deploy
Authentication API Kullanımı	Kötü: OAuth token’larını manuel olarak yönetmeye çalışmak (token expiration, refresh logic vb.) İyi: Her API için ayrı auth logic yazmak En İyi: Merkezi Authentication API tanımlayıp tüm API’lerde kullanmak - Token yenileme otomatik, merkezi yönetim, kod tekrarı yok

​

Güvenlik En İyi Uygulamaları

Güvenlik Alanı	Açıklama / Uyarılar
Credential Güvenliği	Uyarı: Credential’ları asla log’lara yazdırmayın. Politika içinde credential’ları hardcode etmekten kaçının. Şifreleri düz metin olarak saklamayın. Çözüm: Variable expression + Vault entegrasyonu kullanın. Log masking aktif olsun. Credential rotation politikaları uygulayın.
HTTPS Kullanımı	Uyarı: Backend kimlik doğrulama bilgileri HTTP üzerinden gönderilirse man-in-the-middle saldırılarına açık hale gelir. Çözüm: Backend servislere mutlaka HTTPS üzerinden bağlanın. TLS 1.2 veya üstü kullanın. Self-signed sertifika kullanmayın (prod için).
Least Privilege Prensibi	Uyarı: Tüm backend servisleri için aynı admin credential’ı kullanmak büyük güvenlik riski oluşturur. Çözüm: Her backend servisi için ayrı, sadece gerekli yetkilere sahip credential kullanın. Conditional expression ile servis bazlı credential yönetimi yapın.
Audit ve Monitoring	Uyarı: Kimlik doğrulama başarısızlıklarını izlemezseniz saldırı girişimlerini kaçırırsınız. Çözüm: Auth failure log’larını aktif edin. Monitoring ve alerting kurun. Başarısız auth denemelerini limit edin (Rate Limiting ile birlikte kullanın).
Policy Update Güvenliği	Uyarı: Global politikayı güncellerken tüm bağlı API’lerde kimlik doğrulama kesintiye uğrayabilir. Çözüm: Önce test ortamında deneyin. Production’da güncelleme yapmadan önce backup alın. Deploy’dan sonra Used Proxies’de test edin. Blue-green deployment stratejisi kullanın.

​

Kaçınılması Gerekenler

Kategori	Açıklama / Uyarılar
Hardcoded Credential Kullanımı	Neden kaçınılmalı: Güvenlik riski oluşturur. Credential değiştiğinde tüm politikaları manuel güncellemek gerekir. Kod review’lerde credential’lar görünür. Alternatif: Variable expression ve Vault kullanın: ${vault.backend_credentials.username}
Send Type Yanlış Seçimi	Neden kaçınılmalı: Backend’in beklediği format dışında gönderim yapılırsa kimlik doğrulama başarısız olur. BODY_MESSAGE kullanırken mevcut body’yi ezebilir. Alternatif: Backend dokümantasyonunu inceleyin ve uygun Send Type’ı seçin. BODY_INJECTION kullanırken path’lerin doğruluğunu test edin.
Conditional Expression Kullanmadan Çok Sayıda Politika Oluşturma	Neden kaçınılmalı: Yönetim zorlaşır. Deploy karmaşık hale gelir. Aynı mantığı farklı politikalarda tekrarlamak hata riskini artırır. Alternatif: Tek politika içinde conditional expression kullanarak farklı senaryoları yönetin. Policy Group kullanın.
Test Etmeden Production’a Deploy	Neden kaçınılmalı: Yanlış yapılandırma tüm backend çağrılarını kırar. Credential yanlışsa servisler erişilemez hale gelir. Downtime oluşur. Alternatif: Önce local politika olarak test edin. Dev/Test ortamlarında doğrulayın. Canary deployment kullanın.

​

Performans İpuçları

Kriter	Öneri / Etki
Send Type Performansı	Öneri: HEADER veya PARAM kullanın (en hızlı). BODY_MESSAGE ve BODY_INJECTION daha fazla işlem gerektirir. Etki: HEADER: ~1ms ek süre, BODY_MESSAGE: ~5-10ms, BODY_INJECTION: ~10-20ms (message boyutuna bağlı)
Conditional Expression Sayısı	Öneri: Conditional expression sayısını makul seviyede tutun (max 5-10). Karmaşık XPath/JSONPath yerine basit koşullar kullanın. Etki: Her expression ~0.5ms ekler. Çok fazla expression runtime overhead oluşturur.
Variable Expression Çözümleme	Öneri: Variable expression’ları cache’lenen değişkenlerden çözümleyin. Her istekte external Vault’a gitmekten kaçının (caching kullanın). Etki: Cache hit: ~0.1ms, Cache miss + Vault call: ~50-100ms
Message Content Type	Öneri: JSON kullanın (daha hafif ve hızlı parse). XML sadece SOAP servisleri için gerekli. Etki: JSON parsing: ~2-5ms, XML parsing: ~10-20ms (message boyutuna bağlı)
Authentication API Cache	Öneri: Authentication API kullanıyorsanız token cache’i aktif edin. Token expiration süresini optimize edin (너무 kısa: çok sık yenileme, çok uzun: güvenlik riski). Etki: Cached token: ~0.5ms, Yeni token almak: ~100-500ms (auth service’e bağlı)

​

Sık Sorulan Sorular (SSS)

Kategori	Soru	Cevap
Genel	API Authentication politikası ne zaman kullanılmalı?	Backend servisleriniz kimlik doğrulama gerektiriyorsa ve bu bilgileri her istekte manuel eklemek istemiyorsanız bu politikayı kullanmalısınız. Özellikle SOAP WS-Security, Basic Auth, OAuth token yönetimi gibi durumlarda idealdir.
Genel	Birden fazla Authentication politikası aynı API’ye atanabilir mi?	Hayır, bir API’ye sadece bir tane API Authentication politikası atanabilir. Ancak conditional expression kullanarak tek politika içinde birden fazla senaryo yönetebilirsiniz.
Teknik	BODY_MESSAGE ve BODY_INJECTION arasındaki fark nedir?	BODY_MESSAGE: Hazır bir template’i mesajın belirli bir yerine ekler (örn: SOAP Header). Mevcut body’yi değiştirmez, sadece ekler. BODY_INJECTION: Mevcut body içindeki belirli alanlara credential bilgilerini inject eder. XPath/JSONPath ile hedef field’ları bulup değer atar.
Teknik	Authentication API kullanırken token yenileme otomatik mi yapılıyor?	Evet, Authentication API yapılandırmasında token expiration ve refresh logic tanımlıysa Apinizer otomatik olarak token’ı yeniler. Manual müdahale gerekmez.
Kullanım	Ortam bazlı farklı credential nasıl yönetilir?	İki yöntem: 1) Conditional Expression kullanarak tek politika içinde Header[X-Environment] = prod → prod_user şeklinde tanım yapın. 2) Her ortam için ayrı politika oluşturun ve deployment sırasında doğru politikayı aktif edin. Birinci yöntem önerilir (merkezi yönetim).
Kullanım	Variable expression’da hangi değişken kaynaklarını kullanabilirim?	${env.VAR_NAME}: Environment variables ${variable.VAR_NAME}: API Proxy veya Global Variables ${vault.PATH}: Vault entegrasyonu (HashiCorp Vault, AWS Secrets Manager vb.) ${header.HEADER_NAME}: Request header’larından değer alma
Güvenlik	Credential’lar log’larda görünür mü?	Hayır, Apinizer default olarak credential field’larını log’lardan maskeler. Ancak custom log policy kullanıyorsanız masking kurallarını kontrol edin.
Güvenlik	Digest authentication’da nonce ve created nasıl oluşturuluyor?	Apinizer otomatik olarak her istek için unique nonce (Base64 encoded random değer) ve created (ISO 8601 timestamp) değerleri oluşturur. Manual müdahale gerekmez.
Hata Giderme	”Authentication credentials are missing or invalid” hatası alıyorum	Şunları kontrol edin: 1) Conditional expression’larınız doğru mu? (hiçbiri match etmiyorsa hata alırsınız) 2) Variable expression’lar çözümlenebiliyor mu? 3) Backend’in beklediği format ile Send Type uyumlu mu? 4) Field name’ler ve injection path’ler doğru mu? Debug için API logs ve policy execution logs’ları inceleyin.