Apa Itu OAuth? Panduan Lengkap tentang Cara Kerja Otorisasi Modern

Masalah yang Diciptakan OAuth untuk Dipecahkan

Untuk memahami mengapa OAuth ada, ada baiknya memahami alternatif yang digantikannya. Bayangkan sebuah aplikasi penjadwalan yang perlu memeriksa Kalender Google kita untuk konflik sebelum memesan rapat. Di dunia pra-OAuth, satu-satunya cara untuk memberikan akses tersebut adalah dengan memberikan nama pengguna dan kata sandi Google kita yang sebenarnya kepada aplikasi penjadwalan. Aplikasi tersebut kemudian akan masuk sebagai kita, meniru kita sepenuhnya, dengan akses penuh ke semua yang ada di akun kita — tidak hanya kalender kita, tetapi juga email kita, dokumen kita, seluruh kehidupan digital kita.

Pengaturan ini buruk dalam hampir setiap cara yang dapat dibayangkan. Aplikasi pihak ketiga sekarang harus menyimpan kata sandi kita, biasanya dalam bentuk teks biasa atau sesuatu yang mendekati itu, sehingga menciptakan tanggung jawab keamanan yang sangat besar dan tidak perlu. Kita tidak memiliki cara untuk membatasi apa yang sebenarnya dapat dilakukan aplikasi dengan akun kita — aplikasi tersebut memiliki akses yang sama seperti kita, titik. Dan jika kita ingin mencabut akses tersebut nanti, satu-satunya pilihan kita adalah mengubah kata sandi kita sepenuhnya, yang akan merusak setiap aplikasi lain yang telah kita berikan kata sandi yang sama. Kalikan ini di puluhan aplikasi yang memang membutuhkan akses ke akun kita, dan kita akan mendapatkan sistem yang pada dasarnya tidak aman, mustahil untuk diaudit, dan sulit dikelola.

OAuth — singkatan dari Open Authorization — dirancang khusus untuk menghilangkan pola ini. Ini memungkinkan pengguna untuk memberikan aplikasi pihak ketiga akses terbatas, spesifik, dan dapat dicabut ke akun mereka di layanan lain, tanpa pernah menyerahkan kata sandi mereka yang sebenarnya. Aplikasi tersebut tidak pernah melihat kredensial kita. Sebagai gantinya, aplikasi tersebut menerima token, yaitu sepotong data yang membuktikan bahwa aplikasi tersebut memiliki izin untuk melakukan tindakan tertentu, untuk jangka waktu tertentu, tanpa membuktikan bahwa aplikasi tersebut memiliki izin untuk melakukan hal lain.

Aktor Utama dalam Pertukaran OAuth

Setiap interaksi OAuth, terlepas dari bagaimana implementasinya, melibatkan empat peran berbeda, dan memahami peran-peran ini adalah kunci untuk memahami semua hal lain tentang protokol tersebut.

Pemilik sumber daya adalah orang yang memiliki data atau akun yang diakses — dalam sebagian besar skenario sehari-hari, ini adalah kita, pengguna manusia. Klien adalah aplikasi yang meminta akses ke data tersebut atas nama kita, yaitu seperti aplikasi penjadwalan yang ingin membaca kalender kita, layanan pihak ketiga yang ingin memposting ke akun media sosial kita. Server otorisasi adalah sistem yang mengautentikasi pemilik sumber daya dan menerbitkan token yang memberikan akses — ini biasanya dioperasikan oleh organisasi yang sama dengan layanan yang diakses, seperti infrastruktur identitas Google atau Microsoft sendiri. Dan server sumber daya adalah sistem yang benar-benar menyimpan data yang dilindungi dan menerima token sebagai bukti akses yang diotorisasi, yaitu API yang menyajikan acara kalender kita atau informasi akun kita.

Dalam banyak implementasi di dunia nyata, server otorisasi dan server sumber daya dioperasikan oleh perusahaan yang sama, bekerja sama sebagai backend terpadu — misalnya, sistem identitas Google dan API Kalender Google. Namun secara arsitektur, OAuth memperlakukan keduanya sebagai peran terpisah, yang sangat penting dalam lingkungan perusahaan di mana penyedia identitas terpusat tunggal menerbitkan token yang kemudian dihormati oleh banyak server sumber daya yang sepenuhnya terpisah di seluruh organisasi.

Bagaimana Alur Kode Otorisasi Sebenarnya Bekerja

Dari beberapa cara OAuth dapat diimplementasikan, alur yang digunakan untuk sebagian besar skenario dunia nyata yang dihadapi pengguna disebut alur Kode Otorisasi, dan menelusurinya langkah demi langkah akan menghilangkan sebagian besar kebingungan yang awalnya ditimbulkan oleh OAuth.

Alur ini dimulai ketika kita mengklik sesuatu seperti "Hubungkan akun Google Anda" di dalam aplikasi pihak ketiga. Aplikasi tersebut mengalihkan browser kita dari dirinya sendiri ke server otorisasi Google sendiri — yang penting, bukan ke formulir login yang dikendalikan oleh aplikasi pihak ketiga, tetapi ke halaman yang benar-benar dihosting dan dikendalikan oleh Google. Pengalihan ini adalah pilihan desain yang disengaja dan penting, yaitu kata sandi kita hanya akan dimasukkan pada halaman milik layanan yang benar-benar memilikinya, tidak pernah pada halaman yang dikendalikan oleh aplikasi yang meminta akses.

Di halaman tersebut, Google mengautentikasi kita (melalui proses login normal kita, apa pun konfigurasi yang telah kita buat) dan kemudian secara eksplisit menunjukkan kepada kita apa yang diminta oleh aplikasi yang meminta akses — membaca kalender kita, memposting atas nama kita, melihat alamat email kita — yang dijelaskan dalam istilah yang disebut cakupan (scopes), yang mendefinisikan kategori akses yang dibatasi secara tepat. Kita, sebagai pemilik sumber daya, kemudian secara eksplisit menyetujui atau menolak permintaan spesifik tersebut. Jika kita menyetujui, server otorisasi Google akan mengarahkan browser kita kembali ke aplikasi pihak ketiga, tetapi alih-alih mengirimkan kredensial kita atau token akses yang lengkap langsung melalui browser, server tersebut mengirimkan kode otorisasi sekali pakai yang berumur pendek.

Server backend aplikasi pihak ketiga kemudian mengambil kode otorisasi tersebut dan menukarkannya, dalam permintaan langsung antar server yang tidak pernah melewati browser kita sama sekali, dengan token akses yang sebenarnya. Pemisahan ini, yaitu kode sementara yang dilewatkan melalui browser, kemudian ditukar dengan token asli melalui saluran langsung yang lebih aman, adalah salah satu properti keamanan inti yang menjadikan alur Kode Otorisasi sebagai fondasi tepercaya dari OAuth modern. Token akses yang dikembalikan itulah yang kemudian disajikan oleh aplikasi pihak ketiga kepada server sumber daya (API Kalender Google, dalam contoh ini) pada setiap permintaan berikutnya, membuktikan bahwa aplikasi tersebut memiliki izin resmi kita untuk mengakses cakupan yang telah kita setujui, dan tidak lebih dari itu.

Token Akses, Token Penyegaran, dan Mengapa Token Tersebut Kedaluwarsa

Token yang dikeluarkan OAuth sengaja berumur pendek. Token akses biasanya kedaluwarsa dalam waktu satu jam atau bahkan kurang, yang merupakan fitur keamanan, bukan ketidaknyamanan: jika token dicuri atau bocor, jendela waktu penyalahgunaannya kecil dan terbatas. Bersamaan dengan token akses, server otorisasi sering kali mengeluarkan token penyegaran, yang berumur lebih panjang dan dapat ditukar dengan token akses baru setelah token asli kedaluwarsa, tanpa mengharuskan pengguna untuk masuk dan menyetujui akses lagi.

Desain ini memberikan OAuth properti yang benar-benar elegan, yaitu kredensial berumur pendek yang meminimalkan dampak kebocoran, dikombinasikan dengan mekanisme yang menghindari gangguan terus-menerus pada pengguna dengan permintaan masuk berulang. Token penyegaran itu sendiri diperlakukan dengan sangat hati-hati dalam implementasi modern — panduan keamanan saat ini menyerukan agar token penyegaran dibatasi oleh pengirim, artinya token tersebut terikat secara kriptografis pada klien tertentu yang awalnya menerimanya, atau sekali pakai dengan rotasi otomatis, artinya setiap kali token penyegaran digunakan, token tersebut dibatalkan dan diganti dengan yang baru, sehingga token penyegaran yang dicuri dan digunakan kembali oleh penyerang setelah klien yang sah telah menggunakannya akan segera terdeteksi dan dapat memicu respons keamanan.

Pencabutan adalah sisi lain dari desain ini, dan justru itulah yang ingin diwujudkan oleh OAuth, yang tidak pernah bisa dilakukan oleh model berbagi kata sandi lama. Jika kita memutuskan bahwa aplikasi yang terhubung tidak boleh lagi memiliki akses ke akun kita, kita dapat mencabut token aplikasi tersebut langsung dari pengaturan keamanan akun kita, langsung memutus aksesnya, tanpa memengaruhi kata sandi kita atau token terpisah yang diterbitkan secara independen oleh aplikasi lain.

Cakupan: Prinsip Akses Terbatas

Cakupan adalah mekanisme yang digunakan OAuth untuk menegakkan salah satu prinsip dasarnya yang paling penting, yaitu bahwa akses harus sesempit yang dibutuhkan oleh tugas sebenarnya, bukan seluas yang diizinkan oleh akun yang mendasarinya. Ketika sebuah aplikasi meminta akses ke akun kita, aplikasi tersebut menentukan dengan tepat cakupan mana yang dibutuhkannya — misalnya, akses baca saja ke kalender kita, bukan kemampuan untuk memodifikasi atau menghapus acara, atau akses hanya ke informasi profil publik kita daripada seluruh akun kita.

Grafik inilah yang memungkinkan layar persetujuan yang kita lihat selama alur OAuth menjadi bermakna, bukan sekadar formalitas. Kita tidak secara membabi buta mempercayai aplikasi dengan segalanya; kita meninjau dan menyetujui daftar izin yang spesifik dan terperinci, dan aplikasi klien yang diimplementasikan dengan baik hanya meminta cakupan yang benar-benar dibutuhkannya untuk fungsionalitas sebenarnya. Pengguna yang sadar akan keamanan, dan semakin banyaknya alat keamanan otomatis di dalam organisasi, menganggap permintaan dengan cakupan terlalu luas sebagai tanda bahaya yang sah — sebuah aplikasi yang meminta akses penuh ke akun untuk melakukan tugas yang jelas hanya membutuhkan pembacaan sebagian kecil data tertentu merupakan sinyal penting bahwa ada sesuatu tentang permintaan tersebut yang perlu diteliti.

PKCE: Menutup Celah Keamanan yang Nyata

Selama bertahun-tahun, kategori spesifik klien OAuth — aplikasi seluler dan aplikasi web satu halaman yang tidak dapat menyimpan rahasia klien secara aman seperti aplikasi sisi server tradisional — rentan terhadap serangan spesifik, yaitu aplikasi berbahaya pada perangkat yang sama berpotensi mencegat kode otorisasi saat dikirim kembali dari server otorisasi, dan menukarkannya dengan token akses yang valid sebelum aplikasi yang sah memiliki kesempatan untuk melakukannya.

PKCE, yang diucapkan "pixie" dan merupakan singkatan dari Proof Key for Code Exchange, menutup celah ini. Sebelum memulai alur otorisasi, klien menghasilkan nilai rahasia acak yang disebut verifier kode, dan mengirimkan hash yang diturunkan secara kriptografis dari nilai tersebut, yang disebut tantangan kode, bersama dengan permintaan otorisasi awal. Ketika klien kemudian menukarkan kode otorisasi dengan token akses, klien harus menyajikan verifier kode asli, dan server otorisasi memeriksa apakah verifier tersebut cocok dengan tantangan kode yang dikirimkan sebelumnya. Penyerang yang mencegat kode otorisasi saja tidak memiliki cara untuk menghasilkan verifier yang cocok, sehingga kode yang dicegat menjadi tidak berguna bagi mereka.

PKCE awalnya ditentukan pada tahun 2015 khusus untuk aplikasi seluler dan aplikasi native, di mana PKCE dianggap opsional untuk klien sisi server tradisional yang dapat menjaga kerahasiaan rahasia klien. Perbedaan tersebut sejak itu telah ditinggalkan. Panduan keamanan OAuth saat ini memperlakukan PKCE sebagai wajib untuk setiap jenis klien, termasuk aplikasi sisi server tradisional yang bersifat rahasia, karena perlindungan tambahan terhadap penyadapan kode otorisasi dan serangan injeksi sangat berharga terlepas dari langkah-langkah keamanan lain yang sudah dimiliki klien, dan mewajibkannya secara seragam menghilangkan seluruh kategori kesalahan implementasi.

Alur yang Telah Ditinggalkan OAuth

Tidak semua metode yang awalnya didukung OAuth untuk mendapatkan token masih relevan, dan memahami apa yang telah usang, dan mengapa, sangat berguna untuk memahami posisi protokol saat ini.

Alur Implisit awalnya dirancang untuk aplikasi berbasis browser yang, pada tahun-tahun awal OAuth, tidak memiliki cara yang aman untuk melakukan pertukaran kode server-ke-server yang digunakan dalam alur Kode Otorisasi standar. Cara kerjanya adalah dengan mengembalikan token akses langsung di fragmen URL browser, melewati langkah kode otorisasi perantara sepenuhnya. Ini ternyata menjadi kelemahan keamanan yang signifikan, yaitu token yang dikirim dengan cara ini terekspos dalam riwayat browser, di header referrer, dan ke skrip apa pun yang berjalan di halaman, tanpa perlindungan verifikasi kode yang setara dengan yang disediakan PKCE. Aplikasi halaman tunggal modern sekarang dapat melakukan alur Kode Otorisasi lengkap dengan PKCE secara langsung, yang sepenuhnya menghilangkan kebutuhan akan jalan pintas alur Implisit, dan alur tersebut tidak lagi dianggap sebagai praktik yang dapat diterima.

Resource Owner Password Credential, atau ROPC, memungkinkan aplikasi tepercaya untuk mengumpulkan nama pengguna dan kata sandi pengguna secara langsung dan menukarkannya dengan token dalam satu langkah — pada dasarnya memperkenalkan kembali masalah berbagi kata sandi yang persis sama yang ingin dihilangkan oleh OAuth, hanya saja dibungkus dalam protokol OAuth itu sendiri. Hal ini dimaksudkan hanya untuk aplikasi lama pihak pertama yang sangat tepercaya selama periode migrasi transisi, tetapi keberadaannya menciptakan jalan mudah kembali ke praktik yang buruk, dan telah dihapus sepenuhnya dari panduan OAuth saat ini.

Selain menghapus alur ini, praktik terbaik saat ini juga memperketat cara validasi URI pengalihan. Implementasi lama terkadang mengizinkan pencocokan yang fleksibel, seperti subdomain wildcard, saat memeriksa apakah tujuan pengalihan itu sah, yang menciptakan celah bagi penyerang untuk mendaftarkan target pengalihan yang mirip. Panduan modern mensyaratkan pencocokan string yang tepat dan akurat antara URI pengalihan yang terdaftar dan yang digunakan dalam permintaan aktual, menutup celah itu sepenuhnya.

OAuth vs. OpenID Connect: Otorisasi vs. Otentikasi

Salah satu poin kebingungan yang paling sering muncul seputar OAuth adalah perbedaan antara otorisasi dan otentikasi, dan penting untuk memperjelasnya. OAuth, secara tegas, adalah protokol otorisasi — ia menjawab pertanyaan tentang apa yang diizinkan untuk dilakukan oleh aplikasi tertentu, atau data apa yang diizinkan untuk diaksesnya. Awalnya, OAuth tidak dirancang untuk menjawab pertanyaan lain yang terkait: siapa orang ini, secara pasti?

OpenID Connect, sering disingkat OIDC, adalah lapisan otentikasi tipis yang dibangun langsung di atas OAuth 2.0, dan inilah yang sebenarnya mendukung "Masuk dengan Google" dan alur masuk berbasis identitas serupa. OIDC menambahkan token standar khusus yang disebut token ID, yang diformat sebagai JWT (JSON Web Token) yang ditandatangani, yang berisi klaim terverifikasi tentang identitas pengguna — pengidentifikasi unik mereka, alamat email mereka, kapan mereka diautentikasi — dengan cara yang dapat diverifikasi secara kriptografis oleh aplikasi yang mengandalkan token tersebut bahwa token tersebut benar-benar berasal dari penyedia identitas. Pada praktiknya, sebagian besar tombol "login sosial" yang kita temui di internet menggunakan mekanisme otorisasi dasar OAuth bersama dengan lapisan identitas OpenID Connect secara bersamaan, meskipun keduanya secara konseptual merupakan protokol yang berbeda yang menyelesaikan masalah terkait tetapi berbeda. Memahami perbedaan ini penting dalam praktiknya, yaitu aplikasi yang menggunakan OAuth murni tanpa OIDC dapat mengkonfirmasi bahwa ia memiliki izin untuk mengakses data tertentu atas nama kita, tetapi secara tegas tidak memiliki jaminan terverifikasi secara kriptografis tentang siapa kita sebenarnya — celah yang telah menyebabkan kesalahan keamanan nyata dalam sistem yang menggunakan OAuth murni untuk apa yang sebenarnya dimaksudkan sebagai keputusan autentikasi.

OAuth 2.1: Mengkonsolidasikan Pelajaran Selama Satu Dekade

Kerangka kerja OAuth 2.0 asli diterbitkan sebagai RFC 6749 pada tahun 2012, dan sejak saat itu, komunitas keamanan telah mengidentifikasi banyak celah dan menghasilkan serangkaian spesifikasi tambahan yang tersebar untuk mengatasinya — PKCE dalam RFC terpisah, panduan khusus untuk aplikasi seluler asli dalam RFC lain, spesifikasi lebih lanjut untuk aplikasi berbasis browser, dan dokumen praktik terbaik keamanan yang lebih luas yang menambahkan rekomendasi tambahan di atas semuanya. Hasil praktisnya, bagi siapa pun yang benar-benar mencoba menerapkan OAuth dengan benar, adalah perburuan yang membuat frustrasi di antara selusin dokumen yang tumpang tindih, dengan praktik yang benar-benar aman terkubur sebagai rekomendasi opsional daripada persyaratan yang jelas.

OAuth 2.1 hadir untuk memperbaiki masalah tersebut. Alih-alih memperkenalkan kemampuan baru, ia mengkonsolidasikan pelajaran keamanan dan spesifikasi tambahan yang terkumpul sejak tahun 2012 ke dalam satu dokumen terpadu, dan dengan demikian, mengubah apa yang dulunya merupakan praktik terbaik opsional menjadi persyaratan wajib. Di bawah OAuth 2.1, PKCE diwajibkan untuk setiap klien yang menggunakan alur Kode Otorisasi, bukan hanya klien publik yang tidak memiliki rahasia klien. Pemberian Implisit dan ROPC dihapus sepenuhnya, bukan hanya tidak dianjurkan. URI Pengalihan harus divalidasi melalui pencocokan string yang tepat. Dan token penyegaran untuk klien publik harus dibatasi oleh pengirim atau sekali pakai dengan rotasi, menutup kelemahan pemutaran ulang token yang dijelaskan sebelumnya.

Hingga pertengahan tahun 2026, OAuth 2.1 secara formal masih berupa Draf Internet IETF dan bukan RFC bernomor yang telah difinalisasi, tetapi detail teknis ini kurang penting dalam praktiknya daripada yang mungkin terdengar. Spesifikasi ini telah dalam bentuk draf sejak tahun 2020, kelompok kerja OAuth telah mencapai konsensus luas tentang persyaratan intinya, dan penyedia identitas utama — termasuk Okta, Auth0, dan Microsoft Entra ID — sudah mengimplementasikan persyaratannya secara langsung dalam produksi. Bagi tim mana pun yang membangun alur otorisasi baru pada tahun 2026, panduan praktisnya konsisten di seluruh industri: bangun sesuai dengan persyaratan OAuth 2.1 sekarang, karena dengan demikian berarti menghindari proyek migrasi di masa mendatang sepenuhnya daripada harus membongkar pola lama yang tidak aman di kemudian hari.

Salah satu perkembangan yang sangat penting adalah adopsi OAuth 2.1 sebagai elemen dasar dari pendekatan otorisasi dalam Model Context Protocol (MCP), standar yang sedang berkembang yang mengatur bagaimana sistem AI terhubung ke dan mengautentikasi dengan alat dan sumber data eksternal. Seiring dengan semakin banyaknya agen AI yang perlu bertindak atas nama pengguna — membaca kalender, mengirim email, memperbarui catatan dalam sistem bisnis — masalah mendasar yang sama yang dipecahkan OAuth untuk aplikasi web dan seluler konvensional muncul kembali dalam konteks baru, dan mekanisme inti yang sama dari delegasi yang terlingkup, dapat dicabut, dan tanpa berbagi kata sandi ternyata persis seperti yang dibutuhkan di sana juga.

Mengapa OAuth Lebih Penting dari Sebelumnya

Relevansi OAuth semakin meningkat seiring dengan meledaknya jumlah layanan, aplikasi, dan kini agen AI otonom yang saling terhubung dan membutuhkan akses terdelegasi ke akun dan data seseorang. API kini mencakup sebagian besar lalu lintas web, dan analis industri telah mengidentifikasinya sebagai target yang semakin dominan bagi penyerang — yang menjadikan lapisan otorisasi yang mengamankan API tersebut, dalam praktiknya seringkali OAuth, sebagai salah satu bagian infrastruktur keamanan yang paling penting yang dioperasikan oleh sebagian besar organisasi, terlepas dari apakah fakta tersebut dipahami secara luas di dalam organisasi itu sendiri.

Wawasan inti protokol ini — bahwa akses harus diberikan melalui token yang terbatas, dapat dicabut, dan dapat diaudit, bukan kredensial bersama yang bersifat mutlak — telah terbukti tahan lama justru karena mengatasi masalah yang tidak hilang seiring perubahan teknologi, yaitu setiap kali satu sistem perlu bertindak atas nama seseorang di dalam sistem lain, seseorang harus menjawab pertanyaan tentang seperti apa akses tersebut, berapa lama akses tersebut harus berlangsung, dan bagaimana akses tersebut dapat dicabut. OAuth telah menjawab pertanyaan itu dengan cukup baik, lebih dari satu dekade yang lalu, sehingga jawabannya masih terus disempurnakan dan dikonsolidasikan daripada digantikan, dan perluasannya ke cara agen AI mengautentikasi dan bertindak atas nama seseorang menunjukkan bahwa hal itu akan tetap menjadi landasan untuk waktu yang cukup lama.

Jadi, OAuth memecahkan masalah yang terdengar sederhana tetapi memiliki konsekuensi nyata yang sangat besar, yaitu bagaimana sebuah aplikasi membuktikan bahwa ia memiliki izin untuk bertindak atas nama kita di dalam aplikasi lain, tanpa kita harus menyerahkan kata sandi kita yang sebenarnya. Jawabannya — token berumur pendek, ruang lingkup sempit, dan dapat dicabut secara independen, yang diperoleh melalui pertukaran yang dirancang dengan cermat yang menjaga kredensial kita tetap terbatas pada layanan yang benar-benar memilikinya — telah menjadi salah satu protokol dasar yang tenang yang digunakan internet modern.