GNAP: OAuth generasi berikutnya

Saat itu tahun 2012, dan protokol keamanan yang direvisi yang disebut OAuth 2 menyapu web, memungkinkan pengguna menggunakan penyedia keamanan untuk masuk ke situs web dengan mudah. Banyak sistem masuk tunggal, dari AWS Cognito hingga Okta, menerapkan OAuth. OAuth memungkinkan Anda untuk "mengautentikasi dengan Google" atau penyedia lain ke situs web atau aplikasi yang sama sekali berbeda.

Ini berfungsi seperti festival bir. Anda pergi ke meja dan mengautentikasi dengan ID Anda (dan sejumlah uang), dan mereka memberi Anda token. Dari sana, Anda pergi ke setiap tenda bir dan menukar token dengan bir. Pembuat bir individu tidak perlu memeriksa ID Anda atau bertanya apakah Anda membayar. Mereka hanya mengambil token dan memberimu bir. OAuth bekerja dengan cara yang sama, tetapi dengan situs web, bukan bir.

Sayangnya, OAuth adalah festival bir terbaik yang ditawarkan tahun 2020.

Saya berbicara dengan Dan Moore dari FusionAuth tentang OAuth dan usulan pengganti yang disebut GNAP — yang kemungkinan diucapkan tanpa G sebagai "tidur siang". Pengucapan tersebut memperkuat gagasan bahwa keamanan adalah bidang yang sangat menarik. GNAP mengatasi beberapa batasan OAuth dan membumbuinya dengan fitur baru.

Mengapa mengganti, atau lebih tepatnya menambah, OAuth? OAuth dirancang untuk browser. Ini mengasumsikan bahwa pembuat permintaan dapat menangani pengalihan HTTP. Fokus browser web ini adalah batu sandungan untuk aplikasi seluler atau "hal" apa pun di "Internet of Things". Selain itu, pihak OAuth menyukainya pada tahun 2007 dan mengharuskan Anda memposting parameter formulir, bukan JSON.

Spesifikasi OAuth tidak jelas di beberapa tempat, dan dunia berubah sejak 2012. Ada banyak RFC dan BCP, pada dasarnya spesifikasi add-on yang harus Anda terapkan untuk kemampuan lebih, keamanan yang lebih baik, dan kompatibilitas umum. Upaya terpisah yang disebut OAuth 2.1 berharap untuk menciutkan beberapa addons ini menjadi spesifikasi tunggal yang lebih koheren. Untuk beberapa motivasi untuk OAuth 2.1, lihat Lee McGovern dari pos Okta "Berapa Banyak RFC yang Diperlukan untuk Mengubah Bola Lampu". OAuth 2.1, tidak seperti GNAP, hanyalah rilis tambahan tanpa perubahan signifikan baru selain menggabungkan tumpukan spesifikasi ke dalam satu spesifikasi.

Spesifikasi GNAP masih dalam tahap awal. Penulis GNAP berencana untuk melangkah lebih jauh dari OAuth 2.1 dan mengubah sifat protokol itu sendiri. Alih-alih menggunakan parameter HTTP, Anda dapat menggunakan JSON. Titik akhir aplikasi dapat ditemukan. Anda tidak harus mendukung pengalihan (atau berbagai peretasan di sekitarnya). Moore mengacu pada perubahan ini di bawah istilah yang menyenangkan, "ergonomi pengembang".

Tujuan utama GNAP adalah pemisahan siapa yang meminta sumber daya (RQ) dan siapa yang memiliki sumber daya (RO).

IETF

GNAP juga mengusulkan untuk mendukung fitur keamanan baru seperti:

  • Peluncuran Asynchronous dan Application URL. Ini adalah jalur otentikasi berbeda yang memungkinkan klien untuk mengotentikasi tanpa pengalihan. GNAP juga memungkinkan aplikasi untuk mengotentikasi ke sumber pihak ketiga yang server sumber daya dan server otorisasi tidak memiliki akses langsung.
  • Minta Lanjutan. Ini memungkinkan klien untuk menegosiasikan hal-hal seperti pengalihan atau detail otentikasi lainnya selama proses otentikasi. Mereka juga memungkinkan klien untuk menegosiasikan hak istimewa tambahan atau token akses.
  • Beberapa Token Akses. Ini memungkinkan klien untuk mengautentikasi ke banyak sumber daya sekaligus, misalnya, sebagai pengguna dan administrator.
  • Token Batasan Pengirim. Meskipun ada add-on untuk OAuth 2 untuk fungsi ini yang disebut DPOP dan MTLS, GNAP akan membangunnya langsung ke dalam protokol. Kembali ke contoh tenda bir kami. Bagaimana jika kita juga harus membisikkan kata sandi ke telinga penjual sambil memberikan token kepada mereka? Jika token kami dijatuhkan (atau dicegat), itu tidak masalah karena pembawa tidak akan memiliki kata sandi.
  • Dan GNAP menyebabkan hantu Kerberos menjerit.

Kedengarannya bagus? Bisakah Anda mulai menggunakan GNAP hari ini? Jika Anda tertarik untuk berkolaborasi, Anda dapat membagi salah satu prototipe yang masuk ke proposal yang ada di GitHub.

Menurut Moore, penulis bertujuan untuk merilis GNAP pada tahun 2022. Karena setiap hari di tahun 2020 seperti seminggu pada tahun biasa, GNAP masih sangat jauh. Bagaimanapun, kelompok kerja GNAP sedang mencari kolaborator, dan Anda dapat bergabung dengan milis dan menawarkan umpan balik dan keahlian Anda. Saya kira Anda tidak dapat memperbaiki semuanya di dunia, tetapi setidaknya Anda dapat membantu memperbaiki OAuth.