OAuth sağlayıcılarına mektup

 (pilcrowonpaper.com)
1 puan yazan GN⁺ 2024-12-13 | 2 yorum | WhatsApp'ta paylaş

  • OAuth sağlayıcılarına mektup

    • GitHub

      • Token endpoint'i hata durumlarında da 200 durum kodu döndürüyor
      • Hata yanıtları 400 veya 401 durum kodu kullanmalı

    • Facebook

      • Token endpoint'i özel hata yanıtları döndürüyor
      • error alanı içeren bir JSON nesnesi olmalı

    • TikTok

      • Sunucu client_id yerine client_key parametresini kullanıyor
      • Spesifikasyondan sapmasının bir gerekçesi yok

    • Strava

      • Sunucu kapsam parametresinde virgülle ayrılmış bir liste kullanıyor
      • Boşlukla ayrılmış bir liste olmalı

    • Naver

      • Sunucu token sona erme süresini string olarak döndürüyor
      • Bu, spesifikasyona uyumun ötesinde bir sorun

    • Çeşitli OAuth sağlayıcıları

      • İstemci kimlik doğrulaması için client_secret parametresi yerine HTTP Basic authentication'ı desteklemeli
      • OAuth 2.1 standardında HTTP Basic authentication isteğe bağlı olsa da, PKCE zorunlu olmasına rağmen çoğu sağlayıcı bunu kullanmıyor

    • AWS

      • OAuth istemci kütüphanesiyle birlikte kullanımda birden fazla hata bildirimi alındı, ancak sorun yeniden üretilemediği için ilgili içerik kaldırıldı

İlgili okumalar

2 yorum

 
rikko 2024-12-13

Kamuya yönelik hizmet projeleri geliştirirken, sadece OAuth (OIDC) işlevini uygulamaya koymak için tam 1 ay harcadığım bir deneyimim var...

Harici kütüphane kullanamadığımız için her şeyi tek tek kendimiz uygulamak zorunda kaldık; ama OAuth standardına düzgün uyanlar Kakao ve Google dışında yoktu...

Naver ise, yani giriş yapılabiliyorsa sorun yok seviyesindeydi; bunu kullanmak doğru mu diye düşündürüyordu. Apple ise şimdi bile nasıl uyguladığımı hatırlamayacak kadar zordu; mevcut OAuth kodunun 3 katından fazla uygulama kodu gerektirmişti.

Yukarıdaki yazıda olduğu gibi yanıt kodlarının tam bir facia olduğu durumlar da vardı; hatta 418 (I'm a teapot) dönen sağlayıcı bile görmüştüm.
Böyle deneyimler yaşayınca ben de sosyal giriş gibi özellikler ne kadar kullanışlı olsa da kullanmamaya başladım...
 
GN⁺ 2024-12-13
Hacker News görüşü

  • Bir kullanıcı şirketin intranetinde bir OAuth sunucusu uygulamış. Başka bir ekip resmî spesifikasyona uymadan giriş uygulaması talep etmiş ve sonunda resmî olmayan bir OAuth varyantı ortaya çıkmış

  • OAuth kullanılırken birden fazla sağlayıcı ve e-posta ile kayıt seçeneği olduğunda, daha önce hangi yöntemle giriş yapıldığını hatırlamayıp yanlışlıkla yeni bir hesap oluşturma durumu yaşanabiliyor

  • Bir yıl önce 100 popüler API için OAuth uygulanmıştı ve deneyim, OP'nin anlattığına benziyordu

  • Birçok sağlayıcı prompt=select_account desteği vermiyor veya kullanıcının hangi hesapla giriş yapacağını seçmesini istemiyor. Bu özellikle OIDC'de sorun oluyor

  • AWS ile ilgili bir hata raporu alınmış ama yeniden üretilememiş, bu yüzden ilgili bölüm gönderiden çıkarılmış. Yine de genel bir sorun kontrol listesi olarak faydalı olabilirdi

  • Resmî bir test paketi olsa açık standart uygulamalarına yardımcı olurdu. Spesifikasyonu takip etmek zor olduğu için doğrulama yapılabilecek bir test paketi faydalı olurdu

  • Facebook'un sorunu, mevcut hizmet çerçevesini kullanarak OAuth2 kodlamış olmaları ama spesifikasyona uyduramamış olmaları gibi görünüyor. Bu, scripting'deki yaygın sorunlara benziyor

  • Bazı sağlayıcılar spesifikasyona uymayıp refresh token için ayrı bir endpoint seçmiş

  • OIDC/OAuth sağlayıcılarına SCIM desteğini düzgün vermeleri ve sistemlerini "API öncelikli" düşünceyle tasarlamaları çağrısı yapılıyor. GNAP'e geçmeden önce kararlarını yeniden gözden geçirmeleri gerekiyor