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

> OAuth 2.1 merangkum satu dekade perbaikan keamanan dalam satu spesifikasi: PKCE untuk semua, tanpa implicit atau password grant, aturan token dan redirect lebih ketat.

URL: https://www.matthewswong.com/id/blog/oauth-2-1-vs-2-0-migration/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2026-08-01
- Updated: 2026-08-01
- Category: Security

> **Key takeaway:** OAuth 2.1 menggabungkan OAuth 2.0 dan praktik keamanan terbaiknya ke dalam satu spesifikasi. PKCE menjadi wajib untuk setiap klien yang memakai alur authorization code, implicit dan password grant dihapus, bearer token dilarang di query string URL, redirect URI harus dicocokkan persis, dan rotasi refresh token diwajibkan untuk klien publik.

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.

> Nilai verifier dan challenge pada contoh di atas adalah test vector kanonis dari RFC 7636 Lampiran B. Gunakan untuk menguji implementasi S256 Anda sendiri: mem-hash verifier persis itu dengan SHA-256 lalu meng-encode base64url harus menghasilkan challenge persis itu, atau encoding Anda salah.

## 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.

> Pencocokan redirect URI persis dapat merusak integrasi yang mengandalkan parameter query dinamis yang ditambahkan ke callback. Pindahkan data per-permintaan ke parameter state atau sesi yang dilindungi PKCE, bukan ke redirect URI, sebelum Anda mengaktifkannya, atau callback Anda akan mulai ditolak.

## OAuth 2.0 vs OAuth 2.1 sekilas

| Aspek | OAuth 2.0 | OAuth 2.1 |
| --- | --- | --- |
| PKCE | Opsional, disarankan untuk klien publik | Wajib untuk semua klien yang memakai alur authorization code |
| Implicit grant (token di redirect) | Didefinisikan dan diizinkan | Dihapus dari spesifikasi |
| Password grant (kredensial pemilik) | Didefinisikan dan diizinkan | Dihapus dari spesifikasi |
| Bearer token di query string URL | Diizinkan oleh RFC 6750 | Tidak diizinkan; hanya header atau body permintaan |
| Pencocokan redirect URI | Pencocokan longgar lazim dalam praktik | Pencocokan string persis diwajibkan |
| Refresh token untuk klien publik | Berumur panjang dan dapat dipakai ulang | Harus sender-constrained atau sekali pakai |
| Dokumen dasar | RFC 6749 plus RFC 6750 plus catatan terpisah | Satu spesifikasi yang mengusangkan 6749 dan 6750 |

## 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.

- 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.
- 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.
- Hentikan membaca bearer token dari query string dan tolak token di sana. Terima access token hanya dari header Authorization atau body berkode form.
- 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.

## Sources

- The OAuth 2.1 Authorization Framework (draf IETF, datatracker)
- Ikhtisar dan perbedaan OAuth 2.1 (oauth.net)
- Spesifikasi Authorization Model Context Protocol
- OAuth 2.1: How Many RFCs Does it Take (Okta Developer Blog)

## Source links

- https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1
- https://oauth.net/2.1/
- https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
- https://developer.okta.com/blog/2019/12/13/oauth-2-1-how-many-rfcs

## FAQ

### Apa perbedaan utama antara OAuth 2.1 dan OAuth 2.0?

OAuth 2.1 menggabungkan OAuth 2.0 (RFC 6749) dan praktik keamanan terbaiknya ke dalam satu spesifikasi yang mengusangkan RFC 6749 dan RFC 6750. Ia menghapus fitur tidak aman alih-alih menambah fitur baru: PKCE menjadi wajib, implicit dan password grant dihilangkan, serta aturan token dan redirect diperketat.

### Apakah PKCE wajib di OAuth 2.1?

Ya. Di OAuth 2.0 PKCE bersifat opsional dan terutama disarankan untuk aplikasi mobile dan single-page. OAuth 2.1 mewajibkan PKCE untuk semua klien yang memakai alur authorization code, termasuk aplikasi web sisi server konfidensial, untuk mencegah serangan pencegatan dan injeksi authorization code.

### Jenis grant OAuth 2.0 mana yang dihapus di OAuth 2.1?

Dua grant dihilangkan: implicit grant, yang mengembalikan access token langsung di URL redirect, dan resource owner password credentials grant, yang membuat aplikasi mengumpulkan password asli pengguna. Aplikasi browser sebaiknya memakai authorization code dengan PKCE, dan klien mesin memakai client credentials.

### Mengapa Model Context Protocol (MCP) mewajibkan OAuth 2.1?

Spesifikasi otorisasi MCP dibangun langsung di atas OAuth 2.1. Ia menyatakan authorization server HARUS mengimplementasikan OAuth 2.1 dan klien MCP HARUS mengimplementasikan PKCE, dengan merujuk draft-ietf-oauth-v2-1-13. Server MCP terproteksi berperan sebagai OAuth 2.1 resource server dan access token harus dikirim di header Authorization, tidak pernah di query string.

### Bagaimana cara migrasi dari OAuth 2.0 ke OAuth 2.1?

Migrasikan secara bertahap: pertama tambahkan PKCE ke setiap klien authorization code karena kompatibel mundur, lalu pensiunkan implicit dan password grant, kemudian hentikan penerimaan bearer token di query string, dan terakhir terapkan pencocokan redirect URI persis serta rotasi refresh token untuk klien publik. Tidak perlu penulisan ulang sekaligus.

---

- HTML version: https://www.matthewswong.com/id/blog/oauth-2-1-vs-2-0-migration/
- English: https://www.matthewswong.com/en/blog/oauth-2-1-vs-2-0-migration/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json