Her API ekibi aynı duvara çarpar. Uç noktalar tek başına çalışır, sonra birisi OAuth 2.0'ı açar ve test paketinin yarısı 401 hatası dönmeye başlar. Birdenbire yetkilendirme sunucuları, kısa ömürlü erişim jetonları ve kapsamlarla uğraşıyor olursunuz ve bir cURL yanıtından jetonları elle bir başlık alanına kopyalamak üçüncü denemede sıkıcı hale gelir.
Çözüm, testlerinizde kimlik doğrulamayı atlamak değildir. Jeton yönetimini test kurulumunun bir parçası haline getirerek manuel iş olmaktan çıkarmaktır. Bu kılavuz, neredeyse her test planında karşılaşacağınız iki akışı ele almaktadır: bir kullanıcı adına hareket eden API'ler için OAuth yetkilendirme kodu akışı (PKCE ile) ve makineden makineye çağrılar için istemci kimlik bilgileri akışı. Önce tüm yetkilendirme türlerinin haritasını görmek isterseniz, OAuth 2.0 akışlarına genel bakış makalemiz hepsini anlatmaktadır.
Daha sonra pratik kısma geçiyoruz: Apidog'da OAuth 2.0 kimlik doğrulamasını yapılandırma, bir jetonu bir kez alıp istekler arasında yeniden kullanma, süresi dolan jetonların kendi kendine yenilenmesine izin verme, klasör düzeyinde kimlik doğrulamasını devralma ve güvenlik denetiminizin isteyeceği hata yollarını test etme.
API Testleri İçin Önemli Olan İki Akış
OAuth 2.0 birkaç yetkilendirme türü tanımlar, ancak günlük API testleri için zamanınızın çoğunu bunlardan ikisiyle geçireceksiniz. Tek bir soruya göre seçin: API bir kullanıcı adına mı, yoksa bir hizmet adına mı hareket ediyor?
PKCE ile Yetkilendirme Kodu Akışı
Yetkilendirme kodu akışı, bir kullanıcıya bağlı bir jeton almak için standart yoldur. İstemci kullanıcıyı yetkilendirme sunucusuna gönderir, kullanıcı giriş yapar ve onay verir, sunucu tek kullanımlık bir kodla geri yönlendirir ve istemci bu kodu jeton uç noktasında bir erişim jetonu ile değiştirir. RFC 6749, tüm bu dansı bölüm 4.1'de tanımlar.
PKCE (Proof Key for Code Exchange, RFC 7636) değişimi güçlendirir. İstemci rastgele bir doğrulayıcı üretir, yetkilendirme isteğiyle birlikte hashlenmiş bir meydan okuma gönderir, ardından kodu kullanırken orijinal doğrulayıcıya sahip olduğunu kanıtlar. Kodu ele geçiren bir saldırgan onu kullanamaz. PKCE mobil uygulama düzeltmesi olarak başladı, ancak oauth.net'in güncel rehberliği, gizli istemciler de dahil olmak üzere her yetkilendirme kodu değişimi için bunu öneriyor.
Uç noktanın davranışı kullanıcının kim olduğuna bağlı olduğunda bu akışı kullanın: yalnızca çağıranın siparişlerini döndüren GET /orders, rol tabanlı yönetici uç noktaları, kullanıcı başına hız limitleri.
İstemci Kimlik Bilgileri Akışı
OAuth 2.0 istemci kimlik bilgileri yetkilendirmesi, kullanıcıyı tamamen atlar. İstemci kendi kimliği ve sırrıyla kimlik doğrulaması yapar ve uygulamanın kendisini temsil eden bir jeton alır. Jeton uç noktasına tek bir POST, tarayıcı yok, yönlendirme yok:
curl -X POST https://auth.example.com/oauth/token \
-d grant_type=client_credentials \
-d client_id=orders_service \
-d client_secret=s3cr3t_value \
-d scope="orders:read orders:write"
Bu, makineden makineye API'ler için kullanılan akıştır: dahili mikro hizmetler, cron işleri, bir dağıtım API'sini çağıran CI ardışık düzenleri. Ayrıca otomatik testin temel taşıdır, çünkü döngüde insan müdahalesi gerektirmez. Test ortamınız bir test istemcisi sağlamanıza izin veriyorsa, kullanıcı kimliğinin test edilen şey olduğu durumlar dışında her şey için istemci kimlik bilgilerini kullanın.
Apidog'da OAuth 2.0 Kimlik Doğrulamasını Yapılandırma
Apidog, OAuth 2.0'ı birinci sınıf bir kimlik doğrulama türü olarak ele alır. Bunu bir isteğin veya klasörün Kimlik Doğrulama sekmesinde bir kez yapılandırırsınız ve platform jetonları almayı, eklemeyi ve yenilemeyi yönetir. Desteklenen yetkilendirme türleri arasında Yetkilendirme Kodu, Yetkilendirme Kodu (PKCE ile), İstemci Kimlik Bilgileri, Parola Kimlik Bilgileri ve Örtük yer alır.
Yukarıdaki iki akış için, kurgusal bir sipariş yönetim API'si kullanarak kurulum aşağıdadır.
İstemci Kimlik Bilgileri Kurulumu
İsteği (veya daha iyisi, klasörü; aşağıda daha fazlası) açın, kimlik doğrulama türünü OAuth 2.0 olarak değiştirin ve yetkilendirme türü olarak İstemci Kimlik Bilgileri'ni seçin. Şunları doldurun:
- Erişim Jetonu URL'si:
https://auth.example.com/oauth/token - İstemci Kimliği:
orders_service - İstemci Sırrı: sağladığınız sır
- Kapsam (Scope):
orders:read orders:write(gelişmiş seçenekler altında ayarlanır)
Apidog, kimlik bilgilerini iki yolla sunmanıza olanak tanır: bir Basic Auth başlığı olarak veya istek gövdesinde. Yetkilendirme sunucunuzun beklediği ne olursa olsun eşleştirin; Auth0 ve Okta her ikisini de kabul eder, ancak bazı şirket içi sunucular yalnızca gövdeyi ayrıştırır.
Jeton Al'a tıklayın. Apidog, jeton uç noktasını çağırır, sonucu saklar ve jetonu geçerlilik süresiyle birlikte gösterir. Bundan sonra, her gönderim jetonu Bearer önekiyle Authorization başlığına ekler. Kopyala-yapıştır yok, {{token}} değişkeni tesisatı yok.
PKCE ile Yetkilendirme Kodu Kurulumu
Kullanıcı bağlamı testi için, yetkilendirme türü olarak Yetkilendirme Kodu'nu (PKCE ile) seçin. PKCE, Apidog'da ayrı bir yetkilendirme seçeneğidir, bir onay kutusu değildir. Birkaç ek alan doldurmanız gerekecektir:
- Yetkilendirme URL'si:
https://auth.example.com/oauth/authorize - Erişim Jetonu URL'si:
https://auth.example.com/oauth/token - Geri Çağırma URL'si: sağlayıcınıza kayıtlı yönlendirme URI'si
- İstemci Kimliği ve İstemci Sırrı: OAuth uygulama kaydınızdan
Jeton Al'a tıklayın ve Apidog, giriş sayfasına işaret eden bir tarayıcı penceresi açar. Test kullanıcınız olarak giriş yapın, onay ekranını onaylayın ve jeton geri gelir ve daha öncekiyle aynı yönetilen yuvaya düşer. Sağlayıcınız erişim jetonunun yanı sıra bir OpenID Connect ID jetonu döndürürse, Kullanılan Jeton Türü seçeneği hangisinin ekleneceğini değiştirmenize olanak tanır; test edilen API kimlik jetonlarını doğruladığında kullanışlıdır.
Pratik bir ipucu: kapsamanız gereken her rol için (alıcı, yönetici, salt okunur denetçi) özel bir test kullanıcısı bulundurun. Her kullanıcı olarak bir jeton almak ve aynı senaryoyu yeniden çalıştırmak, rol tabanlı erişim kurallarını doğrulamak için en hızlı yoldur.
Jeton Yeniden Kullanımı ve Otomatik Yenileme
Erişim jetonlarının süresi genellikle bir saat içinde dolar. Apidog bunu ele almadan önce, süresi dolmuş bir jeton başarısız bir çalıştırma ve manuel yeniden alım anlamına geliyordu, ki bu tam da ekiplerin görmezden gelmeyi öğrendiği türden hatalı bir hatadır.
Şimdi Apidog, yetkilendirme sunucusu bir yenileme jetonu verdiğinde OAuth 2.0 jetonlarını kendi başına yeniler; bu yetenek Haziran güncellemesinde çıktı. Saklanan erişim jetonunun süresi dolduğunda, Apidog yeni bir tane almak için yenileme jetonunu kullanır ve göndermeden önce onu değiştirir. Sağlayıcınız iki uç noktayı ayırıyorsa, gelişmiş ayarlarda özel bir yenileme jetonu URL'sine de işaret edebilirsiniz.
İstemci kimlik bilgileri için, birçok sunucu yenileme jetonlarını tamamen atlar (istemci her an yeniden kimlik doğrulaması yapabildiğinden spesifikasyon buna izin verir). Pratikte bu zarar vermez: Jeton Al ile yeniden almak tek bir tıklama, ve planlı veya CI çalıştırmaları her çalıştırmanın başlangıcında yeni bir jeton isteyebilir.
Klasör Düzeyinde Kimlik Doğrulamayı Devralma
Her istekte OAuth yapılandırmak yanlış bir yaklaşımdır. Apidog, bir klasöre kimlik doğrulama ayarlamanıza izin verir ve içindeki istekler yapılandırmayı ebeveynlerinden devralır. "Siparişler API'si" klasörünüzde OAuth 2.0'ı bir kez ayarlayın ve altındaki her istek, takım arkadaşlarınızın bir sonraki sprint'te ekleyeceği yenileri de dahil olmak üzere, aynı yönetilen jetonu gönderir.
Bu, çok adımlı test senaryolarında en çok önem taşır. Bir ödeme senaryosu POST /carts, POST /carts/{id}/items ve POST /orders'ı zincirleyebilir. Klasör düzeyinde kimlik doğrulama ile, üç adım da tek bir jetonu ve tek bir yapılandırmayı paylaşır. Jeton senaryonun ortasında süresi dolduğunda, otomatik yenileme bunu kapsar. Ve güvenlik ekibiniz istemci sırrını değiştirdiğinde, kırk istek yerine bir klasörü güncellersiniz.
İstekler, ebeveyni geçersiz kılma seçeneğini korur, bu da negatif testler için tam da istediğiniz şeydir. Şimdi bunlara daha yakından bakalım.
Hata Yollarını Test Etme
Başarılı yol OAuth testleri, jeton hattınızın çalıştığını kanıtlar. Hata yolu testleri, API'nizin kimlik doğrulamayı uyguladığını kanıtlar. Bunları atlarsanız, çerçevenin varsayılanlarına güveniyorsunuz demektir. Otomatikleştirmeye değer üç durum aşağıdadır; her durum kodunun ne anlama gelmesi gerektiğine ilişkin bir hatırlatma için, API anahtarları ve taşıyıcı jetonlar karşılaştırmamıza bakın.
Süresi Dolan veya Eksik Jeton: 401 Bekle
Senaryonuzdaki bir isteği çoğaltın ve devraldığı kimlik doğrulamasını ya kimlik doğrulama olmadan ya da "Bearer expired_token_do_not_rotate" gibi sabit kodlanmış, uzun süre önce süresi dolmuş bir taşıyıcı jetonla geçersiz kılın. Şunları doğrulayın:
- Durum kodu
401'e eşit WWW-Authenticateyanıt başlığı mevcut (RFC 6749'un eşlikçisi RFC 6750 bunu bekler)- Gövde, yığın izlerini veya dahili ana bilgisayar adlarını sızdırmıyor
Burada bir 200 kritik bir hatadır. Bir 403, bir bilet gerektiren bir tasarım kokusudur: sunucu "kim olduğunu bilmiyorum" ile "kim olduğunu biliyorum ve hayır"ı ayırt etmelidir.
Yanlış Kapsam: 403 Bekle
orders:read ile sınırlı ikinci bir test istemcisi sağlayın, jetonunu alın ve POST /orders gibi bir yazma uç noktasını çağırın. Durumun 403 olduğunu ve API'niz RFC 6750'yi takip ediyorsa, WWW-Authenticate başlığının error="insufficient_scope" içerdiğini doğrulayın. Bu test, bazı rotalar için ağ geçidinde kapsamların kontrol edildiği ve diğerlerinde unutulduğu klasik yanlış yapılandırmayı yakalar. Kapsamlar ekibiniz için yeniyse, OAuth 2.0 kapsamları açıklandı makalesi bunları nasıl dilimleyeceğinizi kapsar.
Geçersiz İstemci: Temiz Bir Jeton Uç Noktası Hatası Bekle
Sahte bir client_secret ile doğrudan https://auth.example.com/oauth/token adresine bir istek gönderin. RFC 6749 bölüm 5.2'ye göre, sunucu "error": "invalid_client" içeren bir JSON gövdesiyle birlikte 400 (veya başarısız istemci kimlik doğrulaması için 401) dönmelidir. Her ikisini de doğrulayın. Yetkilendirme sunucuları da API'dir ve hata sözleşmeleri yüzeyinizin bir parçasıdır.
Test Senaryolarında Jeton Yanıtlarını Doğrulama
Jeton uç noktası, geçersiz istemci durumunun ötesinde kendi kapsamını hak ediyor. Test senaryonuza doğrudan jeton uç noktasını çağıran bir adım ekleyin, ardından yanıta doğrulama ekleyin:
access_tokenmevcut ve boş değiltoken_type,bearer'a eşit (spesifikasyona göre büyük/küçük harf duyarsız)expires_in0'dan büyük ve politikanız dahilinde, örneğin 3600'den fazla değilscopeistenenle eşleşiyor, sunucuların yetkilendirmeleri sessizce daraltmasını yakalıyor
Apidog'un test senaryoları, bunları yanıt JSON'una görsel doğrulama olarak eklemenize olanak tanır, komut dosyası gerekmez ve yönetilen kimlik doğrulamayı kullanmak yerine ham anlaşmayı test etmek istediğinizde access_token'ı bir sonraki adım için bir değişkene çıkarabilirsiniz. Senaryoyu CI çalıştırmanıza bağlayın ve yanlış davranan bir yetkilendirme sunucusu, üretimde gizemli bir 401 olarak ortaya çıkmak yerine derlemenin başarısız olmasına neden olur.
Tüm döngü şöyle görünür: başarılı yol için klasör düzeyinde OAuth 2.0 yapılandırması, 401 ve 403 durumları için istek başına geçersiz kılmalar ve jeton uç noktasının sözleşmesini vuran bir senaryo. Bu, PKCE ile yetkilendirme kodu aracılığıyla kullanıcı bağlamı API'lerini ve istemci kimlik bilgileri aracılığıyla hizmetten hizmete API'lerini kapsar, jeton yenileme sizin için halledilir. Apidog'u indirin ve ücretsiz deneyin; OAuth 2.0 kimlik doğrulama türü ücretsiz planda çalışır, böylece dakikalar içinde kendi jeton uç noktanıza işaret edebilirsiniz.
SSS
API testi için hangi OAuth akışını kullanmalıyım?
Makineden makineye her şey ve çoğu otomatik paket için istemci kimlik bilgilerini kullanın, çünkü tarayıcı etkileşimi gerektirmez. Test kullanıcı kimliğine bağlı olduğunda PKCE ile yetkilendirme kodu akışını kullanın: kullanıcı başına veri izolasyonu, rol kontrolleri veya onay davranışı. Yeni test planlarında örtük ve parola yetkilendirmelerinden kaçının; her ikisi de güncel OAuth rehberliğinde önerilmemektedir.
Apidog'da süresi dolan bir jetonu otomatik olarak nasıl yenilerim?
Kimlik Doğrulama sekmesinde OAuth 2.0'ı yapılandırın ve Jeton Al ile bir jeton alın. Yetkilendirme sunucusu bir yenileme jetonu döndürdüğünde, Apidog siz yeniden kimlik doğrulaması yapmadan erişim jetonunu süresi dolduğunda yeniler ve sağlayıcınız kullanıyorsa gelişmiş ayarlarda ayrı bir yenileme jetonu URL'si belirleyebilirsiniz. Yenileme jetonları olmayan istemci kimlik bilgileri kurulumları için, Jeton Al'ı yeniden çalıştırmak yeni bir tane verir.
Bir senaryodaki her istek tek bir OAuth jetonunu paylaşabilir mi?
Evet. OAuth 2.0 yapılandırmasını üst klasöre ayarlayın ve içindeki istekler bunu devralır, böylece çok adımlı bir senaryo tek bir yönetilen jeton altında çalışır. Bireysel istekler yine de klasör yapılandırmasını geçersiz kılabilir, bu da negatif testleri (süresi dolmuş jeton, yanlış kapsam) aynı senaryoya nasıl dahil edeceğinizdir.
OAuth korumalı API'lerde 401 ile 403 ne anlama gelmeli?
Kimlik doğrulama başarısız olduğunda 401 döndürün: jeton eksik, süresi dolmuş veya hatalı biçimlendirilmiş. Jeton geçerli ancak yetkisi eksik olduğunda 403 döndürün, örneğin eksik bir kapsam. Bunları karıştırmak istemci yeniden deneme mantığını bozar, çünkü 401 istemciye yeniden kimlik doğrulaması yapmasını söylerken, 403 durmasını söyler. JWT kimlik doğrulamasını test etme kılavuzumuz, jetonun kendisini doğrulamayı derinlemesine inceler.