Apa Itu Base64URL? Penjelasan Lengkap

Mengapa Base64 Ada Sejak Awal?

Base64 ada untuk menyelesaikan masalah spesifik dan benar-benar lama dalam komputasi, yaitu bagaimana kita mengambil data biner — file gambar, tanda tangan kriptografi, potongan byte mentah yang sama sekali tidak sesuai dengan karakter yang dapat dicetak — dan merepresentasikannya hanya menggunakan karakter teks biasa yang dapat dicetak, sehingga dapat ditransmisikan dengan aman melalui sistem yang awalnya dirancang untuk menangani teks daripada konten biner sembarang?

Banyak protokol dan format yang menjadi dasar internet dirancang dengan mempertimbangkan teks biasa. Email, dalam spesifikasi aslinya, mengasumsikan isi pesan terdiri dari teks yang dapat dibaca dan dapat berperilaku tidak terduga atau merusak data secara langsung jika byte biner mentah disematkan secara langsung. JSON, salah satu format pertukaran data yang paling banyak digunakan dalam software modern, tidak memiliki cara asli untuk merepresentasikan data biner sama sekali — setiap nilai dalam dokumen JSON, pada tingkat syntax, adalah teks, angka, boolean, objek, atau array, tanpa tipe biner khusus. Base64 menyelesaikan kedua masalah ini, dan banyak masalah serupa lainnya, melalui satu mekanisme yang konsisten, yaitu ia mengambil data biner sembarang, tiga byte sekaligus, dan merepresentasikan kembali dua puluh empat bit tersebut sebagai empat karakter ASCII yang dapat dicetak yang diambil dari alfabet tetap yang terdiri dari enam puluh empat simbol — enam puluh empat huruf besar dan kecil, sepuluh angka, dan dua simbol tambahan yang dibutuhkan untuk melengkapi alfabet menjadi tepat enam puluh empat pilihan total, yang merupakan asal nama encoding ini.

Hasil praktisnya adalah bahwa setiap urutan byte apa pun — sebuah foto, tanda tangan digital, kunci enkripsi, hash kata sandi — dapat dikonversi menjadi string yang dibangun sepenuhnya dari karakter yang dapat dicetak biasa, disematkan dengan aman dalam format berbasis teks, ditransmisikan melalui sistem yang hanya dapat menangani teks dengan andal, dan kemudian dikonversi kembali ke data biner asli dengan membalikkan prosesnya. Transformasi inilah yang menjadikan Base64 sebagai dasar penting dalam lampiran email, URI data yang disematkan langsung di halaman web, muatan API, dan file konfigurasi — dan justru mekanisme dasar inilah yang menjadi landasan Base64URL, hanya menyesuaikan alfabet spesifik yang digunakan untuk dua simbol khusus terakhir tersebut.

Masalah yang Diciptakan Base64 Standar dalam URL

Alfabet Base64 standar terdiri dari dua puluh enam huruf besar, dua puluh enam huruf kecil, sepuluh angka nol hingga sembilan, dan terakhir dua karakter tambahan — yaitu tanda tambah (+) dan garis miring (/) — yang dibutuhkan untuk melengkapi total alfabet hingga enam puluh empat simbol yang diperlukan. Karakter pengisi terpisah, tanda sama dengan (=), ditambahkan di akhir output yang dikodekan ketika data asli tidak terbagi rata menjadi kelompok tiga byte, sehingga memastikan string yang dikodekan selalu memiliki panjang yang merupakan kelipatan empat.

Alfabet ini bekerja dengan sempurna di sebagian besar konteks yang dirancang Base64 — seperti isi email, nilai string JSON, dokumen XML — tetapi menciptakan masalah praktis yang nyata saat string yang dikodekan perlu ditempatkan di dalam URL, karena setiap karakter khusus tersebut sudah memiliki makna yang dicadangkan dan signifikan secara struktural dalam spesifikasi URL itu sendiri. Tanda plus (+) dalam string kueri URL secara konvensional diinterpretasikan sebagai karakter spasi literal — artinya string yang dikodekan Base64 yang berisi + dapat secara diam-diam dan salah didekode oleh sistem penerima sebagai berisi spasi, sehingga merusak data tanpa menimbulkan kesalahan yang terlihat. Garis miring (/) adalah karakter yang digunakan URL untuk memisahkan segmen jalur, artinya / yang muncul di dalam nilai yang dikodekan dapat disalahartikan sebagai penanda segmen baru dari jalur URL daripada sebagai bagian dari data yang dikodekan itu sendiri, sehingga merusak struktur URL secara langsung. Tanda sama dengan (=) adalah karakter yang digunakan untuk memisahkan nama parameter kueri dari nilainya, artinya = yang tertanam di dalam nilai yang dikodekan dapat membingungkan parser URL tentang di mana satu parameter berakhir dan parameter berikutnya dimulai.

Tidak satu pun dari masalah ini yang tidak dapat diatasi sendiri — pada prinsipnya, developer dapat mengkodekan setiap karakter bermasalah ini dengan persentase sebelum menempatkannya dalam URL, mengubah setiap +, /, dan = menjadi urutan escape %2B, %2F, dan %3D yang sesuai. Namun, melakukan hal itu akan menambah kompleksitas, panjang, dan peluang kesalahan yang berulang, terutama di berbagai lapisan software—seperti browser, proksi, server web, framework aplikasi, sistem pencatatan—yang biasanya dilalui URL dalam perjalanannya dari klien ke server dan kembali, yang mana masing-masing dapat menerapkan encoding atau decoding persentase pada titik yang tidak terduga dalam rantai tersebut dan secara diam-diam merusak data sebagai akibatnya.

Bagaimana Base64URL Sebenarnya Memperbaikinya

Base64URL menyelesaikan seluruh kategori masalah ini dari akarnya, alih-alih mengatasinya dengan cara menghindari karakter khusus, dengan hanya memilih pasangan karakter yang berbeda untuk dua simbol terakhir alfabet — karakter yang tidak memiliki makna khusus atau terlindungi di mana pun dalam struktur URL sejak awal, dan oleh karena itu tidak perlu dihindari sama sekali.

Perbaikan ini sengaja dibuat minimal, yaitu di mana pun Base64 standar akan menggunakan tanda plus (+), Base64URL menggunakan tanda hubung (-) sebagai gantinya; di mana pun Base64 standar akan menggunakan garis miring, Base64URL menggunakan garis bawah (_) sebagai gantinya. Setiap karakter lain dalam alfabet — kelima puluh dua huruf dan kesepuluh angka — tetap tidak berubah sama sekali antara kedua encoding, dan algoritma manipulasi bit yang mendasarinya yang mengubah tiga byte data biner menjadi empat karakter yang dikodekan juga sepenuhnya identik antara kedua varian tersebut. Satu-satunya hal yang berbeda adalah dua simbol spesifik mana yang digunakan untuk mewakili posisi keenam puluh tiga dan keenam puluh empat dalam alfabet bersama tersebut.

Karena tanda hubung dan garis bawah tidak memiliki makna struktural yang dicadangkan di mana pun dalam spesifikasi URL, string yang dikodekan dengan alfabet Base64URL dapat langsung dimasukkan ke dalam jalur URL, string kueri, atau header HTTP apa pun, dan setiap sistem yang kemudian mengurai URL tersebut — browser, proxy, server, alat pencatatan, dan semua yang ada di antaranya — akan meneruskan string yang dikodekan tersebut sepenuhnya tanpa risiko salah tafsir dan tanpa perlu langkah encoding persen tambahan sama sekali. Inilah keseluruhan proposisi nilai praktis Base64URL dalam satu kalimat, yaitu ini adalah Base64, yang disesuaikan sehingga outputnya sendiri tidak pernah bertabrakan dengan karakter yang sudah memiliki arti lain dalam konteks spesifik — URL — yang akan dilalui oleh data yang dikodekan tersebut.

Substitusi Dua Karakter, Dijelaskan Secara Tepat

Penting untuk menjelaskan secara tepat karakter mana yang berubah dan mana yang tidak, karena ketelitian ini sangat penting dalam praktiknya — satu karakter yang tidak cocok di posisi yang salah akan menghasilkan encoding yang tampak hampir benar tetapi didekode menjadi data yang rusak dan tidak valid.

Alfabet Base64 standar, secara berurutan, adalah: huruf besar A hingga Z (menempati posisi alfabet 0 hingga 25), huruf kecil a hingga z (posisi 26 hingga 51), angka 0 hingga 9 (posisi 52 hingga 61), dan akhirnya tanda tambah di posisi 62 dan garis miring di posisi 63. Alfabet Base64URL identik di setiap enam puluh dua posisi pertama tersebut — setiap huruf dan setiap angka menempati posisi yang sama persis di kedua alfabet — dan hanya berbeda di posisi 62 dan 63, di mana tanda hubung menggantikan tanda tambah dan garis bawah menggantikan garis miring.

Kesamaan posisi demi posisi yang tepat inilah yang memungkinkan konversi bersih antara kedua format hanya melalui substitusi karakter sederhana, tanpa perlu menjalankan ulang algoritma encoding yang mendasarinya dari awal, yaitu mengganti setiap + dengan - dan setiap / dengan _ dalam string Base64 standar menghasilkan string Base64URL yang sesuai persis yang mewakili data biner yang sama persis, dan substitusi sebaliknya mengkonversi string Base64URL kembali menjadi Base64 standar yang valid. Karena substitusi ini hanya beroperasi pada teks keluaran yang dikodekan dan tidak pernah menyentuh data biner asli atau logika pengelompokan enam bit yang menghasilkannya, kedua encoding selalu mewakili informasi yang sama persis — dalam arti yang paling harfiah, keduanya adalah dua kostum tekstual berbeda yang dikenakan oleh byte yang identik.

Padding: Mengapa Ada dan Mengapa Base64URL Menghilangkannya

Base64 bekerja dengan mengelompokkan byte input menjadi tiga bagian, karena tiga byte (total dua puluh empat bit) dapat dibagi rata menjadi empat kelompok enam bit, yang masing-masing dipetakan langsung ke salah satu dari enam puluh empat karakter alfabet. Kesulitan muncul ketika panjang total data input itu sendiri bukanlah kelipatan pasti dari tiga byte — situasi yang benar-benar umum, karena sebagian besar data dunia nyata tidak memiliki alasan khusus untuk datang dalam kelipatan tiga byte yang rapi. Base64 standar menangani sisa ini menggunakan padding, yaitu ketika satu atau dua byte tersisa di bagian paling akhir input setelah semua kelompok tiga byte lengkap telah diproses, encoding mengisi kelompok empat karakter terakhir dengan satu atau dua karakter padding tanda sama dengan literal, memastikan bahwa setiap string Base64 standar yang diformat dengan benar memiliki panjang total yang selalu merupakan kelipatan empat yang bersih.

Konvensi pengisian ini ada khusus untuk membantu dekoder mengenali, tanpa ambiguitas, tepat di mana data yang dikodekan yang bermakna berakhir — tetapi seperti yang telah dibahas sebelumnya, tanda sama dengan adalah salah satu dari tiga karakter yang menyebabkan masalah struktural di dalam URL, karena karakter yang sama digunakan URL untuk memisahkan nama parameter kueri dari nilai terkaitnya. Karena konflik langsung ini, sebagian besar implementasi Base64URL secara default hanya menghilangkan karakter pengisian sepenuhnya, dan sebagai gantinya mengandalkan panjang string yang dikodekan yang tersisa untuk menyimpulkan berapa banyak karakter pengisian yang akan ada dalam representasi Base64 standar yang setara, tanpa perlu memasukkannya ke dalam string yang dikirim.

Perbedaan antara kedua encoding ini cukup signifikan sehingga spesifikasi yang mengatur JSON Web Token secara khusus — yaitu RFC 7515, standar JSON Web Signature — melangkah lebih jauh daripada sekadar merekomendasikan output tanpa padding sebagai preferensi gaya, yaitu spesifikasi tersebut secara eksplisit mewajibkan bahwa padding tidak boleh disertakan dalam salah satu dari tiga segmen yang dikodekan Base64URL dari JWT, sebuah persyaratan tegas dan bukan konvensi opsional, justru karena JWT secara rutin ditransmisikan langsung dalam URL, header HTTP, dan cookie, konteks di mana bahkan satu tanda sama dengan yang salah dapat menciptakan ambiguitas parsing yang nyata. Namun, perlu dicatat bahwa persyaratan tanpa padding yang ketat ini khusus untuk spesifikasi JWT dan JWS; Definisi Base64URL yang lebih umum yang terdapat dalam RFC 4648 sendiri secara teknis mengizinkan penambahan padding jika implementasi atau kasus penggunaan tertentu benar-benar membutuhkannya, dan decoder yang ditulis dengan baik umumnya harus siap untuk menerima kedua varian input Base64URL, baik yang sudah diberi padding maupun yang belum, dengan benar, meskipun sisi encoder, khususnya untuk pekerjaan yang berkaitan dengan JWT, seharusnya secara default menghasilkan output yang belum diberi padding.

RFC 4648 dan Di Mana Standar Sebenarnya Berada

Base64URL bukanlah konvensi informal yang muncul secara organik melalui praktik developer umum, tetapi ini adalah encoding yang secara formal ditentukan dalam RFC 4648, dokumen Internet Engineering Task Force yang sama yang mendefinisikan standar Base64 itu sendiri, bersama dengan beberapa encoding terkait lainnya termasuk Base32. Asal usul bersama ini patut dipahami karena memperjelas bahwa Base64URL tidak diciptakan kemudian, sebagai tambalan ad hoc yang ditambahkan ke Base64 setelahnya, tetapi ditentukan sebagai varian kelas satu yang disengaja dan diberi nama dalam dokumen standar yang sama sejak awal.

RFC 4648 mendefinisikan alfabet Base64 standar di Bagian 4-nya, dan mendefinisikan alfabet Base64URL — yang dijelaskan dalam spesifikasi sebagai "Alfabet Aman URL dan Nama File" — di Bagian 5-nya, yang menjabarkan substitusi dua karakter yang sama persis dan perilaku padding umum yang sama seperti yang dijelaskan di atas sebagai bagian dari standar formal dan berversi yang diharapkan dipatuhi oleh implementasi software di setiap bahasa pemrograman dan platform utama. Spesifikasi formal inilah yang menjadi alasan mengapa Base64URL berperilaku identik dan dapat diprediksi di berbagai bahasa dan platform yang telah mengimplementasikan RFC dengan benar — string Base64URL yang dikodekan di backend Python dan didekodekan di frontend JavaScript akan menghasilkan hasil yang identik, asalkan kedua sisi benar-benar mengimplementasikan varian aman URL RFC 4648 dan bukan, misalnya, diam-diam kembali ke Base64 standar karena kesalahan konfigurasi pustaka, kesalahan yang akan dibahas lebih detail di bagian selanjutnya dalam panduan ini.

Base64URL Adalah Encoding, Bukan Enkripsi

Salah satu kesalahpahaman yang paling penting dan paling sering diulang tentang Base64URL — yang cukup serius hingga menghasilkan kerentanan keamanan yang nyata dan dapat dieksploitasi dalam sistem produksi nyata — adalah keyakinan bahwa karena suatu data telah dikodekan dengan Base64URL, data tersebut juga telah terlindungi, disembunyikan, atau diamankan. Ini sepenuhnya salah, dan perbedaan ini perlu dinyatakan sejelas dan selangsung mungkin: Base64URL adalah skema encoding, bukan skema enkripsi, dan sama sekali tidak memberikan perlindungan kerahasiaan apa pun.

Encoding dan enkripsi menyelesaikan dua masalah yang benar-benar berbeda, meskipun kedua proses tersebut mengubah data yang dapat dibaca menjadi representasi tekstual yang berbeda, kesamaan permukaan yang tampaknya menjadi akar kebingungan. Encoding ada semata-mata untuk mengubah format data sehingga dapat direpresentasikan dan ditransmisikan dengan aman — Base64URL ada khusus untuk membuat data biner aman untuk disematkan di dalam URL dan format berbasis teks. Tidak diperlukan kunci rahasia apa pun untuk membalikkannya: siapa pun, di mana pun, hanya dengan akses ke editor teks dan alat online yang tersedia secara gratis, dapat mendekode string Base64URL kembali ke konten aslinya dalam sepersekian detik, tanpa kata sandi, tanpa kunci kriptografi, dan tanpa akses khusus apa pun. Sebaliknya, enkripsi ada khusus untuk melindungi kerahasiaan data, dan pada dasarnya memerlukan kunci rahasia untuk membalikkannya — data yang telah dienkripsi dengan benar tidak dapat didekripsi oleh pihak ketiga mana pun yang tidak memiliki kunci tersebut, berapa pun waktu atau upaya komputasi yang ingin mereka habiskan.

Konsekuensi praktis dan nyata dari perbedaan ini cukup signifikan untuk perlu ditekankan secara langsung, yaitu muatan (payload) dari JSON Web Token (JWT), misalnya, dienkode menggunakan Base64URL, bukan dienkripsi, yang berarti bahwa klaim yang terkandung dalam JWT biasa — ID pengguna, alamat email mereka, peran yang ditugaskan kepada mereka, dan informasi lain apa pun yang dipilih penerbit token untuk disertakan — sepenuhnya dan dengan mudah dapat dibaca oleh siapa pun yang mencegat token tersebut, tanpa perlu mengalahkan mekanisme keamanan apa pun. Tanda tangan kriptografi yang biasanya menyertai JWT melindungi integritas data tersebut, sehingga memungkinkan server penerima untuk memverifikasi bahwa token tersebut belum diubah sejak diterbitkan, tetapi tanda tangan tersebut sama sekali tidak melindungi kerahasiaan klaim itu sendiri. Inilah mengapa panduan keamanan secara tegas menyatakan bahwa informasi sensitif — kata sandi, nomor kartu pembayaran lengkap, nomor identifikasi nasional, atau data lain apa pun yang benar-benar perlu dirahasiakan — tidak boleh ditempatkan di dalam muatan JWT, parameter status OAuth, atau nilai yang dienkode menggunakan Base64URL lainnya dengan asumsi yang salah bahwa pengkodean itu sendiri memberikan perlindungan yang berarti.

Di Mana Base64URL Sebenarnya Muncul

Base64URL bukanlah teknik khusus atau jarang ditemui — ia berada di balik sebagian besar infrastruktur otentikasi, otorisasi, dan API yang digunakan web modern, justru karena sebagian besar infrastruktur tersebut perlu memindahkan data biner atau terstruktur dengan aman melalui URL, header, dan cookie.

JSON Web Token (JWT) adalah penggunaan Base64URL yang paling terlihat dan paling sering ditemui di dunia nyata. Setiap JWT yang akan ditemui developer — baik yang tertanam dalam header Otorisasi HTTP, ditambahkan ke URL sebagai parameter kueri, atau disimpan langsung di dalam cookie — menggunakan Base64URL untuk mengkodekan setiap tiga segmen komponennya, dan memahami encoding tersebut sangat penting untuk dapat memeriksa, men-debug, dan memahami apa yang sebenarnya terkandung dalam token tertentu.

OAuth 2.0 mengandalkan Base64URL di beberapa bagian berbeda dari alur otorisasi, yaitu seperti kode otorisasi, token akses, dan parameter status yang digunakan untuk melindungi dari serangan pemalsuan permintaan lintas situs tertentu selama proses pengalihan login semuanya umumnya dikodekan menggunakan Base64URL, khususnya karena alur OAuth pada dasarnya bergantung pada pengiriman nilai-nilai ini bolak-balik melalui pengalihan browser dan parameter kueri URL, di mana karakter yang dicadangkan Base64 standar akan menciptakan masalah penguraian yang persis seperti yang dijelaskan sebelumnya dalam panduan ini. Ekstensi PKCE untuk OAuth 2.0, yang dibahas lebih detail di bagian selanjutnya, bergantung pada pengkodean Base64URL sebagai bagian inti dan tidak opsional dari mekanisme keamanannya sendiri.

Selain otentikasi secara khusus, Base64URL muncul dalam format JSON Web Encryption (JWE) dan JSON Web Key (JWK), keduanya merupakan bagian dari keluarga standar kriptografi berbasis JSON yang lebih luas yang termasuk JWT itu sendiri; dalam muatan notifikasi Web Push, di mana kunci enkripsi biner perlu ditransmisikan dengan aman sebagai bagian dari URL berlangganan; Dalam WebAuthn, standar otentikasi tanpa kata sandi modern, di mana pengidentifikasi kredensial biner dan kunci publik direpresentasikan menggunakan Base64URL sehingga dapat disertakan dengan aman dalam permintaan dan respons API; dan secara lebih umum dalam desain API apa pun di mana pengidentifikasi biner, hash, atau token perlu disematkan dengan aman langsung di dalam segmen jalur URL atau parameter kueri tanpa memerlukan escaping tambahan.

Anatomi JWT: Base64URL dalam Praktik

JSON Web Token terdiri dari tepat tiga segmen, dipisahkan oleh dua karakter titik literal, dan setiap segmen tersebut dienkode Base64URL secara independen. Segmen pertama adalah header, objek JSON kecil yang menentukan algoritma kriptografi dan jenis token yang digunakan — sesuatu seperti {"alg":"HS256","typ":"JWT"} — yang dienkode Base64URL menjadi string ringkas berupa huruf, angka, tanda hubung, dan garis bawah. Segmen kedua adalah payload, sebuah objek JSON yang jauh lebih besar yang berisi klaim sebenarnya yang ditegaskan oleh token — pengidentifikasi subjek, timestamp penerbitan, waktu kedaluwarsa, dan data spesifik aplikasi tambahan apa pun yang dipilih penerbit untuk disertakan — juga dienkode Base64URL dengan cara yang sama persis seperti header. Segmen ketiga dan terakhir adalah tanda tangan, yaitu nilai kriptografi yang dihitung atas dua segmen pertama menggunakan algoritma yang ditentukan dalam header dan kunci rahasia atau pribadi yang hanya diketahui oleh penerbit, dan segmen tanda tangan ini juga direpresentasikan menggunakan Base64URL, meskipun — tidak seperti dua segmen pertama — ia sendiri tidak dapat didekode kembali menjadi JSON yang dapat dibaca, karena pada dasarnya merupakan keluaran kriptografi biner daripada data teks yang dienkode.

Token lengkap yang dihasilkan dari penggabungan ketiga segmen yang dienkode Base64URL dengan titik inilah yang menjadi alasan mengapa JWT dapat dengan aman dan langsung ditempatkan ke dalam header HTTP Authorization: Bearer, ditambahkan ke URL sebagai parameter kueri, atau disimpan di dalam cookie, semuanya tanpa memerlukan langkah escaping tambahan, yaitu setiap karakter yang muncul di mana pun dalam JWT yang diformat dengan benar diambil secara eksklusif dari kumpulan huruf, angka, tanda hubung, garis bawah, dan karakter titik yang digunakan sebagai pemisah segmen — kumpulan karakter yang, berdasarkan desainnya, sepenuhnya aman dalam setiap konteks transmisi tersebut. Siapa pun dapat mengambil dua segmen pertama dari JWT apa pun, mendekodenya secara independen hanya dengan menggunakan dekoder Base64URL dasar, dan membaca JSON yang dihasilkan secara langsung — kemampuan debugging yang benar-benar berguna, dan sekaligus batasan kerahasiaan yang tepat seperti yang dijelaskan di bagian sebelumnya tentang pengkodean versus enkripsi.

OAuth 2.0, PKCE, dan Tantangan Kode

Selain penggunaannya dalam encoding token itu sendiri, Base64URL memainkan peran spesifik dan penting bagi keamanan dalam PKCE — Proof Key for Code Exchange, diucapkan "pixy" — ekstensi untuk Alur Kode Otorisasi OAuth 2.0 yang telah menjadi praktik keamanan default yang direkomendasikan untuk hampir setiap kategori aplikasi modern, mulai dari aplikasi seluler hingga single-page application hingga aplikasi web yang dirender server tradisional.

Mekanisme PKCE bekerja dengan cara aplikasi yang meminta menghasilkan nilai rahasia acak, yang disebut verifier kode, di awal alur autentikasi. Karena nilai rahasia mentah tersebut tidak boleh ditransmisikan langsung selama langkah awal alur, aplikasi tersebut malah menghitung hash kriptografi SHA-256 dari verifier kode, dan hash tersebut — yang pada dasarnya merupakan data biner mentah, karena hash SHA-256 pada dasarnya adalah urutan byte dengan panjang tetap daripada teks yang dapat dibaca — perlu ditransmisikan sebagai bagian dari permintaan otorisasi berbasis URL ke penyedia identitas. Inilah skenario yang ingin dipecahkan oleh Base64URL, yaitu hash biner SHA-256 mentah dienkode Base64URL menjadi string yang aman dan dapat ditransmisikan melalui URL yang disebut tantangan kode, yang dikirim sebagai bagian dari permintaan otorisasi awal tanpa risiko masalah karakter yang dicadangkan yang akan muncul jika menggunakan Base64 standar dalam konteks yang sama.

Kemudian, ketika aplikasi menukarkan kode otorisasi yang diterimanya dengan token aktual, aplikasi tersebut langsung menyajikan verifier kode asli yang belum di-hash, dan penyedia identitas secara independen menghitung ulang hash SHA-256 dan encoding Base64URL yang sama, mengkonfirmasi bahwa kedua nilai tersebut cocok sebelum melepaskan token apa pun — sebuah mekanisme yang memastikan bahkan penyerang yang entah bagaimana mencegat kode otorisasi dalam perjalanan tidak dapat berhasil menyelesaikan pertukaran token tanpa juga memiliki verifier kode asli, yang tidak pernah dikirim langsung selama permintaan awal. Seluruh mekanisme keamanan ini bergantung, pada tingkat struktural, pada kemampuan Base64URL untuk membawa output kriptografi biner dengan aman melalui permintaan berbasis URL, menjadikannya komponen yang benar-benar penting dari salah satu praktik keamanan otentikasi yang paling banyak digunakan saat ini, dan bukan sekadar detail format kosmetik.

Jadi, Base64URL adalah modifikasi kecil dan tepat sasaran pada skema encoding yang jauh lebih tua dan lebih umum, dan ketepatan itulah yang membuatnya sangat efektif, yaitu daripada menciptakan algoritma encoding baru dari awal, atau menerima gesekan dan risiko berkelanjutan dari pengescapean karakter standar Base64 secara manual setiap kali data yang dikodekan perlu dikirim melalui URL, Base64URL cukup memilih pasangan simbol alfabet yang berbeda sejak awal, yaitu simbol yang tidak akan pernah bertabrakan dengan apa pun yang bermakna dalam konteks spesifik, URL, yang dirancang untuk dilayani oleh encoding tersebut.