Apa Itu OpenID Connect (OIDC)? Panduan Lengkap

Masalah yang Diciptakan OIDC untuk Dipecahkan

OAuth 2.0, yang diterbitkan sebagai IETF RFC 6749, dirancang untuk memecahkan masalah otorisasi yang didelegasikan, yaitu memungkinkan aplikasi mengakses sumber daya tertentu atas nama pengguna — seperti kalender, perpustakaan foto, sekumpulan file — tanpa aplikasi tersebut perlu mengetahui kata sandi pengguna untuk layanan yang menampung sumber daya tersebut. Ini adalah inovasi yang tulus dan berharga. Sebelum OAuth, aplikasi yang ingin, misalnya, mencadangkan foto kita dari layanan lain sering meminta kita untuk mengetikkan nama pengguna dan kata sandi kita langsung ke dalam formulir loginnya sendiri — praktik yang melatih pengguna untuk menyerahkan kredensial mereka kepada pihak ketiga dan menciptakan risiko keamanan yang sangat besar ketika salah satu pihak ketiga tersebut disusupi atau jahat.

Namun, OAuth 2.0, dengan sendirinya, menjawab pertanyaan yang lebih sempit daripada yang sebenarnya dibutuhkan oleh sebagian besar aplikasi. Ia menerbitkan token akses yang pada dasarnya mengatakan "aplikasi ini diizinkan untuk melakukan X" — tetapi, dengan sendirinya, tidak secara andal memberi tahu aplikasi siapa pengguna di balik token tersebut sebenarnya. Token akses membuktikan izin, bukan identitas. Seorang developer dapat menerima token akses OAuth yang valid dan tetap tidak memiliki cara standar dan tepercaya untuk mengetahui apakah orang di ujung lain adalah Alice, Bob, atau akun anonim atau bahkan robot dengan cakupan yang cukup untuk membuat permintaan tersebut berfungsi. Sebelum OIDC, setiap penyedia identitas yang ingin mengekspos informasi identitas pengguna bersama dengan token OAuth melakukannya dengan cara mereka sendiri yang bersifat eksklusif dan tidak standar, yang berarti setiap integrasi "login dengan X" yang baru memerlukan kode khusus penyedia — situasi yang terfragmentasi dan rawan kesalahan yang OIDC ciptakan khusus untuk memperbaikinya.

Hubungan OIDC dengan OAuth 2.0

Secara praktis, alur OIDC hampir identik dengan alur OAuth 2.0 standar, dengan satu tambahan penting, yaitu aplikasi yang meminta menyertakan nilai `openid` dalam parameter `scope` saat memulai permintaan. Nilai `scope` tunggal tersebut adalah sinyal yang memberi tahu server otorisasi, "harap jalankan juga protokol OpenID Connect di atas pertukaran OAuth standar yang sudah akan Anda lakukan." Ketika sinyal tersebut hadir, server identitas — yang di bawah OIDC juga secara formal mengambil peran sebagai Penyedia OpenID, atau OP — tidak hanya mengembalikan token akses yang akan diberikan oleh OAuth 2.0 biasa, tetapi juga jenis token baru yang berbeda yang disebut token ID, yang merupakan pembawa informasi identitas terverifikasi yang sebenarnya.

Pilihan desain ini — memperluas daripada mengganti — adalah alasan mengapa OIDC telah mencapai interoperabilitas yang begitu luas. Sistem apa pun yang sudah fasih menggunakan OAuth 2.0 hanya perlu menambahkan dukungan untuk satu jenis token baru dan sejumlah kecil endpoint standar baru untuk menjadi sepenuhnya sesuai dengan OIDC, daripada perlu mengimplementasikan protokol yang sepenuhnya terpisah dari awal.

Perbedaan Inti: Otentikasi vs. Otorisasi

Otorisasi menjawab pertanyaan "apa yang diizinkan untuk dilakukan oleh orang atau aplikasi ini?" OAuth 2.0, pada intinya, adalah framework otorisasi: ia menerbitkan token akses yang memberikan izin khusus dan terbatas pada sumber daya tertentu, tanpa pernah membuat pernyataan pasti tentang identitas pihak yang mengajukan permintaan. Otentikasi, sebaliknya, menjawab pertanyaan yang sama sekali berbeda: "siapa orang ini, dan dapatkah identitas itu diverifikasi?" Inilah tepatnya pertanyaan yang tidak pernah dirancang untuk dijawab secara andal oleh OAuth 2.0, dan inilah tepatnya pertanyaan yang ingin dijawab oleh OIDC.

Sebuah model mental yang bermanfaat, yang secara konsisten digunakan dalam dokumentasi rekayasa identitas, adalah dengan menganggap OAuth 2.0 sebagai sistem kartu kunci hotel dan OIDC sebagai proses check-in di meja resepsionis yang terjadi sebelum kartu kunci dikeluarkan. Kartu kunci (token akses OAuth) membuktikan bahwa pemegangnya diizinkan untuk membuka pintu tertentu — tetapi kartu kunci saja, yang ditemukan di lantai, tidak memberi tahu kita apa pun tentang siapa orang itu sebenarnya. Proses check-in di meja resepsionis (otentikasi OIDC) adalah yang memverifikasi identitas tamu sejak awal, sebelum kartu kunci dikeluarkan sama sekali. Dalam aplikasi modern, kedua proses tersebut biasanya terjadi bersamaan dalam satu alur gabungan, itulah sebabnya OIDC dan OAuth 2.0 sering disebut bersamaan dan, dapat dimengerti, sering dikacaukan satu sama lain.

Para Pemain Kunci dalam Alur OIDC

End User adalah manusia yang sebenarnya mencoba masuk atau membuktikan identitas mereka — orang yang duduk di depan keyboard memasukkan kredensial atau menyetujui permintaan masuk di ponsel mereka.

Relying Party, disingkat RP, adalah aplikasi atau website yang ingin memverifikasi identitas pengguna dan, pada dasarnya, telah mengalihfungsikan fungsi masuk dan otentikasinya ke pihak ketiga yang tepercaya daripada membangun dan memelihara sistem nama pengguna dan kata sandi sendiri. Dalam terminologi OAuth 2.0 biasa, peran yang sama ini hanya disebut "klien," tetapi terminologi "Relying Party" OIDC lebih tepat menggambarkan apa yang sebenarnya terjadi, yaitu aplikasi tersebut mengandalkan orang lain untuk menjamin identitas pengguna.

OpenID Provider, disingkat OP, adalah layanan identitas tepercaya yang sebenarnya melakukan autentikasi — memverifikasi kata sandi pengguna, berpotensi memicu autentikasi multi-faktor, dan pada akhirnya menerbitkan token yang membuktikan identitas pengguna yang terverifikasi kepada Relying Party. Google, Microsoft Entra ID (sebelumnya Azure AD), Apple, Okta, dan Amazon Cognito adalah Penyedia OpenID yang umum digunakan dalam sistem produksi saat ini. Penyedia OpenID secara fungsional merupakan entitas yang sama dengan apa yang disebut OAuth 2.0 biasa sebagai "server otorisasi," tetapi sekali lagi, istilah khusus OIDC menekankan peran verifikasi identitasnya daripada peran penerbitan tokennya saja.

Sebelum peran-peran ini dapat berinteraksi, Relying Party harus terlebih dahulu mendaftar ke Penyedia OpenID yang dipilih, sebuah proses yang menghasilkan ID klien dan, untuk aplikasi rahasia, rahasia klien — kredensial yang mengidentifikasi aplikasi spesifik ke penyedia dan digunakan sepanjang proses pertukaran token selanjutnya.

Tiga Token OIDC

ID Token adalah kontribusi khas OIDC dan token yang sama sekali tidak ada di OAuth 2.0 biasa. Ini adalah JSON Web Token (JWT) yang ditandatangani, yang mewakili bukti peristiwa autentikasi itu sendiri — berisi, setidaknya, pengidentifikasi unik untuk pengguna (klaim yang disebut sub, singkatan dari "subjek") bersama dengan informasi tentang bagaimana dan kapan autentikasi tersebut terjadi. Token ID dimaksudkan untuk dikonsumsi dan divalidasi langsung oleh Relying Party itu sendiri; ini adalah jawaban atas pertanyaan "siapa yang masuk, dan bagaimana saya tahu klaim ini dapat dipercaya?"

Access Token memiliki tujuan yang sama persis seperti pada OAuth 2.0 biasa, yaitu token ini merupakan kredensial yang memberikan izin kepada pemegangnya untuk mengakses sumber daya atau API yang dilindungi atas nama pengguna, yang dibatasi oleh izin spesifik yang diminta dan diberikan selama proses otorisasi. Yang penting, token akses tidak dimaksudkan untuk dibaca atau diinterpretasikan oleh Relying Party itu sendiri — token ini dimaksudkan untuk disajikan, sebagian besar sebagai kredensial yang tidak transparan, kepada server sumber daya atau API apa pun yang telah diterbitkan untuk diakses.

Refresh Token, yang diterbitkan secara opsional, memungkinkan Relying Party untuk mendapatkan token akses baru (dan dalam banyak implementasi, token ID baru) setelah token asli kedaluwarsa, tanpa mengharuskan pengguna untuk masuk kembali dan memasukkan kembali kredensial mereka. Karena token penyegaran dapat digunakan untuk mempertahankan dan memperpanjang sesi terautentikasi dalam jangka waktu yang lama, terkadang bahkan ketika pengguna tidak aktif, token ini merupakan kredensial yang sangat sensitif yang membutuhkan penyimpanan dan penanganan yang hati-hati dan aman — pertimbangan keamanan yang akan dibahas lebih mendalam di bagian selanjutnya dalam panduan ini.

Apa Sebenarnya Isi Token ID?

Karena token ID adalah komponen yang membedakan OIDC dari OAuth 2.0 biasa, ada baiknya untuk memeriksa struktur dan isinya secara lebih detail. Token ID diformat sebagai JSON Web Token, yang berarti berupa string ringkas dan aman untuk URL yang terdiri dari tiga bagian yang dipisahkan oleh titik, yaitu header yang menjelaskan algoritma penandatanganan token, payload yang berisi klaim identitas sebenarnya, dan tanda tangan kriptografi yang memungkinkan Relying Party untuk memverifikasi bahwa token belum diubah sejak diterbitkan oleh Penyedia OpenID.

Payload token ID berisi serangkaian klaim standar yang telah ditentukan, beberapa di antaranya secara efektif wajib berdasarkan spesifikasi. Subklaim adalah pengidentifikasi unik dan stabil untuk pengguna yang diautentikasi dalam Penyedia OpenID tertentu — secara fungsional merupakan hal yang paling mendekati kunci utama untuk identitas yang disediakan OIDC, dan nilai yang umumnya harus digunakan aplikasi secara internal untuk mewakili "pengguna spesifik ini," daripada mengandalkan sesuatu yang lebih mudah berubah seperti alamat email. Klaim `iss` mengidentifikasi penerbit — Penyedia OpenID spesifik yang menerbitkan token — memungkinkan Relying Party untuk mengkonfirmasi bahwa token tersebut benar-benar berasal dari penyedia yang diharapkan. Klaim `aud` mengidentifikasi audiens yang dituju dari token tersebut, biasanya ID klien dari Relying Party spesifik yang menjadi penerima token, mencegah token yang diterbitkan untuk satu aplikasi diputar ulang dan diterima oleh aplikasi lain. Klaim `exp` menentukan stempel waktu kedaluwarsa, setelah itu token tidak lagi dianggap valid, dan klaim `iat` mencatat kapan token tersebut awalnya diterbitkan.

Di luar rangkaian inti ini, token ID sering kali membawa klaim profil tambahan tergantung pada cakupan apa yang diminta selama permintaan otentikasi awal — informasi seperti nama pengguna, alamat email, dan URL gambar profil, yang dibahas lebih detail di bagian berikut tentang cakupan dan klaim. Karena token ID ditandatangani secara kriptografis oleh Penyedia OpenID menggunakan kunci privat, Relying Party dapat secara independen memverifikasi tanda tangan tersebut menggunakan kunci publik yang dipublikasikan oleh penyedia, yang mengkonfirmasi bahwa token tersebut otentik dan bahwa tidak ada kontennya yang diubah selama pengiriman — mekanisme spesifik yang memungkinkan untuk mempercayai JWT yang tiba melalui internet terbuka tanpa memerlukan perjalanan bolak-balik terpisah secara real-time kembali ke penyedia untuk setiap verifikasi.

Cakupan dan Klaim: Meminta Data Identitas Spesifik

OIDC menstandarkan tidak hanya bagaimana token identitas diformat, tetapi juga bagaimana Relying Party meminta kategori informasi identitas spesifik dari Penyedia OpenID — sebuah mekanisme yang dibangun di sekitar cakupan, sebuah konsep yang dipinjam langsung dari OAuth 2.0 tetapi diperluas dengan nilai-nilai spesifik OIDC.

Nilai cakupan `openid`, seperti yang dijelaskan sebelumnya, adalah sinyal wajib yang memicu perilaku OIDC sejak awal — tanpanya, server otorisasi tidak memiliki alasan untuk menerbitkan token ID sama sekali dan hanya akan berperilaku sebagai server otorisasi OAuth 2.0 biasa. Di luar dasar wajib tersebut, OIDC mendefinisikan beberapa nilai cakupan tambahan standar yang meminta kumpulan klaim spesifik, yaitu cakupan profil meminta informasi profil umum seperti nama, gambar profil, dan lokal; cakupan email meminta alamat email pengguna beserta klaim boolean yang menunjukkan apakah alamat tersebut telah diverifikasi oleh penyedia; dan cakupan telepon dan alamat meminta kategori informasi kontak yang sesuai, jika didukung oleh penyedia tertentu.

Sistem berbasis cakupan ini memiliki fungsi privasi dan keamanan yang penting: sistem ini memastikan bahwa Relying Party hanya menerima kategori informasi identitas spesifik yang telah secara eksplisit diminta dan yang telah disetujui secara eksplisit oleh pengguna untuk dibagikan, daripada menerima seluruh informasi yang dimiliki Penyedia OpenID tentang pengguna tersebut tanpa batasan. Integrasi sederhana yang hanya untuk login mungkin hanya meminta cakupan openid, menerima informasi yang cukup untuk mengetahui bahwa pengguna tertentu yang telah diverifikasi telah diautentikasi, sementara integrasi yang lebih rumit yang perlu mempersonalisasi pengalaman dengan nama dan foto pengguna akan meminta cakupan profil juga.

Bagaimana Proses Login OIDC Sebenarnya Terjadi, Langkah demi Langkah

Proses dimulai ketika pengguna mencoba mengakses aplikasi Relying Party dan mengklik tombol bergaya "Masuk dengan Google" atau secara otomatis dialihkan karena mereka tidak memiliki sesi yang valid. Relying Party membuat permintaan otorisasi — URL yang diarahkan ke endpoint otorisasi Penyedia OpenID, termasuk cakupan openid beserta cakupan tambahan yang diperlukan, ID klien terdaftar Relying Party, URI pengalihan yang menentukan ke mana pengguna harus dikirim kembali setelah otentikasi, dan nilai yang dihasilkan secara acak yang disebut parameter status yang digunakan untuk melindungi dari serangan pemalsuan permintaan lintas situs tertentu.

Browser pengguna dialihkan ke Penyedia OpenID, tempat autentikasi sebenarnya berlangsung: pengguna memasukkan kredensial mereka langsung di halaman login penyedia — tidak pernah di halaman Relying Party, yang merupakan properti keamanan yang membuat model ini jauh lebih aman daripada pola lama mengetikkan kata sandi ke setiap aplikasi pihak ketiga secara individual — dan penyedia juga dapat memicu autentikasi multi-faktor pada tahap ini jika akun atau permintaan spesifik membutuhkannya.

Setelah autentikasi berhasil, Penyedia OpenID mengalihkan browser pengguna kembali ke URI pengalihan yang ditentukan oleh Relying Party, biasanya membawa kode otorisasi berumur pendek daripada token sebenarnya. Langkah perantara ini ada khusus untuk alasan keamanan, yaitu kode otorisasi dirancang untuk dipertukarkan, bukan digunakan secara langsung, meminimalkan risiko kebocoran token melalui riwayat browser, log server, atau header referrer selama proses pengalihan. Kemudian, backend Relying Party membuat permintaan langsung antar server ke endpoint token Penyedia OpenID, menukarkan kode otorisasi tersebut — bersama dengan kredensial kliennya sendiri, yang membuktikan bahwa itu benar-benar aplikasi yang memulai permintaan — dengan token ID, token akses, dan secara opsional token penyegaran (refresh token).

Terakhir, Relying Party memvalidasi tanda tangan dan klaim token ID yang diterima, mengkonfirmasi informasi identitas yang dibutuhkannya, dan membangun sesi terautentikasi untuk pengguna, biasanya dengan menerbitkan cookie sesi sendiri sehingga pengguna tidak perlu mengulangi seluruh alur ini pada setiap permintaan berikutnya.

Alur Kode Otorisasi dengan PKCE

Urutan spesifik yang dijelaskan di atas secara formal dikenal sebagai Authorization Code Flow, dan pada tahun 2025 secara universal direkomendasikan sebagai pilihan default untuk hampir semua kategori aplikasi — aplikasi web, aplikasi seluler, dan aplikasi halaman tunggal — ketika dipasangkan dengan ekstensi keamanan tambahan yang disebut PKCE, yang diucapkan "pixy" dan merupakan singkatan dari Proof Key for Code Exchange.

PKCE awalnya dikembangkan untuk mengatasi kerentanan spesifik dalam aplikasi seluler dan aplikasi asli, yang, tidak seperti aplikasi web yang dirender server tradisional, seringkali tidak dapat menyimpan rahasia klien dengan aman sama sekali — rahasia apa pun yang tertanam dalam biner aplikasi seluler terdistribusi, pada prinsipnya, dapat diekstrak oleh penyerang yang cukup termotivasi. PKCE menutup celah ini dengan meminta Relying Party menghasilkan nilai rahasia acak, yang disebut verifier kode, di awal alur, dan mengirimkan versi hash-nya, yang disebut code challenge, bersama dengan permintaan otorisasi awal. Relying Party kemudian menukarkan kode otorisasi dengan token, mereka juga harus menyajikan verifier kode asli yang belum di-hash, yang kemudian diperiksa oleh Penyedia OpenID terhadap tantangan kode yang diterima sebelumnya. Hal ini memastikan bahwa meskipun penyerang entah bagaimana mencegat kode otorisasi dalam perjalanan, mereka tidak dapat berhasil menukarkannya dengan token tanpa juga memiliki verifier kode asli, yang tidak pernah dikirim melalui jaringan dalam bentuk yang belum di-hash selama permintaan awal.

Karena PKCE secara signifikan memperkuat Authorization Code Flow terhadap kelas serangan intersepsi yang nyata dan telah dieksploitasi sebelumnya, dan karena hanya menambah kompleksitas implementasi yang dapat diabaikan, panduan praktik terbaik saat ini merekomendasikan penggunaannya secara universal — tidak hanya untuk klien publik seperti aplikasi seluler dan aplikasi satu halaman di mana awalnya dianggap wajib, tetapi juga untuk aplikasi web sisi server yang bersifat rahasia, sebagai lapisan pertahanan tambahan.

Penemuan dan Endpoint yang Dikenal

Salah satu standardisasi yang lebih penting namun kurang diperhatikan yang diperkenalkan OIDC di atas OAuth 2.0 biasa adalah mekanisme penemuan yang memungkinkan Relying Party untuk secara otomatis mempelajari detail konfigurasi dari setiap Penyedia OpenID yang sesuai, daripada mengharuskan konfigurasi tersebut untuk diteliti dan dikodekan secara manual oleh pengembang untuk setiap integrasi penyedia baru.

Setiap Penyedia OpenID yang sesuai dengan OIDC mengekspos dokumen penemuan standar pada URL yang dapat diprediksi dan dikenal — secara konvensional URL penerbit dasar penyedia dengan tambahan /.well-known/openid-configuration. Dokumen JSON ini mempublikasikan lokasi pasti dari endpoint otorisasi penyedia, endpoint token, endpoint UserInfo (dijelaskan di bagian selanjutnya), lokasi kunci penandatanganan publik yang digunakan untuk memverifikasi tanda tangan token ID, dan daftar lengkap cakupan, klaim, dan metode autentikasi yang didukung oleh penyedia tertentu.

Kemampuan penemuan ini merupakan kemudahan praktis yang signifikan: artinya, mengintegrasikan Penyedia OpenID baru ke dalam aplikasi, dalam banyak kasus, dapat dilakukan hanya dengan memberikan URL penerbit dasar penyedia, dengan konfigurasi lain yang diperlukan diambil secara otomatis saat runtime — sebuah peningkatan yang berarti dibandingkan dengan pekerjaan integrasi yang terfragmentasi, dikonfigurasi secara manual, dan spesifik penyedia yang menjadi ciri era pra-OIDC yang dijelaskan sebelumnya dalam panduan ini.

Endpoint UserInfo

Selain klaim identitas yang tertanam langsung dalam token ID itu sendiri, OIDC mendefinisikan endpoint UserInfo standar yang dapat dipanggil oleh Relying Party, dengan menyajikan token akses yang valid, untuk mengambil informasi profil tambahan tentang pengguna yang diautentikasi langsung dari Penyedia OpenID.

Endpoint ini ada secara khusus karena menyematkan setiap informasi profil yang mungkin ada langsung di dalam token ID akan membuat token tersebut menjadi terlalu besar dan juga berarti bahwa setiap perubahan selanjutnya pada profil pengguna — gambar profil baru, nama yang diperbarui — tidak akan tercermin hingga autentikasi ulang penuh pengguna berikutnya. Sebaliknya, endpoint UserInfo memungkinkan Relying Party untuk mengambil informasi profil terkini sesuai permintaan, yang dicakup sesuai dengan sistem cakupan dan klaim yang sama seperti yang dijelaskan sebelumnya, memberikan alternatif atau pelengkap yang lebih fleksibel dan terkini untuk klaim yang sudah ada dalam token ID itu sendiri.

Bagaimana OIDC Memungkinkan Single Sign-On

Single sign-on, yang biasa disingkat SSO, adalah salah satu kemampuan paling signifikan secara praktis yang dimungkinkan oleh OIDC, dan memahami mekanisme di baliknya akan menjelaskan mengapa OIDC telah menjadi pilihan default untuk login sosial konsumen dan manajemen identitas perusahaan.

Mekanisme intinya mudah dipahami setelah alur yang dijelaskan sebelumnya dipahami, yaitu ketika pengguna pertama kali melakukan autentikasi dengan Penyedia OpenID, penyedia tersebut biasanya membuat sesi sendiri dengan browser pengguna, terlepas dari Relying Party tertentu — yang biasanya diimplementasikan melalui cookie sesi yang dicakup ke domain penyedia itu sendiri. Ketika pengguna yang sama kemudian mencoba masuk ke aplikasi Relying Party kedua yang sama sekali berbeda yang kebetulan menggunakan Penyedia OpenID yang sama, permintaan otorisasi mengarahkan browser pengguna ke penyedia seperti biasa, tetapi karena penyedia mengenali cookie sesi yang ada, ia dapat secara diam-diam melakukan autentikasi ulang pengguna tanpa mengharuskan mereka untuk memasukkan kembali kredensial mereka sama sekali, segera mengeluarkan kode otorisasi baru dan mengarahkan kembali ke Relying Party yang baru.

Dari perspektif pengguna, ini menghasilkan pengalaman tanpa hambatan yang umumnya dikaitkan dengan SSO, yaitu masuk sekali ke penyedia identitas pusat dan kemudian mendapatkan akses ke berbagai aplikasi berbeda tanpa perlu mengulangi proses masuk untuk setiap aplikasi secara individual. Penting untuk memperjelas terminologi di sini, karena ini adalah poin yang sering membingungkan bahkan di antara para praktisi, yaitu OIDC memungkinkan SSO dan merupakan protokol yang paling umum digunakan untuk mengimplementasikannya, tetapi OIDC sendiri adalah protokol otentikasi, bukan sinonim harfiah dengan SSO sebagai konsep arsitektur yang lebih luas — SSO pada prinsipnya dapat diimplementasikan menggunakan protokol lain juga, dengan SAML, yang dibahas di bagian selanjutnya, sebagai alternatif historis yang paling signifikan.

OIDC vs. OAuth 2.0 Saja: Kapan Menggunakan yang Mana

OAuth 2.0 saja, tanpa lapisan OIDC, tetap sepenuhnya tepat untuk skenario otorisasi API-ke-API murni di mana verifikasi identitas pengguna manusia sebenarnya tidak diperlukan — misalnya, layanan backend yang meminta token untuk mengakses API layanan backend lain atas namanya sendiri, atau integrasi mesin-ke-mesin apa pun di mana konsep "pengguna manusia mana ini" sama sekali tidak berlaku. Dalam skenario ini, menambahkan lapisan identitas OIDC tidak memberikan manfaat nyata, karena pada awalnya tidak ada identitas pengguna yang perlu diverifikasi.

OIDC menjadi pilihan yang tepat dan, dalam praktik saat ini, hampir wajib setiap kali aplikasi perlu mengetahui, dengan keyakinan kriptografis, siapa sebenarnya pengguna manusia tertentu — integrasi login sosial yang berhadapan dengan konsumen, implementasi SSO perusahaan, dan skenario apa pun di mana logika aplikasi sendiri perlu membuat keputusan berdasarkan identitas pengguna yang terverifikasi daripada sekadar pemberian izin anonim yang terbatas. Aturan praktis yang telah menjadi panduan standar di seluruh komunitas rekayasa identitas sangat sederhana, yaitu gunakan OIDC setiap kali aplikasi perlu mengautentikasi pengguna manusia dan mempersonalisasi atau membatasi akses berdasarkan siapa orang tertentu tersebut; gunakan OAuth 2.0 biasa saja hanya ketika skenario benar-benar terbatas pada otorisasi akses sumber daya, tanpa persyaratan yang berarti untuk memverifikasi atau mewakili identitas pengguna tertentu.

Pertimbangan Keamanan dan Kesalahan Umum

Karena OIDC menangani verifikasi identitas yang mendasari akses ke aplikasi dan data sensitif, implementasi yang benar sangat penting, dan beberapa kesalahan berulang menjadi penyebab sebagian besar masalah keamanan di dunia nyata yang muncul dalam praktik.

Kegagalan untuk memvalidasi parameter status selama pengalihan kembali dari Penyedia OpenID adalah salah satu kesalahan implementasi yang paling umum, dan hal ini membuat aplikasi rentan terhadap serangan cross-site request forgery (CSRF) di mana penyerang berpotensi menipu browser pengguna untuk menyelesaikan alur autentikasi yang sebenarnya tidak dimulai oleh pengguna tersebut. Demikian pula, kegagalan untuk memvalidasi setiap klaim yang relevan di dalam token ID yang diterima dengan benar — tidak hanya memeriksa bahwa tanda tangan valid, tetapi juga mengkonfirmasi bahwa klaim iss cocok dengan penyedia yang diharapkan, klaim aud cocok dengan ID klien aplikasi itu sendiri, dan klaim exp menunjukkan bahwa token belum kedaluwarsa — menciptakan celah untuk berbagai serangan substitusi token dan serangan pemutaran ulang yang akan ditolak secara otomatis oleh implementasi yang sepenuhnya benar.

Refresh token memerlukan perhatian keamanan khusus karena seberapa banyak akses terautentikasi yang dapat diberikannya jika disalahgunakan: karena refresh token dapat digunakan untuk membuat token akses dan ID baru dalam jangka waktu yang lama, bahkan berpotensi ketika pengguna yang sah tidak hadir secara aktif atau tidak memperhatikan, penyimpanan dan penanganan refresh token yang aman — dienkripsi saat disimpan, hanya ditransmisikan melalui TLS, dan idealnya dirotasi setiap kali digunakan — merupakan persyaratan keamanan yang nyata, bukan praktik terbaik opsional. Pemantauan berkelanjutan untuk pola penggunaan token yang anomali, dikombinasikan dengan jendela kedaluwarsa token akses yang cukup singkat yang membatasi jendela kerusakan jika token pernah disalahgunakan, melengkapi postur keamanan inti yang harus dipertahankan oleh setiap implementasi OIDC yang serius.

Terakhir, mengandalkan sepenuhnya pada validasi token berbasis browser sisi klien tanpa langkah verifikasi sisi server — kesalahan yang lebih umum dalam implementasi aplikasi satu halaman yang dibuat dengan cepat daripada dalam sistem yang dirancang dengan benar — merusak sebagian besar nilai keamanan yang secara khusus dirancang untuk diberikan oleh penandatanganan kriptografi OIDC, karena lingkungan browser secara inheren lebih rentan terhadap perusakan daripada server backend yang diamankan dengan benar.

Mengimplementasikan OIDC: Gambaran Praktis

Bagi tim developer yang benar-benar mengimplementasikan OIDC, bukan sekadar mengintegrasikan dengan tombol "Masuk dengan Google" yang sudah ada, titik awal praktisnya adalah memilih Penyedia OpenID tepercaya yang sesuai dengan konteks aplikasi — umumnya Google, Microsoft Entra ID, Okta, Auth0, atau Amazon Cognito untuk sebagian besar skenario konsumen dan perusahaan, meskipun penyedia yang sesuai dengan OIDC mana pun akan beroperasi dengan benar mengingat desain protokol yang terstandarisasi.

Aplikasi kemudian harus didaftarkan ke penyedia yang dipilih, sebuah proses yang menghasilkan ID klien (dan, untuk aplikasi sisi server yang bersifat rahasia, rahasia klien) yang mengidentifikasi aplikasi spesifik ke penyedia di setiap permintaan berikutnya, bersama dengan pendaftaran satu atau lebih URI pengalihan yang diizinkan yang hanya akan digunakan penyedia untuk mengirimkan respons otentikasi — kontrol keamanan yang mencegah kode otorisasi dan token dialihkan ke tujuan yang dikendalikan penyerang.

Dari situ, implementasi umumnya dilakukan melalui salah satu library klien OIDC yang matang dan teruji dengan baik yang tersedia untuk hampir setiap bahasa pemrograman dan framework utama, daripada membuat sendiri logika validasi token, verifikasi tanda tangan, dan orkestrasi alur dari awal — sebuah praktik yang benar-benar bermanfaat mengingat banyaknya detail keamanan yang rumit, beberapa di antaranya telah dijelaskan di bagian pertimbangan keamanan di atas, yang perlu diperhatikan dengan benar dalam implementasi dari awal. Sebagian besar framework web modern dan platform cloud juga menyediakan modul integrasi OIDC bawaan atau pihak pertama yang menangani sebagian besar kompleksitas implementasi ini secara langsung, sehingga mengurangi apa yang dulunya merupakan pekerjaan besar menjadi tugas konfigurasi yang relatif sederhana.

Jadi, OpenID Connect memecahkan masalah yang benar-benar penting dan, sebelum kehadirannya, benar-benar belum terpecahkan, yaitu OAuth 2.0 memberi industri perangkat lunak cara yang sangat baik dan diadopsi secara luas untuk mendelegasikan otorisasi tanpa berbagi kata sandi, tetapi secara sengaja membiarkan pertanyaan tentang identitas pengguna yang terverifikasi tidak terjawab, dan setiap penyedia identitas yang mencoba mengisi celah itu sendiri sebelum kehadiran OIDC melakukannya dengan cara yang saling tidak kompatibel dan bersifat eksklusif yang membuat setiap integrasi baru menjadi proyek rekayasa khusus.