Kamu pasti pernah melihat tombol ini: "Sign in with Google" atau "Continue with GitHub." Sekali klik, tanpa password baru, dan aplikasi bisa membaca profil atau repo kamu. Tombol itu adalah OAuth 2.0 yang sedang bekerja, dan ide intinya sederhana: sebuah aplikasi mendapat izin terbatas untuk bertindak atas nama kamu, tanpa pernah menyentuh password kamu.
Poin Penting
OAuth 2.0 adalah protokol otorisasi, bukan sistem login dengan sendirinya. Ia memberikan akses yang dibatasi scope dan bisa dicabut.
Authorization code flow adalah flow standar untuk aplikasi web: pengguna menyetujui akses, aplikasi menerima kode sekali pakai, lalu menukarkannya dengan token.
Access token adalah kredensial berumur pendek untuk memanggil API. Refresh token mengambil access token baru tanpa meminta pengguna login lagi.
Scope membatasi apa yang bisa dilakukan sebuah token. PKCE melindungi client publik, seperti aplikasi mobile, dari pencurian authorization code.
OAuth 2.0 menggantikan berbagi password dan API token statis berumur panjang dengan token yang bisa dibatasi scope-nya, dirotasi, dan dicabut.
Apa Sebenarnya OAuth 2.0
oauth.net menggambarkan OAuth 2.0 sebagai protokol standar industri untuk otorisasi, dengan flow khusus untuk perangkat web, desktop, mobile, dan ruang keluarga. Kata kuncinya adalah otorisasi: OAuth menjawab "apa yang boleh dilakukan aplikasi ini," bukan "siapa pengguna ini." OpenID Connect, lapisan yang dibangun di atas OAuth 2.0, menambahkan bagian identitas, dan karena itulah "Sign in with Google" juga memberi tahu aplikasi siapa kamu.
Sebelum OAuth, model lamanya bermasalah. Seperti dijelaskan RFC 6749, spesifikasi inti OAuth 2.0 yang diterbitkan IETF pada Oktober 2012, aplikasi pihak ketiga harus menyimpan password pengguna, sering kali dalam bentuk teks biasa, dan mereka mendapat akses yang terlalu luas yang hanya bisa dicabut dengan mengganti password. OAuth memperbaiki kedua masalah itu: aplikasi tidak pernah melihat password, dan aksesnya terbatas serta bisa dicabut.
Empat peran terlibat dalam setiap flow OAuth:
Resource owner: kamu, pengguna pemilik data.
Client: aplikasi yang meminta akses.
Authorization server: layanan yang memeriksa identitas kamu dan menerbitkan token, misalnya Google atau GitHub.
Resource server: API yang menyimpan data kamu dan menerima token yang valid.
Cara Kerja Authorization Code Flow
Authorization code flow, yang didefinisikan dalam RFC 6749 bagian 4.1, adalah flow untuk aplikasi rahasia seperti aplikasi web biasa, menurut Auth0 Docs. Cara kerjanya:
Kamu mengklik "Sign in" di aplikasi, yang mengarahkan kamu ke authorization server.
Kamu login di sana, di situs provider itu sendiri, bukan di dalam aplikasi.
Kamu menyetujui (atau menolak) izin yang diminta, yang ditampilkan sebagai scope.
Authorization server mengarahkan kamu kembali ke aplikasi dengan authorization code sekali pakai.
Aplikasi menukarkan kode itu, ditambah kredensial client-nya sendiri, di token endpoint.
Authorization server memverifikasi semuanya dan mengembalikan access token, dan opsional refresh token.
Perhatikan apa yang tidak pernah terjadi: password kamu tidak pernah melewati aplikasi. Aplikasi hanya memegang token, dan token itu bisa dicabut tanpa mengganti password kamu.
Access Token vs Refresh Token
Spesifikasi OAuth 2.0 mendefinisikan access token di bagian 1.4 dan refresh token di bagian 1.5. Peran keduanya berbeda, dan mencampuradukkan keduanya adalah kesalahan OAuth yang paling umum.
Aspek | Access Token | Refresh Token |
|---|---|---|
Tujuan | Memanggil API atas nama kamu | Mendapatkan access token baru saat yang lama kedaluwarsa |
Masa berlaku | Pendek, sering kali hitungan menit sampai satu jam | Panjang, hitungan hari sampai bulan, atau sampai dicabut |
Ke mana ia dikirim | Dikirim pada setiap request API | Hanya dikirim ke authorization server |
Jika dicuri | Kerusakan dibatasi oleh masa berlaku pendek dan scope sempit | Serius, karena itu harus disimpan aman dan dirotasi |
Pola yang umum, ditunjukkan dalam dokumen Okta Developer, memakai access token dengan masa berlaku 1 jam. Saat kedaluwarsa, aplikasi diam-diam memakai refresh token untuk mendapatkan yang baru, jadi kamu tetap login tanpa memasukkan password lagi. Jika kamu mencabut akses, refresh token berhenti bekerja, dan aplikasi terkunci keluar.
Scope: Prinsip Hak Akses Minimum
Scope adalah label izin yang melekat pada sebuah token. Setiap token yang dibatasi scope memungkinkan pemegangnya melakukan tindakan tertentu pada endpoint tertentu, dan scope dalam token itulah yang mengendalikan kemampuan tersebut, seperti dijelaskan dokumen Okta Developer. Token dengan scope `read:user` bisa membaca profil publik kamu, tetapi tidak bisa menghapus repo kamu atau mengirim email atas nama kamu.
Inilah manfaat praktis OAuth. Saat kamu menyetujui sebuah aplikasi, bacalah daftar scope-nya. Jika filter foto sederhana meminta akses penuh ke email dan kontak kamu, daftar scope itu adalah tanda peringatannya, dan menolak tidak merugikan apa pun.
PKCE: Melindungi Client Publik
Aplikasi mobile dan single-page app tidak bisa menyimpan client secret, sehingga disebut public client. RFC 7636, yang diterbitkan IETF pada September 2015, ditulis karena public client yang memakai authorization code grant rentan terhadap pencurian authorization code: aplikasi jahat di perangkat yang sama bisa mencuri kode dari redirect.
PKCE (dibaca "pixy") memperbaiki ini dengan rahasia per request. Client membuat code verifier acak, string dengan entropi tinggi sepanjang 43 sampai 128 karakter, dan mengirim code challenge hasil transformasinya saat meminta kode. Saat menukarkan kode dengan token, client harus menunjukkan verifier asli sebagai bukti kepemilikan, seperti dijelaskan MojoAuth. Penyerang yang mencegat kode tetap tidak memiliki verifier, sehingga kode itu tidak berguna baginya. Saat ini, PKCE direkomendasikan untuk semua authorization code flow, bukan hanya client publik.
OAuth vs Password dan API Token Statis
Mengapa tidak sekadar berbagi password atau API key statis? Okta menjelaskan kontrasnya dengan jelas: tidak seperti token OAuth yang berumur pendek, token statis biasanya berumur panjang, dan token statis yang dicuri tetap aktif sampai dinonaktifkan manual atau akhirnya kedaluwarsa. Token statis juga biasanya memberikan akses semua atau tidak sama sekali, sementara OAuth mendukung akses berbasis scope, rotasi token, dan pemakaian antar layanan lewat client credentials flow.
Pendekatan | Berbagi password | API token statis | OAuth 2.0 |
|---|---|---|---|
Aplikasi melihat password kamu | Ya | Tidak | Tidak |
Cakupan akses | Semua yang bisa dilakukan akun kamu | Biasanya semua atau tidak sama sekali | Ber-scope, per token |
Pencabutan | Ganti password kamu | Nonaktifkan token secara manual | Cabut token, password tidak berubah |
Kedaluwarsa | Tidak pernah, sampai diganti | Berumur panjang, sering tanpa batas | Access token berumur pendek, refresh token bisa dirotasi |
Tabel itu juga alasan OAuth cocok dengan model API yang dijelaskan dalam panduan REST API kami: API membutuhkan cara aman untuk memutuskan siapa yang boleh memanggilnya, dan token ber-scope adalah mekanisme itu.
Kapan Menggunakan OAuth 2.0
Gunakan OAuth 2.0 saat aplikasi pihak ketiga membutuhkan akses ke data pengguna di layanan lain, saat kamu ingin pengguna login tanpa password baru, atau saat sebuah API membutuhkan akses ber-scope yang bisa dicabut. Gunakan authorization code flow dengan PKCE untuk aplikasi web dan mobile, dan client credentials flow untuk pemanggilan antar layanan tanpa pengguna.
Jangan memakai OAuth sebagai pengganti manajemen sesi di dalam aplikasimu sendiri, dan jangan menyimpan token di tempat yang bisa dibaca penyerang, seperti local storage browser untuk aplikasi sensitif. OAuth mengamankan delegasi antar layanan; keamanan sesi aplikasimu sendiri tetap menjadi tanggung jawabmu.
Read this article in English at OAuth Explained: How Secure Login Without Sharing Your Password Works.
FAQ
Apakah OAuth 2.0 sama dengan login?
Tidak. OAuth 2.0 adalah otorisasi: ia memberikan akses ber-scope ke resource. OpenID Connect, yang dibangun di atas OAuth 2.0, menambahkan autentikasi, dan karena itulah "Sign in with Google" mengonfirmasi identitas kamu.
Apakah aplikasi pernah melihat password saya?
Tidak, dalam flow OAuth yang benar. Kamu login di situs provider itu sendiri, dan aplikasi hanya menerima token. Jika sebuah aplikasi memintamu mengetikkan password Google atau GitHub langsung ke dalamnya, itu bukan OAuth, dan kamu harus berhenti.
Apa yang terjadi saat saya mencabut akses sebuah aplikasi?
Authorization server membatalkan token aplikasi itu, termasuk refresh token-nya. Aplikasi tidak lagi bisa memanggil API atas nama kamu, dan password kamu tetap tidak berubah.
Mengapa beberapa aplikasi sering meminta saya login lagi?
Access token mereka berumur pendek dan mereka tidak memiliki refresh token yang valid, atau refresh token itu dicabut atau kedaluwarsa. Masa berlaku pendek adalah fitur keamanan, bukan bug.