HTTP 401 ve 403 farkı, API'nin kimlik doğrulama bilgisini kabul edip etmediği ile isteğin hedef kaynağa veya işleme izin verilip verilmediğini ayırır. 401, hedef kaynak için geçerli kimlik doğrulama bilgisinin eksik, geçersiz ya da sunucu tarafından kabul edilmemiş olduğunu; 403 ise sunucunun isteği anlayıp kaynağı veya istenen işlemi yerine getirmeyi reddettiğini gösterir. 403 yanıtı, kimliğin her durumda kesin olarak bilindiğini tek başına kanıtlamaz.
API hata ayıklarken yalnızca durum koduna bakmak yerine WWW-Authenticate ve Authorization başlıklarını, yanıt gövdesini ve ilgili API'nin erişim politikasını birlikte incelemek gerekir. Aynı durum kodu, farklı sunucu uygulamalarında farklı ayrıntılarla dönebilir.
HTTP 401 ve 403 farkı nedir?
401 Unauthorized için temel soru, isteğin hedef kaynak adına geçerli bir kimlik doğrulama bilgisi taşıyıp taşımadığıdır. Kimlik bilgisi hiç gönderilmemiş, eksik, geçersiz veya sunucu tarafından kabul edilmemiş olabilir. HTTP semantiğine göre 401 yanıtı üreten sunucu, en az bir kimlik doğrulama sorgusu içeren WWW-Authenticate başlığını göndermelidir.
403 Forbidden ise sunucunun isteği anladığını, ancak isteği yerine getirmeyi reddettiğini belirtir. Gönderilen kimlik bilgileri erişim için yetersiz olabilir. Bununla birlikte, isteğin reddedilmesi kimlik bilgilerinden bağımsız bir kaynak veya sunucu politikası nedeniyle de gerçekleşebilir.
| Durum kodu | Temel anlam | İlk kontrol | Olası sonraki adım |
|---|---|---|---|
| 401 | Geçerli kimlik doğrulama bilgisi yok, eksik veya kabul edilmedi. | Authorization biçimi, tokenın varlığı ve WWW-Authenticate başlığı. |
Kimlik bilgisini düzeltmek, yenilemek veya beklenen şemayla yeniden göndermek. |
| 403 | İstek anlaşıldı, ancak kaynak veya işlem reddedildi. | Tokenın kabul edilip edilmediği, rol, izin, kapsam ve kaynak politikası. | Uygun izinleri veya kapsamı doğrulamak, hedef kaynağın politikasını incelemek. |
401 kimlik doğrulama, 403 yetkilendirme sorunudur.
Bu cümle yararlı bir hatırlatmadır, ancak tek başına kesin teşhis sağlamaz. 403, kimliğin kesin olarak doğrulandığını göstermez. HTTP standardı, isteğin kimlik bilgilerinden bağımsız nedenlerle de yasaklanabileceğini ve sunucunun yasaklanan bir kaynağın varlığını gizlemek için 404 döndürebileceğini belirtir. Bu nedenle durum kodunu, endpoint açıklaması ve yanıt ayrıntılarıyla birlikte yorumlamak gerekir.
Authorization başlığı ve Bearer token nasıl çalışır?
Authorization başlığı, istemcinin hedef kaynak için sunduğu kimlik doğrulama bilgisini taşıyan HTTP başlık alanıdır. Genel yapıda önce kimlik doğrulama şeması, ardından bu şemaya ait bilgi bulunur. Bearer kullanımında yaygın biçim Authorization: Bearer TOKEN şeklindedir. Buradaki Bearer bir şema adıdır. Başlığın gönderilmiş olması tek başına erişim izni verildiği anlamına gelmez; sunucu tokenı doğrulayıp hedef kaynak ve işlem için uygunluğunu ayrıca değerlendirebilir.
Token hiç yoksa, biçimi bozuksa, süresi dolmuşsa, iptal edilmişse veya başka bir nedenle geçersiz kabul edilmişse 401 yönü yaygın bir teşhis noktasıdır. Token kabul edilmiş olsa bile istenen işlem için gerekli rol, izin, kapsam veya kaynak erişimi bulunmuyorsa 403 yönü daha anlamlı olabilir. Bearer token tanımında invalid_token durumu için 401, insufficient_scope durumu için 403 önerilir.
Bu eşleşme her API için zorunlu bir davranış değildir. API'nin kullandığı kimlik doğrulama şeması, erişim politikası ve hata yanıtı biçimi farklı olabilir. Bu yüzden durum kodunu, WWW-Authenticate başlığını ve yanıt gövdesindeki hata ayrıntılarını birlikte kontrol et.
Aynı API isteği farklı kimlik ve izin durumlarında ne döndürür?
Aynı GET yöntemi ve kaynak yolu korunurken yalnızca kimlik doğrulama bilgisi veya izin durumu değişirse API yanıtı da değişebilir. 401, geçerli kimlik doğrulama bilgisinin eksik olduğu ya da kabul edilmediği; 403 ise sunucunun isteği anlayıp işlem için erişim vermediği durumu gösterir. 403, kimliğin her durumda bütün ayrıntılarıyla bilindiği anlamına gelmez. Aşağıdaki örnekler öğretici bir senaryodur; gerçek API'nin belgeleri ve güvenlik politikası ayrıca incelenmelidir.
Kimlik doğrulama bilgisi gönderilmediğinde
GET /api/reports/annual HTTP/1.1
Host: api.example.test
Accept: application/json
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="reports"
Content-Type: application/json
{"message":"authentication required"}Beklenen durum 401'dir. İstek korumalı kaynağa yönelmiş, ancak kimlik doğrulama bilgisi göndermemiştir. Düzeltme, API'nin beklediği yönteme göre doğru Authorization başlığını ve geçerli bilgiyi eklemektir. WWW-Authenticate başlığı, kullanılabilecek doğrulama şemasını bildirir.
Token geçerli, rol yetersiz olduğunda
GET /api/reports/annual HTTP/1.1
Host: api.example.test
Accept: application/json
Authorization: Bearer reader-token-example
HTTP/1.1 403 Forbidden
Content-Type: application/json
{"error":"insufficient_permissions"}Bu senaryoda token sunucu tarafından kabul edilmiş, fakat rolü rapora erişmek için yetersizdir. Bu nedenle 403 döner. Düzeltme yönü, rolü, kapsamı ve hesabın kaynak üzerindeki iznini kontrol etmektir; aynı kimlik bilgisiyle isteği yinelemek tek başına yetkiyi değiştirmez.
Gerekli erişim bulunduğunda
GET /api/reports/annual HTTP/1.1
Host: api.example.test
Accept: application/json
Authorization: Bearer reports-reader-token
HTTP/1.1 200 OK
Content-Type: application/json
{"report":"annual","status":"available"}Gerekli erişim bulunduğunda istek başarıyla işlenir ve örnekte 200 OK döner. Kimlik doğrulama veya izin yönünden ek düzeltme gerekmez; istemci yanıt gövdesini gerçek API'nin sözleşmesine göre işlemelidir.
401, 403 ve 404 için hangi düzeltme anlamlıdır?
Düzeltmeyi durum kodunun işaret ettiği katmana göre seç: 401'de kimlik doğrulamayı, 403'te izni, 404'te kaynak yolunu ve görünürlük politikasını incele.
401 için kimlik doğrulama bilgisini denetle
Önce Authorization başlığının beklenen şemayı, ayır
Üç adımlı karar ağacıyla API hatası nasıl teşhis edilir?
401, 403 veya 404 yanıtını gördüğünde teşhisi üç aşamada ilerletmek, rastgele değişiklik yapmaktan daha sağlıklı bir yol sunar.
- İstemciyi kontrol et. Belirti: İstek beklenmedik bir durum koduyla dönüyor olabilir. Kontrol: HTTP yöntemini, adresi, kaynak kimliğini ve başlıkların biçimini incele. Özellikle
Authorization: Bearer tokenyapısında şema adının ve token değerinin doğru aktarılıp aktarılmadığını kontrol et. Sonraki eylem: Yanlış yöntem, adres veya başlık varsa isteği düzelterek yeniden gönder. - Kimlik doğrulamayı kontrol et. Belirti: Authorization başlığı gönderildiği hâlde 401 alınmasıdır. Kontrol: Tokenın gerçekten bulunup bulunmadığını, boş ya da kesilmiş olmadığını ve sunucu tarafından bu istek için kabul edilip edilmediğini incele. Sonraki eylem: Gerekirse doğru kimlik doğrulama akışıyla yeni bir token al, ancak yalnızca durum koduna bakarak token yenilemeye geçme.
- Rol veya izni kontrol et. Belirti: Kimlik doğrulama kabul edildikten sonra 403 alınması ya da belirli bir kaynağa erişilememesidir. Kontrol: Rolü, kapsamı ve istenen kaynağa erişim koşullarını incele. Sonraki eylem: Gerekli izinleri, doğru kaynak kimliğini ve API belgesindeki işlem koşullarını doğrula. 403 yanıtı, kimliğin her durumda kesin olarak bilindiğini tek başına göstermez.
Bu karar ağacında durum kodu yalnızca başlangıç işaretidir. Yanıt gövdesi, yanıt başlıkları, API belgesi ve erişilebiliyorsa sunucu kayıtları birlikte değerlendirilmelidir. Aynı durum kodu, farklı uygulamalarda farklı güvenlik politikalarının sonucu olabilir.
JavaScript ile durum kodu nasıl yorumlanır?
Aşağıdaki bağımlılıksız fonksiyon, durum kodu için kesin teşhis koymaz. Yalnızca ilk olarak hangi noktayı kontrol etmen gerektiğini belirtir.
function yorumlaDurumKodu(status) {
if (status >= 200 && status < 300) {
return "İlk kontrol: HTTP yanıtı başarılı sınıfta; veri biçimini ve uygulama sonucunu incele.";
}
if (status === 401) {
return "İlk kontrol: kimlik doğrulama bilgisinin biçimini ve kabul edilmesini incele.";
}
if (status === 403) {
return "İlk kontrol: rol, kapsam ve kaynak erişimini incele.";
}
if (status === 404) {
return "İlk kontrol: yöntem, adres ve kaynak kimliğini doğrula.";
}
return "İlk kontrol: yanıt gövdesini, başlıkları ve API belgesini incele.";
}
console.log("401:", yorumlaDurumKodu(401));
console.log("403:", yorumlaDurumKodu(403));
console.log("404:", yorumlaDurumKodu(404));
console.log("200:", yorumlaDurumKodu(200));Bu çağrılar için beklenen konsol çıktısı şöyledir:
401: İlk kontrol: kimlik doğrulama bilgisinin biçimini ve kabul edilmesini incele.
403: İlk kontrol: rol, kapsam ve kaynak erişimini incele.
404: İlk kontrol: yöntem, adres ve kaynak kimliğini doğrula.
200: İlk kontrol: HTTP yanıtı başarılı sınıfta; veri biçimini ve uygulama sonucunu incele.Fonksiyon yalnızca ön sınıflandırma yapar. Özellikle 403 yanıtından kimliğin kesin olarak bilindiği sonucunu çıkarmak doğru değildir. Yanıtın içeriği ve uygulamanın davranışı ayrıca incelenmelidir.
Küçük deneylerle yazılım temellerini çalışma yaklaşımını değerlendirirken birebir yazılım öğrenme seçenekleri için de aynı ölçüt kullanılabilir: açıklama, uygulama ve geri bildirim birlikte düşünülmelidir.
Sık Sorulan Sorular
Authorization başlığı gönderildiği hâlde neden 401 yanıtı alınabilir?
Authorization başlığının bulunması tek başına yeterli değildir. Şema adı hatalı olabilir, Bearer ifadesi eksik olabilir, token boş, kesilmiş, süresi geçmiş veya bu sunucu için kabul edilmeyen bir yapıda olabilir. Ayrıca istemci ile sunucu arasındaki bir katman başlığı değiştirmiş ya da sunucuya ulaştırmamış olabilir.
Geçerli bir Bearer token neden 403 yanıtı üretebilir?
Tokenın sunucu tarafından kabul edilmesi, her kaynağa veya işleme izin verildiği anlamına gelmez. Tokenla ilişkilendirilen rol, kapsam ya da kaynak erişimi istenen işlem için yetersiz olabilir. Bazı uygulamalar güvenlik politikaları nedeniyle yetki durumlarını farklı biçimlerde de yanıtlayabilir.
401 yanıtında tokenı yenilemek her zaman doğru mudur?
Hayır. Önce adresi, yöntemi, başlık biçimini ve tokenın hangi bağlam için üretildiğini kontrol et. Sorun süresi dolmuş bir token ise yenileme uygun olabilir. Ancak eksik başlık, yanlış adres veya hatalı token biçimi varsa yeni token almak aynı hatayı sürdürebilir.
Bir kaynağın bulunmadığı mı, güvenlik amacıyla gizlendiği mi nasıl anlaşılır?
Yalnızca 404 durum koduna bakarak kesin ayrım yapılamaz. API belgesindeki adresi ve yöntemi, yanıt gövdesini, başlıkları ve yetkili bir test senaryosundaki davranışı karşılaştır. Erişebiliyorsan sunucu kayıtları da yardımcı olur. Bazı uygulamalar kaynakların varlığını açığa çıkarmamak için dışarıya bulunamadı yanıtı verebilir.
401, 403 ve 404 yanıtlarını ayırırken kodu tek başına değil, isteğin biçimi, kimlik doğrulama durumu ve kaynak erişimiyle birlikte değerlendirmek daha sağlıklı bir teşhis sağlar.
