Token ID vs Token Akses: Perbedaan Krusial dalam OpenID Connect

By Mirko Peters · 2026-10-28

Pelajari perbedaan penting antara token ID dan token akses dalam OpenID Connect, dan pahami mengapa mencampuradukkan keduanya dapat menimbulkan celah keamanan yang serius.

Automatically translated with AI from the original post. Read the English original

Memahami perbedaan antara token ID dan token akses sangat penting bagi pengembang dan administrator TI yang bekerja dengan autentikasi modern. OAuth 2.0 menangani izin, sedangkan OpenID Connect memperkenalkan token ID untuk memastikan identitas pengguna. Mencampuradukkan kedua token yang berbeda ini menimbulkan kerentanan keamanan yang kritis pada aplikasi cloud.

Poin Penting

• Token ID membuktikan identitas pengguna, sedangkan token akses memberikan otorisasi dan izin.
• Mengacaukan kedua token ini merupakan kesalahan utama dalam keamanan aplikasi buatan sendiri.
• OpenID Connect menambahkan lapisan konfirmasi identitas di atas kerangka kerja OAuth 2.0.
• Token akses dapat dicabut, sehingga memberikan postur keamanan yang lebih aman dibandingkan menyimpan kata sandi.
• Aplikasi harus memverifikasi token ID yang masuk secara kriptografis, bukan mempercayainya begitu saja.

Dilema Inti: Identitas versus Otorisasi

Dalam perkembangan aplikasi web modern, pengembang sering kali dibingungkan oleh cara pengguna masuk dan cara pengguna yang sama berinteraksi dengan data yang mendasarinya. Sebagian besar kebingungan ini berasal dari istilah yang tumpang tindih dalam ranah identitas. Ketika aplikasi mulai berkembang pesat di web, hanya mengandalkan kombinasi nama pengguna dan kata sandi sederhana menciptakan hambatan keamanan yang sangat besar. Pengguna merasa lelah harus mengelola puluhan kredensial yang berbeda, sehingga kata sandi lemah sering digunakan ulang di berbagai platform.

Untuk mengatasi sebagian dari masalah ini, OAuth 2.0 hadir. Namun, OAuth 2.0 tidak pernah dirancang untuk menjawab pertanyaan tentang siapa seseorang. Tujuan utamanya adalah menyediakan surat izin, yang dikenal sebagai token akses, yang memungkinkan aplikasi mengakses titik akhir data tertentu atas nama pengguna. Token akses menjelaskan apa yang boleh dilakukan aplikasi, tetapi sama sekali tidak memberi tahu identitas orang yang memegangnya. Celah mendasar ini membuat perusahaan yang ingin membangun pengalaman single sign-on harus menambahkan pemeriksaan identitas kustom sendiri ke OAuth, sehingga menghasilkan implementasi yang terfragmentasi dan jarang sejalan satu sama lain.

OpenID Connect menjembatani celah ini dengan memperkenalkan lapisan terstandar yang dirancang khusus untuk autentikasi. Dengan menggunakan token kedua di samping token akses tradisional, OpenID Connect memisahkan dengan jelas pertanyaan tentang identitas dari pertanyaan tentang izin. Menjaga kedua konsep ini tetap terpisah adalah pergeseran pola pikir terpenting bagi siapa pun yang membangun atau mengaudit aplikasi cloud saat ini.

Anatomi Token ID: Apa Saja yang Ada di Dalamnya

Ketika pengguna mengklik tombol "Masuk dengan Microsoft", penyedia identitas memproses kredensial, menangani persyaratan autentikasi multi-faktor, dan akhirnya mengirim pengguna kembali ke aplikasi disertai token ID. Token ini dikemas sebagai JSON Web Token, yang biasa disingkat JWT dan dibaca "jot". Sekilas, JWT tampak seperti rangkaian karakter yang membingungkan dan sulit ditembus yang dipisahkan oleh titik. Namun, struktur internalnya ternyata sangat sederhana setelah didekode.

Di dalam token ID, Anda akan menemukan sejumlah klaim standar, masing-masing dengan tujuan yang jelas:

• Issuer: Mengidentifikasi penyedia identitas tertentu (misalnya Microsoft Entra ID) yang membuat dan menandatangani token tersebut.
• Subject (sub): Berfungsi sebagai pengenal unik yang tidak dapat diubah untuk pengguna. Yang terpenting, nilai ini dirancang agar tidak berubah meskipun pengguna memperbarui nama tampilan atau alamat email mereka.
• Audience (aud): Menentukan aplikasi spesifik tempat token tersebut dibuat, sehingga memastikan bahwa token yang ditujukan untuk satu aplikasi tidak dapat dicegat dan digunakan kembali secara jahat oleh aplikasi lain.
• Timestamps: Menguraikan kapan token diterbitkan, kapan token kedaluwarsa, dan saat tepat pengguna melakukan autentikasi.
• Nonce: Berperan sebagai nomor tanda terima yang aman, yang mengaitkan token hasil dengan sesi masuk spesifik yang memulai permintaan, sehingga secara efektif memblokir serangan replay.

Yang terpenting, seluruh paket ditandatangani menggunakan kunci privat penyedia. Aplikasi penerima memvalidasi tanda tangan ini menggunakan kunci publik yang sesuai dan dipublikasikan oleh penyedia. Tanpa verifikasi kriptografis ini, token ID tidak lebih dari sekadar catatan yang tidak terverifikasi yang diteruskan di antara pihak-pihak terkait.

Bahaya Memperlakukan Identitas sebagai Akses

Salah satu anti-pola paling berbahaya dalam pengembangan aplikasi adalah memperlakukan token ID sebagai kunci izin. Karena token ID memastikan bahwa pengguna adalah John Doe dari organisasi tertentu, pengembang pemula terkadang keliru menggunakan konfirmasi tersebut untuk memberikan hak administratif atau akses database tanpa batas. Ini secara mendasar salah memahami arsitekturnya.

Token ID hanya menyatakan siapa yang berdiri di depan pintu; token ini tidak menentukan apakah orang tersebut boleh masuk ke setiap ruangan di dalam atau menekan tombol administratif tertentu. Logika otorisasi harus ditangani secara terpisah oleh aplikasi menggunakan kontrol akses berbasis peran (role-based access control) atau mekanisme serupa, dengan menjadikan identitas yang telah terverifikasi sebagai titik awal, bukan keputusan otorisasi akhir.

Selain itu, aplikasi sering melakukan kesalahan dengan menerima token ID yang masuk tanpa menjalankan pemeriksaan validasi yang semestinya. Mempercayai token secara membabi buta hanya karena sebuah library memprosesnya di balik layar akan membuat sistem rentan terhadap data palsu. Memvalidasi tanda tangan, memeriksa stempel waktu kedaluwarsa, dan memverifikasi klaim audience adalah langkah yang tidak dapat ditawar untuk menjaga postur keamanan.

Kesimpulan

Memahami batas antara identitas dan otorisasi membantu menyingkap misteri arsitektur cloud modern. Dengan menjaga token ID agar sepenuhnya fokus untuk membuktikan siapa yang berada di depan keyboard, dan membiarkan token akses mengatur tindakan apa saja yang diizinkan, pengembang dapat membangun integrasi yang tangguh dan aman dengan platform seperti Microsoft Entra ID. Untuk mendengarkan penjelasan lengkap tentang konsep-konsep ini dan memahami cara alur masuk modern beroperasi dalam ekosistem Microsoft, simak diskusi lengkapnya. Dengarkan episode lengkapnya dan pelajari lebih dalam mekanisme identitas cloud hari ini!

Pertanyaan Umum

Apakah token ID dapat digunakan untuk memanggil API atau mengakses sumber daya yang dilindungi?

Tidak. Token ID hanya berisi klaim identitas tentang siapa pengguna tersebut. Untuk memanggil API atau mengakses sumber daya yang dilindungi, aplikasi harus menggunakan token akses yang diterbitkan melalui OAuth 2.0.

Mengapa OpenID Connect dan OAuth 2.0 menggunakan token yang terpisah?

Memisahkan identitas dari otorisasi memungkinkan aplikasi untuk memverifikasi siapa yang sedang masuk tanpa memberi aplikasi tersebut izin tak terbatas untuk memanipulasi data atau sumber daya dasar milik pengguna.

Apa yang terjadi jika aplikasi menerima token ID tanpa memeriksa tanda tangannya?

Melewati verifikasi tanda tangan membuat aplikasi rentan terhadap token palsu, karena siapa pun dapat membuat string klaim khusus yang mengaku sebagai pengguna yang valid.

Di mana nilai 'nonce' berperan dalam pertukaran token?

Nonce adalah string acak yang dibuat di awal alur masuk dan disematkan di dalam token ID, sehingga memungkinkan aplikasi untuk mencegah serangan replay.