401 Unauthorized: Ne Anlama Gelir, Nasıl Düzeltilir

401 Unauthorized ne anlama gelir

RFC 9110, 401'i, ya hiç sağlanmadığı ya da sağlananın geçemediği için kimlik doğrulama gerektiren bir istek olarak tanımlar. Bir 401 yanıtı, Basic, Bearer, veya Digest gibi sunucunun beklediği şemayı adlandıran bir WWW-Authenticate başlığı içermelidir. O başlık, çoğu kişinin gözden kaçırdığı ipucudur: size sunucunun tam olarak ne tür bir kimlik bilgisi istediğini söyler, ki bu genellikle tahmin etmekten daha hızlıdır.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token"

Hata nasıl görünür

Bir tarayıcıda, HTTP Basic kimlik doğrulaması tarafından korunan bir 401, sitenin oluşturduğu bir sayfayı değil, yerel kullanıcı adı ve şifre istemini tetikler. Buna karşılık, bir JSON API'sinden gelen bir 401, genellikle sadece bir ağ sekmesinde veya uygulamanın onun için oluşturduğu bir hata bildiriminde görünür, çünkü bir Bearer token başarısızlığı için varsayılan bir tarayıcı arayüzü yoktur. Komut satırından, kimlik bilgisi ve başlık tek bir istekte görünür:

curl -i -H "Authorization: Bearer eyJhbGciOi..." https://api.example.com/v1/account
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token", error_description="token is expired"

Sunucu ve uygulama günlükleri de tipik olarak nedeni kaydeder, örneğin "token expired," "signature invalid," veya "no Authorization header," ki bu tek başına genel durum kodundan daha hızlı nedeni daraltır.

401 Unauthorized'a ne sebep olur

Kabaca her birinin nedenin ne sıklıkla olduğu sırayla:

• Hiç kimlik bilgisi gönderilmedi. Oturumu kapatılmış bir oturum, eksik bir API anahtarı, veya Authorization başlığını hiç eklemeyen bir istemci.
• Süresi dolmuş bir token. Oturum çerezleri, OAuth erişim token'ları ve JWT'lerin hepsi bir ömür taşır, ve eski bir tane kullanan bir istemci, sadece dakikalar önce çalışmış olsa bile 401 alır.
• İstemci ve sunucu arasında saat sapması. Bir JWT'nin exp ve nbf talepleri sunucunun saatine karşı değerlendirilir. Yanlış saatli bir sunucu veya istemci, token'ın kendi matematiğine göre hâlâ geçerli olan bir token'ı reddedebilir, veya zaten süresi dolmuş bir tanesini kabul edebilir.
• Yanlış kimlik doğrulama şeması. Bearer bekleyen bir uç noktaya Authorization: Basic ... göndermek, veya tersi, bir başlık mevcut olsa bile başarısız olur.
• Yanlış yere yerleştirilmiş bir API anahtarı. Bazı API'ler anahtarı X-API-Key gibi özel bir başlıkta bekler, diğerleri Authorization'da, ve diğerleri bir sorgu parametresi olarak. Geçerli bir anahtarı yanlış yere koymak, hiç anahtar göndermemekle aynı görünür.
• Authorization başlığını çıkaran bir ters proxy veya ağ geçidi. Bazı proxy ve CDN yapılandırmaları, açıkça iletmedikleri başlıkları düşürür, ve tamamen geçerli bir kimlik bilgisi kaynağına asla ulaşmaz.
• İptal edilmiş kimlik bilgileri. Bir kullanıcı şifresini değiştirdi, bir yönetici bir API anahtarını döndürdü, veya bir token çıkışta açıkça geçersiz kılındı.

401'e karşı 403

İkisi de isteği reddettiği için sıklıkla karıştırılır, ama spesifikasyon net bir çizgi çizer. Bir 401, sunucunun sizin kimlik doğrulamanıza ihtiyaç duyduğu, ve geçerli bir kimlik bilgisinin sonucu değiştirebileceği anlamına gelir; WWW-Authenticate taşımalıdır. Bir 403, sunucunun tam olarak kim olduğunuzu anladığı ve kimlik doğrulamanın düzeltemeyeceği bir nedenle, bir rol veya plan kısıtlaması gibi, yine de reddettiği anlamına gelir. Yeniden giriş yapmak makul olarak yardımcı olacaksa, 401 olmalıdır. Kullanıcı zaten giriş yapmışsa ve basitçe izin verilmiyorsa, 403 olmalıdır, ancak pratikte birçok API her iki durum için de gevşek bir şekilde 401 kullanır.

Kimin hatası olduğunu nasıl anlarsınız

API'yi çağıran kişi sizsiniz, isteği temiz bir ortamdan taze bir kimlik bilgisiyle yeniden üretin; yeni verilmiş bir token başarılı olursa, eski tane basitçe süresi dolmuş veya iptal edilmişti. Yepyeni bir token da başarısız olursa, sunucunun bozuk olduğunu varsaymadan önce şemayı ve başlık adını API'nin belgelerine karşı kontrol edin. Hizmeti çalıştıran sizseniz ve kullanıcılar kendi hesabınızla yeniden üretemediğiniz 401'ler bildiriyorsa, "sunucu iyi durumda, bireysel token'lar eski" ile "kimlik doğrulama herkes için bozuk" durumunu ayırmanın en hızlı yolu, bilinen iyi bir kimlik bilgisiyle birden fazla konumdan aynı anda bir HTTP kontrolü çalıştırmak ve sonuçları karşılaştırmaktır.

401 Unauthorized nasıl düzeltilir

Bir ziyaretçiyseniz

1. Yeniden giriş yapın. Bir web uygulamasından gelen çoğu 401 basitçe süresi dolmuş bir oturumdur, ve giriş yapmak onu yeniler.
2. Kimlik doğruladıktan hemen sonra aynı giriş başarısız olmaya devam ediyorsa cihazınızdaki sistem saatini kontrol edin. Birkaç dakika sapan bir saat, bazı istemcilerde zaman tabanlı token'ları geçersiz kılabilir.
3. Döndürüldüğünden veya iptal edildiğinden şüpheleniyorsanız, entegrasyon kodunuzda bir hata olduğunu varsaymak yerine hesap ayarlarından bir API anahtarı veya token yeniden oluşturun.
4. Authorization başlığının gerçekten gönderilip gönderilmediğini, tarayıcınızın ağ sekmesini veya düz bir curl çağrısını kullanarak doğrulayın, çünkü bazı HTTP istemci kütüphaneleri bir yönlendirmede özel başlıkları sessizce düşürür.

Siteyi çalıştırıyorsanız

1. Herhangi bir şeyi değiştirmeden önce, belirli reddiye nedeni için WWW-Authenticate başlığını ve kendi günlüklerinizi okuyun; "expired," "invalid signature," ve "missing header" her biri farklı bir düzeltmeye işaret eder.
2. Token'ları veren ve doğrulayan sunucularda saat senkronizasyonunu kontrol edin. Her iki taraftaki NTP sapması, aksi takdirde rastgele görünen JWT reddiyelerinin klasik, aralıklı bir nedenidir.
3. Proxy'nin veya yük dengeleyicinin Authorization başlığını ilettiğini doğrulayın. İlgisiz bir nedenle eklenen bir kural, o sıçramanın arkasındaki her istek için onu sessizce çıkarabilir.
4. API belgelerinizde beklenen şemayı ve başlık adını açıkça belgeleyin, ve entegratörlerin tahmin etmek zorunda kalmaması için WWW-Authenticate başlığında belirli bir error_description döndürün.
5. Çağıranlar için önemli olduğu yerde kendi yanıtlarınızda 401'i 403'ten ayırt edin, böylece istemci kodu "token'ınızı yenileyin"i "buna asla izin verilmeyecek"ten ayırt edebilir.

Sessiz bir 401 kesintisi nasıl önlenir

Süresi dolmuş bir imzalama sertifikası, senkronizasyondan çıkmış bir saat, veya Authorization başlığını düşürmeye başlayan bir proxy değişikliği tarafından oluşturulan bir 401, bir çökme gibi görünmeyecektir. Hizmet, kendi kurallarına göre anında ve doğru şekilde yanıt verir, bu yüzden birisi fark edene kadar her çağıran için bozuk kalabilir. Kimlik doğrulanmış bir uç noktaya karşı canlı bir kimlik bilgisiyle çalıştırılan, beklenen durum kodu üzerinde bir doğrulaması olan bir HTTP kontrolü, bunu başladığı anda yakalar. Özellikle API'ler için, bunu yanıt gövdelerini de durum kodları kadar kontrol eden API izlemesi ile eşleştirmek, kimlik doğrulayan ama bozuk veri döndüren bir token'ı da yakalar.

İlgili hatalar

Kimlik bilgilerine bakılmaksızın sunucunun anladığı ve reddettiği istekler için 403 Forbidden'a, daha geniş istemci hataları ailesi için 4xx genel bakışına, ve bu partideki diğer kılavuzlara bakın: 405 Method Not Allowed, 422 Unprocessable Content.

Sık sorulan sorular

Başarıyla giriş yaptıktan hemen sonra neden 401 alıyorum?

Genellikle cihazınız ve sunucu arasında bir saat uyuşmazlığı, veya yeni verilen token yerine önbelleğe alınmış eski, artık geçersiz token'ı kullanan bir istemci. Sistem saatinizin doğru olduğunu ve yeni token'ın gerçekten gönderildiğini doğrulayın.

401, hesabımın hacklendiği anlamına mı gelir?

Tek başına değil. Neredeyse her zaman süresi dolmuş bir oturum, iptal edilmiş bir anahtar, veya yanlış gönderilmiş bir başlık anlamına gelir. Sadece kimlik bilgisinin çalışmayı durduracağını beklemiyorsanız ve neden durduğunu açıklayamıyorsanız bunu bir güvenlik endişesi olarak ele alın.

401 ile TLS katmanında bir kimlik doğrulama hatası arasındaki fark nedir?

Bir TLS istemci sertifikası hatası, bağlantının hiç kurulmasını engeller, bu yüzden hiç HTTP durum kodu döndürülmez. Bir 401, bağlantının başarılı olduğu ve sunucunun tam bir HTTP isteği aldığı, sonra onu uygulama katmanında geçerli kimlik bilgilerinden yoksun olduğu için reddettiği anlamına gelir.

Bir giriş formu kendisi hiç 401 döndürmeli mi?

Hayır. Bir kullanıcı adı ve şifreyi değerlendiren bir giriş uç noktası, var olan bir isteği kimlik doğrulamıyor; orada yanlış bir şifre geleneksel olarak bir 400 veya bir hata yükü içeren bir 200'dür, çünkü uç noktanın tüm amacı kimlik doğrulanmamış denemeleri kabul etmek ve yargılamaktır.

Geçerli bir API anahtarı hâlâ 401 üretebilir mi?

Evet, yanlış başlıkta veya yanlış şemada gönderilirse, entegrasyonunuz eski tane önbelleğe aldıktan sonra döndürüldüyse, veya istek başlığı ileri iletmeden önce düşüren bir proxy üzerinden sunucuya ulaştıysa.