OAuth sağlayıcılarına mektup

• 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ı

[rikko]

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...