Surat untuk penyedia OAuth

 (pilcrowonpaper.com)
1 poin oleh GN⁺ 2024-12-13 | 2 komentar | Bagikan ke WhatsApp

  • Surat untuk penyedia OAuth

    • GitHub

      • Endpoint token mengembalikan kode status 200 bahkan saat terjadi kesalahan
      • Respons kesalahan seharusnya menggunakan kode status 400 atau 401

    • Facebook

      • Endpoint token mengembalikan respons kesalahan kustom
      • Seharusnya berupa objek JSON dengan field error

    • TikTok

      • Server menggunakan parameter client_key alih-alih client_id
      • Tidak ada alasan untuk menyimpang dari spesifikasi

    • Strava

      • Server menggunakan daftar yang dipisahkan koma untuk parameter scope
      • Seharusnya berupa daftar yang dipisahkan spasi

    • Naver

      • Server mengembalikan waktu kedaluwarsa token sebagai string
      • Ini masalah yang melampaui sekadar kepatuhan terhadap spesifikasi

    • Berbagai penyedia OAuth

      • Harus mendukung autentikasi dasar HTTP alih-alih parameter client_secret untuk autentikasi klien
      • Dalam standar OAuth 2.1, autentikasi dasar HTTP bersifat opsional, tetapi meskipun PKCE diwajibkan, sebagian besar penyedia tetap tidak menggunakannya

    • AWS

      • Pernah menerima beberapa laporan bug saat digunakan bersama library klien OAuth, tetapi karena masalahnya tidak dapat direproduksi, bagian terkait dihapus

Bacaan terkait

2 komentar

 
rikko 2024-12-13

Saat membangun proyek layanan publik pemerintah, saya pernah punya pengalaman menghabiskan waktu sebulan penuh hanya untuk mengimplementasikan fitur OAuth (OIDC)...

Karena tidak bisa menggunakan library eksternal, saya harus mengimplementasikan semuanya satu per satu, dan selain Kakao atau Google, tidak ada yang benar-benar mematuhi standar OAuth...

Naver ya begitu, levelnya seperti asal login bisa maka tidak masalah, sampai-sampai saya ragu apakah pantas dipakai, dan Apple bahkan sampai sekarang pun saya tidak ingat bagaimana dulu saya mengimplementasikannya karena butuh kode implementasi lebih dari 3 kali lipat dibanding sumber OAuth yang sudah ada.

Seperti di teks utama di atas, ada juga kasus kode responsnya berantakan, dan bahkan ada penyedia yang sampai membalas dengan 418 (I'm a teapot).
Karena pengalaman-pengalaman seperti ini, saya jadi tidak memakai fitur seperti social login meskipun sebenarnya lebih praktis...
 
GN⁺ 2024-12-13
Komentar Hacker News

  • Seorang pengguna pernah mengimplementasikan server OAuth di intranet perusahaannya. Tim lain meminta implementasi login tanpa mengikuti spesifikasi resmi, dan pada akhirnya ia harus membuat varian OAuth tidak resmi

  • Saat menggunakan OAuth dengan beberapa penyedia dan opsi pendaftaran email, kadang pengguna tidak ingat sebelumnya login dengan cara apa sehingga tanpa sengaja membuat akun baru

  • Setahun lalu seseorang mengimplementasikan OAuth untuk 100 API populer, dan pengalamannya mirip dengan yang dijelaskan OP

  • Banyak penyedia tidak mendukung prompt=select_account atau tidak meminta pengguna memilih akun yang akan dipakai untuk login. Ini terutama menjadi masalah di OIDC

  • Ada laporan bug terkait AWS, tetapi tidak bisa direproduksi sehingga bagian itu dihapus dari postingan. Namun, itu sempat berguna sebagai daftar periksa masalah umum

  • Jika ada test suite resmi, itu akan membantu implementasi standar terbuka. Karena spesifikasinya sulit diikuti, test suite yang bisa dipakai untuk verifikasi akan sangat berguna

  • Masalah Facebook tampaknya adalah kasus ketika OAuth2 dikodekan menggunakan framework layanan yang sudah ada, tetapi tidak sesuai dengan spesifikasi. Ini mirip dengan masalah umum dalam scripting

  • Beberapa penyedia tidak mengikuti spesifikasi dan memilih endpoint terpisah untuk refresh token

  • Meminta para penyedia OIDC/OAuth untuk mendukung SCIM dengan benar dan merancang sistem dengan pola pikir "API-first". Perlu mempertimbangkan ulang keputusan sebelum beralih ke GNAP