OAuth 2.1 vs OAuth 2.0: Apa yang Berubah dan Cara Migrasi

OAuth 2.0 tidak pernah berupa satu dokumen. Ia terdiri dari RFC 6749 tahun 2012, aturan bearer token di RFC 6750, lalu satu dekade catatan praktik terbaik terpisah yang menambal celah yang ditinggalkan kerangka aslinya. Jika Anda belajar OAuth dari tutorial yang ditulis tahun 2015, hampir pasti Anda mempelajari pola yang kini diam-diam sudah ditinggalkan komunitas. OAuth 2.1 adalah pembersihannya: satu spesifikasi yang mempertahankan yang berhasil, menghapus yang terbukti berbahaya, dan memasukkan panduan keamanan langsung ke dalam teks normatifnya.

Saya sudah cukup banyak membangun integrasi untuk tahu jurang antara apa yang diizinkan spesifikasi lama dan apa yang seharusnya benar-benar Anda lakukan di produksi. OAuth 2.1 menutup jurang itu dengan menjadikan jalur aman sebagai satu-satunya jalur. Tulisan ini membahas persis apa yang berubah, menampilkan pertukaran Authorization Code plus PKCE yang akurat, dan memberi Anda urutan migrasi yang bisa diikuti tanpa merusak klien yang sedang berjalan.

OAuth 2.1 adalah konsolidasi, bukan penemuan ulang

Draf ini eksplisit menyatakan bahwa ia menggantikan dan menganggap usang RFC 6749 dan RFC 6750, menggabungkan informasi dari dokumen-dokumen itu dan praktik keamanan terbaik ke dalam satu spesifikasi Standards Track sekaligus menghapus fitur yang ditemukan tidak aman. Tidak ada format token baru, tidak ada grant inti baru, dan tidak ada endpoint baru. Jika Anda sudah menjalankan alur authorization code dengan benar hari ini, sebagian besar sistem Anda sudah patuh OAuth 2.1. Pekerjaannya ada pada apa yang harus Anda hentikan.

PKCE kini wajib untuk setiap klien

Di OAuth 2.0, Proof Key for Code Exchange hanyalah tambahan, terutama disarankan untuk aplikasi mobile dan single-page yang tidak bisa menyimpan rahasia. OAuth 2.1 menaikkannya menjadi persyaratan dasar: PKCE wajib untuk semua klien yang memakai alur authorization code, termasuk server web konfidensial. Klien membuat verifier acak, mengirim hanya hash-nya sebagai challenge pada permintaan otorisasi, lalu mengungkapkan verifier saat menukar code. Penyerang yang mencegat code tidak bisa menukarnya tanpa verifier asli.

# 1. Client generates a PKCE pair (S256)
code_verifier  = base64url( random(32 bytes) )
code_challenge = base64url( SHA256(code_verifier) )

# 2. Authorization request — a browser redirect that returns a code, never a token
GET /authorize?response_type=code
  &client_id=s6BhdRkqt3
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &scope=read%20write
  &state=xyz
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256 HTTP/1.1
Host: as.example.com

# 3. Authorization server redirects back with a short-lived, one-time code
HTTP/1.1 302 Found
Location: https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

# 4. Token request — the client proves it owns the verifier behind that challenge
POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&client_id=s6BhdRkqt3
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Dua jenis grant dihapus

OAuth 2.1 menghilangkan dua alur yang didefinisikan RFC 6749. Keduanya membocorkan token atau kredensial dengan cara yang tak bisa sepenuhnya diperbaiki oleh konfigurasi apa pun, jadi alih-alih mendokumentasikan solusi tambal, spesifikasi cukup menghapusnya.

• Implicit grant, di mana authorization server mengembalikan access token langsung di fragmen redirect, dihilangkan. Token di URL berakhir di riwayat browser, log, dan header referrer. Aplikasi browser kini memakai alur authorization code dengan PKCE sebagai gantinya.
• Resource owner password credentials grant, di mana aplikasi mengumpulkan username dan password asli pengguna lalu mengirimnya ke endpoint token, dihilangkan. Ia menggagalkan seluruh tujuan otorisasi terdelegasi dan menghalangi federasi serta prompt multi-faktor.

Jika Anda punya salah satu alur ini di produksi, itulah migrasi yang membawa risiko nyata, karena mengubah cara klien memperoleh token. Selebihnya OAuth 2.1 sebagian besar hanya memperketat aturan yang mungkin sudah nyaris Anda ikuti.

Token dan redirect memiliki aturan lebih ketat

Tiga perubahan yang lebih kecil namun penting memperkuat bagian OAuth yang paling sering dijadikan sasaran penyerang.

• Bearer token tidak boleh berada di query string URL. RFC 6750 mengizinkan parameter query; OAuth 2.1 menghapus opsi itu, sehingga access token hanya berada di header Authorization atau body permintaan berkode form agar tidak masuk log dan riwayat.
• Redirect URI harus dibandingkan dengan pencocokan string persis. Kebiasaan lama mengizinkan pencocokan prefix atau wildcard dihapus, karena membuka pintu bagi serangan open-redirect dan pencurian token. Daftarkan setiap URL callback secara penuh.
• Refresh token untuk klien publik harus sender-constrained atau sekali pakai. Dalam praktiknya itu berarti rotasi: setiap refresh mengembalikan refresh token baru dan membatalkan yang lama, sehingga refresh token yang dicuri berhenti berfungsi begitu klien sah memakai token berikutnya.

OAuth 2.0 vs OAuth 2.1 sekilas

Mengapa MCP memilih OAuth 2.1

Alasan OAuth 2.1 tiba-tiba penting bagi banyak developer adalah Model Context Protocol. MCP adalah cara klien AI terhubung ke server alat dan data eksternal, dan spesifikasi otorisasinya dibangun langsung di atas OAuth 2.1. Spesifikasi MCP menyatakan bahwa authorization server harus mengimplementasikan OAuth 2.1 dengan langkah keamanan yang sesuai untuk klien konfidensial maupun publik, dan bahwa klien MCP harus mengimplementasikan PKCE sesuai OAuth 2.1. Ia menyematkan referensi persisnya: draft-ietf-oauth-v2-1-13.

Dalam istilah MCP, server MCP terproteksi berperan sebagai OAuth 2.1 resource server, klien MCP adalah klien OAuth 2.1, dan access token hanya berjalan di header Authorization, tidak pernah di query string. MCP juga menambahkan resource indicators dari RFC 8707 sehingga token terikat pada server spesifik tempat ia diterbitkan, serta mewajibkan rotasi refresh token untuk klien publik. Jika Anda membangun server MCP, Anda sedang mengimplementasikan OAuth 2.1 entah Anda berniat atau tidak.

Bagaimana saya akan migrasi

Anda tidak perlu penulisan ulang sekaligus. Migrasikan dengan urutan yang menghapus pola paling berisiko lebih dulu dan menyisakan pengetatan yang kompatibel untuk terakhir.

1. Tambahkan PKCE ke setiap klien authorization code, termasuk aplikasi sisi server konfidensial. Ini kompatibel mundur dengan server yang sudah mendukungnya, jadi Anda bisa menggelarnya sebelum apa pun yang lain berubah.
2. Pensiunkan implicit dan password grant. Pindahkan aplikasi browser dan mobile ke authorization code dengan PKCE, dan pindahkan klien mesin-ke-mesin ke client credentials grant.
3. Hentikan membaca bearer token dari query string dan tolak token di sana. Terima access token hanya dari header Authorization atau body berkode form.
4. Daftarkan redirect URI secara persis dan aktifkan rotasi refresh token untuk klien publik, sambil memantau log Anda untuk callback yang mengandalkan pencocokan longgar.

Lakukan empat langkah ini secara berurutan dan Anda mendarat di OAuth 2.1 tanpa hari peralihan mendadak. Imbalannya adalah permukaan serangan lebih kecil, satu spesifikasi otoritatif alih-alih perburuan lintas banyak RFC, dan pengaturan token yang sudah kompatibel dengan MCP serta gelombang perkakas AI yang dibangun di atasnya.