Apa itu Single Sign-On (SSO)? Panduan Lengkap

Apa Sebenarnya Single Sign-On Itu

Single Sign-On (SSO) adalah mekanisme autentikasi yang memungkinkan pengguna untuk masuk (log in) satu kali menggunakan satu set kredensial, lalu mendapatkan akses ke berbagai aplikasi dan sistem yang terpisah dan independen tanpa perlu masuk kembali secara terpisah pada masing-masing aplikasi tersebut. Identitas pengguna diverifikasi satu kali oleh satu sistem pusat yang tepercaya, dan verifikasi tersebut kemudian diakui serta diterima oleh setiap aplikasi lain dalam ekosistem organisasi yang telah dikonfigurasi untuk memercayai sistem pusat tersebut.

Penting untuk memahami secara tepat apa yang sebenarnya dilakukan SSO pada tingkat konseptual, karena frasa "masuk satu kali" bisa sedikit menyesatkan jika ditafsirkan secara harfiah. SSO tidak berarti bahwa satu peristiwa masuk secara ajaib disebarkan ke setiap aplikasi yang mungkin kita gunakan. Yang sebenarnya terjadi adalah satu sistem pusat yang tepercaya mengautentikasi kita, lalu menerbitkan bukti autentikasi yang dapat diverifikasi secara kriptografis—berupa token atau assertion, tergantung pada protokol spesifik yang digunakan—yang dapat diperiksa dan dipercaya secara independen oleh aplikasi lain. Aplikasi-aplikasi tersebut tidak perlu lagi meminta kata sandi kita, dan sering kali bahkan tidak pernah melihat kata sandi asli kita sama sekali. Secara teknis, setiap aplikasi yang kita kunjungi tetap memverifikasi identitas kita; perbedaannya, aplikasi tersebut melakukannya dengan memeriksa bukti tepercaya dari autentikasi sebelumnya, alih-alih mengumpulkan dan memverifikasi kredensial kita secara langsung satu per satu untuk setiap aplikasi.

Masalah Utama yang Diatasi SSO

Tanpa SSO, setiap aplikasi yang digunakan organisasi harus mengelola database kredensial pengguna secara mandiri, dan setiap pengguna harus mendaftar, mengingat, serta memperbarui kata sandi secara terpisah untuk setiap aplikasi tersebut. Hal ini memicu serangkaian masalah praktis dan keamanan yang serius. Fenomena kelelahan akibat banyaknya kata sandi (password fatigue) muncul dengan cepat dan mendorong perilaku manusia yang dapat diprediksi serta telah banyak didokumentasikan, yaitu orang cenderung menggunakan kembali kata sandi yang sama (atau variasi yang mirip) untuk berbagai layanan. Akibatnya, kebocoran satu kata sandi pada salah satu layanan dapat berpotensi membahayakan akun pengguna di layanan lain—sebuah teknik serangan yang dikenal luas sebagai credential stuffing. Beban kerja administratif pun meningkat drastis karena tim TI harus mengelola proses pembuatan dan penghapusan akun secara terpisah untuk setiap aplikasi. Selain itu, momen krusial saat karyawan keluar dari organisasi—ketika semua akun mereka harus segera dinonaktifkan secara pasti dan andal—menjadi proses yang jauh lebih sulit dan rentan kesalahan jika harus dilakukan secara konsisten di puluhan sistem yang terpisah dan tidak saling terhubung. Biaya layanan bantuan (help desk) juga meningkat sebagai konsekuensi langsung dan dapat diprediksi dari semua hal ini, mengingat sebagian besar tiket dukungan TI rutin di banyak organisasi pada praktiknya hanyalah permintaan pengaturan ulang kata sandi.

SSO mengatasi setiap masalah tersebut secara langsung dan spesifik dengan memusatkan autentikasi ke dalam satu sistem khusus. Pengguna hanya perlu mengingat dan mengelola satu set kredensial, bukan puluhan. Administrator dapat memberikan akses atau—yang tak kalah penting—mencabut akses karyawan yang keluar dari semua aplikasi yang terhubung secara instan dan terpusat, tanpa perlu melacak dan menonaktifkan puluhan akun individu yang tersebar di berbagai sistem secara terpisah. Selain itu, karena logika autentikasi berada dalam satu sistem pusat yang terawat dengan baik dan berfokus pada keamanan—alih-alih diimplementasikan secara terpisah dan berulang (sering kali dengan tingkat ketatnya keamanan yang bervariasi) di dalam puluhan aplikasi—maka postur keamanan infrastruktur autentikasi organisasi secara keseluruhan menjadi jauh lebih mudah untuk dipahami, dipantau, dan ditingkatkan secara konsisten.

Penyedia Identitas (Identity Provider) dan Penyedia Layanan (Service Provider)

Penyedia Identitas—yang secara umum disingkat sebagai IdP—adalah sistem pusat tepercaya yang secara khusus bertanggung jawab untuk melakukan autentikasi pengguna; sistem ini memverifikasi nama pengguna dan kata sandi (serta sering kali menyertakan langkah autentikasi multi-faktor tambahan saat ini), lalu menerbitkan bukti autentikasi yang dapat diverifikasi dan dipercaya oleh aplikasi lain. Contoh penyedia identitas yang terkenal meliputi Okta, Microsoft Entra ID (sebelumnya dikenal sebagai Azure Active Directory), Ping Identity, dan Google Workspace, di antara berbagai platform pesaing lain yang sepadan; namun, banyak organisasi juga menjalankan perangkat lunak penyedia identitas kustom yang mereka kelola sendiri (self-hosted) alih-alih mengandalkan platform eksternal yang disediakan secara komersial tersebut.

Penyedia Layanan—yang secara umum disingkat sebagai SP (dan dalam konteks protokol tertentu, khususnya OAuth dan OpenID Connect, lebih sering disebut sebagai Relying Party)—adalah aplikasi apa pun yang ingin diakses oleh pengguna. Aplikasi ini telah dikonfigurasi secara khusus untuk memercayai pernyataan autentikasi yang berasal dari Penyedia Identitas tertentu yang telah ditetapkan, alih-alih menangani dan memverifikasi kredensial masuk pengguna secara mandiri dan terpisah. Alat manajemen proyek perusahaan, sistem pelaporan biaya internal, dan platform dukungan pelanggan dapat berfungsi sebagai penyedia layanan yang terpisah satu sama lain, namun semuanya dikonfigurasi untuk memercayai satu penyedia identitas pusat yang sama dalam melakukan autentikasi pengguna mereka.

Pemisahan peran dan tanggung jawab yang jelas ini merupakan konsep arsitektur mendasar yang melandasi seluruh sistem SSO: tugas spesifik—yang sering kali sangat kompleks dan krusial bagi keamanan—untuk memverifikasi identitas pengguna dipusatkan pada satu sistem khusus yang dikelola dengan baik (yaitu penyedia identitas). Sementara itu, berbagai aplikasi individual yang ingin dan perlu digunakan oleh pengguna terbebas dari beban untuk menerapkan sendiri logika autentikasi kompleks tersebut secara mandiri dan terpisah; sebaliknya, aplikasi-aplikasi ini cukup memercayai pernyataan terverifikasi yang telah dihasilkan oleh sistem yang memang dibangun dan dipercaya secara khusus untuk menangani tugas tersebut dengan baik.

Hubungan Kepercayaan yang Memungkinkan SSO

Pada dasarnya, SSO dapat berfungsi karena adanya hubungan kepercayaan formal yang sengaja dibangun dan dikonfigurasi sebelumnya antara penyedia identitas (identity provider) dan setiap penyedia layanan (service provider) yang ingin mengandalkannya.

Dalam praktiknya, hubungan kepercayaan ini dibangun melalui pertukaran dan konfigurasi kunci kriptografis serta metadata khusus di antara kedua belah pihak. Proses ini umumnya dilakukan satu kali sebagai langkah pengaturan awal oleh administrator di masing-masing pihak, jauh sebelum pengguna akhir mencoba masuk (login) melalui koneksi yang telah dikonfigurasi tersebut. Penyedia identitas dikonfigurasi dengan informasi spesifik mengenai penyedia layanan mana saja yang akan mereka layani dengan menerbitkan pernyataan autentikasi (authentication assertion). Sebaliknya, setiap penyedia layanan dikonfigurasi dengan kunci publik khusus yang diperlukan untuk memverifikasi secara mandiri bahwa setiap pernyataan autentikasi yang diterimanya benar-benar ditandatangani oleh penyedia identitas tepercaya yang telah ditetapkan sebelumnya—dan bukan oleh pihak lain yang tidak terkait, berpotensi berbahaya, atau tidak berwenang yang mencoba menyamar sebagai penyedia tepercaya tersebut.

Proses penandatanganan dan verifikasi kriptografis inilah yang memungkinkan penyedia layanan memercayai pernyataan autentikasi yang diterimanya tanpa perlu menghubungi penyedia identitas secara langsung dan mandiri pada saat pernyataan tersebut diterima. Secara matematis, tanda tangan digital yang disertakan pada pernyataan tersebut sudah cukup untuk membuktikan dua hal, yaitu bahwa pernyataan itu benar-benar berasal dari penyedia identitas yang tepat dan tepercaya, serta bahwa isinya tidak pernah diubah atau dimanipulasi oleh siapa pun sejak pertama kali diterbitkan secara sah.

Cara Kerja Alur Login SSO yang Umum

Alur ini umumnya bermula saat pengguna mencoba mengakses aplikasi penyedia layanan tertentu—misalnya, alat manajemen proyek—yang belum mereka akses melalui proses autentikasi khusus dalam sesi penjelajahan saat ini. Penyedia layanan mendeteksi bahwa pengguna tersebut belum memiliki sesi yang valid dan aktif dengan layanan mereka. Alih-alih menampilkan formulir masuk khusus miliknya sendiri secara langsung, penyedia layanan mengalihkan browser pengguna ke penyedia identitas (identity provider) yang telah ditetapkan dan dikonfigurasi oleh organisasi. Pengalihan ini disertai permintaan khusus yang menunjukkan secara persis penyedia layanan mana yang sedang meminta autentikasi tersebut.

Jika pengguna belum memiliki sesi aktif dengan penyedia identitas (misalnya, jika ini adalah aplikasi pertama yang mereka coba akses pada hari itu), penyedia identitas akan menampilkan formulir masuknya sendiri, dan pengguna memasukkan nama pengguna serta kata sandi mereka (sering kali diikuti dengan langkah autentikasi multi-faktor tambahan). Jika pengguna sudah memiliki sesi aktif dengan penyedia identitas—misalnya, karena mereka sebelumnya telah masuk ke aplikasi lain yang sama sekali berbeda pada hari yang sama—langkah ini akan dilewati secara otomatis dan sepenuhnya. Penyedia identitas kemudian langsung melanjutkan ke langkah berikutnya tanpa mengharuskan pengguna melakukan tindakan apa pun. Perilaku inilah yang menciptakan pengalaman "masuk sekali saja" yang pada praktiknya sering dikaitkan orang dengan SSO.

Setelah identitas pengguna berhasil diverifikasi oleh penyedia identitas—baik melalui proses masuk yang baru saja diselesaikan maupun melalui sesi sebelumnya yang masih valid—penyedia identitas akan membuat pernyataan autentikasi (authentication assertion) yang ditandatangani secara kriptografis. Pernyataan ini diimplementasikan—tergantung pada protokol spesifik yang digunakan—sebagai pernyataan SAML atau token OAuth/OIDC. Penyedia identitas kemudian mengalihkan kembali browser pengguna ke penyedia layanan awal yang ingin diakses, dengan menyertakan pernyataan yang baru dibuat tersebut sebagai bagian dari proses pengalihan itu.

Penyedia layanan menerima pernyataan tersebut, memverifikasi tanda tangannya secara kriptografis menggunakan kunci publik milik penyedia identitas yang telah dikonfigurasi sebelumnya (untuk memastikan keaslian pernyataan serta menjamin bahwa isinya tidak diubah sedikit pun sejak pertama kali diterbitkan), mengekstrak identitas pengguna serta atribut relevan lainnya yang terkandung di dalamnya, dan—setelah menyelesaikan seluruh proses verifikasi ini—membentuk sesi lokal bagi pengguna yang kini telah terautentikasi; pada tahap inilah pengguna akhirnya berhasil masuk ke aplikasi tersebut tanpa perlu memasukkan kata sandi secara langsung pada antarmuka penyedia layanan itu sendiri.

SAML: Standar Perusahaan

Pada intinya, sebuah assertion SAML (Security Assertion Markup Language ) adalah dokumen XML yang memuat serangkaian pernyataan spesifik mengenai pengguna yang telah diautentikasi: bahwa pengguna tersebut benar-benar telah berhasil diautentikasi oleh penyedia identitas pada waktu tertentu, serta (opsional) pernyataan atribut tambahan yang memberikan informasi relevan lainnya tentang pengguna tersebut—seperti alamat email, departemen atau peran spesifik dalam organisasi, keanggotaan grup tertentu, atau atribut relevan lainnya yang dipilih secara khusus oleh organisasi untuk disertakan. Seluruh assertion ini ditandatangani secara digital oleh penyedia identitas menggunakan kunci privatnya sendiri; tanda tangan digital inilah yang kemudian diverifikasi secara independen oleh penyedia layanan penerima menggunakan kunci publik penyedia identitas yang bersesuaian, persis seperti yang dijelaskan dalam bagian mengenai hubungan kepercayaan (trust relationship) di atas.

Secara historis, SAML sangat diminati di lingkungan perusahaan besar yang mapan, instansi pemerintah, dan industri dengan regulasi ketat. Hal ini terutama disebabkan oleh fakta bahwa SAML muncul jauh lebih awal dibandingkan beberapa protokol alternatif yang lebih modern, sehingga memiliki keuntungan berupa basis software perusahaan yang sangat luas dan sudah lama ada yang mendukungnya secara bawaan. Kekurangan paling signifikan yang sering disebut-sebut adalah implementasinya yang terasa cukup berat dan bertele-tele, terutama jika dibandingkan dengan alternatif modern berbasis JSON; dalam praktiknya, proses parsing dan validasi XML umumnya dianggap jauh lebih rumit dibandingkan dengan pemrosesan token berbasis JSON yang lebih sederhana dan ringkas, yang biasanya menjadi andalan protokol-protokol modern yang dibahas pada bagian selanjutnya.

OAuth 2.0 dan OpenID Connect

Penting untuk memperjelas satu hal yang sering kali membingungkan banyak orang saat pertama kali mengenal bidang ini: OAuth 2.0, jika dilihat secara terpisah, sebenarnya bukanlah protokol autentikasi sama sekali; pada dasarnya, ini adalah kerangka kerja otorisasi. Protokol ini dirancang khusus agar satu aplikasi dapat diberikan akses terbatas dan dengan cakupan spesifik terhadap sumber daya atau data pengguna di layanan lain yang sepenuhnya terpisah, tanpa aplikasi pertama tersebut perlu melihat atau menangani secara langsung kata sandi pengguna untuk layanan kedua itu. OpenID Connect (OIDC) adalah lapisan identitas yang relatif sederhana namun sangat penting; lapisan ini dibangun langsung di atas kerangka kerja dasar OAuth 2.0 dan menambahkan komponen yang diperlukan untuk mendukung autentikasi yang sesungguhnya. Komponen utamanya adalah ID token khusus—yang diimplementasikan sebagai JSON Web Token (JWT)—yang secara spesifik dan eksplisit menyatakan identitas terverifikasi pengguna. Token ini berbeda dari access token biasa (yang menjadi fokus utama spesifikasi inti OAuth); access token tersebut secara khusus ditujukan untuk mengizinkan akses berkelanjutan ke sumber daya terlindungi tertentu, bukan untuk menyatakan identitas dasar pengguna secara langsung.

Saat kita melihat tombol "Masuk dengan Google" atau "Masuk dengan Microsoft" di website atau aplikasi pihak ketiga, proses teknis yang sebenarnya terjadi di balik tombol sederhana tersebut sering kali merupakan alur OpenID Connect: aplikasi pihak ketiga mengarahkan kita ke halaman masuk Google atau Microsoft (yang dalam konteks ini berperan sebagai penyedia identitas atau identity provider), kita melakukan autentikasi langsung dengan mereka di sana, dan kemudian mereka menerbitkan ID token yang telah ditandatangani. Aplikasi pihak ketiga tersebut (yang dalam konteks ini berperan sebagai pihak yang mengandalkan identitas atau relying party) kemudian dapat memverifikasi token tersebut secara independen dan menggunakannya untuk memastikan identitas kita yang sebenarnya.

OIDC telah menjadi sangat dominan, khususnya dalam pengembangan aplikasi modern yang bersifat cloud-native. Hal ini sebagian besar disebabkan oleh token berbasis JSON-nya yang—dari sudut pandang pengalaman developer—jauh lebih sederhana untuk digunakan dibandingkan dengan assertion berbasis XML milik SAML yang cenderung lebih berat dan bertele-tele. Selain itu, OIDC juga terintegrasi secara alami dan mulus dengan REST API serta konvensi arsitektur berbasis JSON yang mendominasi sebagian besar pengembangan aplikasi web dan seluler modern saat ini.

SAML vs. OIDC: Mana yang Sebenarnya Digunakan dan Di Mana

SAML tetap sangat dominan dalam software perusahaan berskala besar yang sudah mapan—seperti sistem SDM (HR) tradisional yang sudah lama ada, platform pelaporan biaya, dan aplikasi bisnis inti perusahaan warisan lainnya yang sering kali dibangun lebih dari satu dekade lalu dan terus dipelihara serta digunakan hingga saat ini. Protokol ini juga umum digunakan dalam industri dengan regulasi ketat dan lingkungan pemerintahan, karena rekam jejaknya yang panjang dan terdokumentasi secara luas, serta dukungannya yang kaya dan matang terhadap keputusan otorisasi berbasis atribut yang mendetail—hal-hal yang sangat dihargai secara khusus dalam konteks tersebut.

OIDC mendominasi aplikasi modern yang ditujukan bagi konsumen, software perusahaan cloud-native masa kini, dan hampir semua pengembangan aplikasi seluler. Kesederhanaan teknisnya, kecocokan alaminya dengan arsitektur API berbasis REST, serta dukungannya yang luas di hampir semua framework dan platform pengembangan modern menjadikannya pilihan utama yang paling logis dan alami untuk setiap aplikasi baru yang dikembangkan saat ini.

Dalam praktiknya, banyak organisasi besar yang lebih mapan akhirnya perlu mendukung kedua protokol tersebut secara bersamaan. Hal ini dikarenakan portofolio aplikasi mereka biasanya mencakup software perusahaan warisan (legacy) yang hanya mendukung SAML, serta aplikasi yang jauh lebih baru dan modern yang memang dirancang menggunakan OIDC sejak awal. Oleh karena itu, penyedia layanan identitas (identity provider) modern umumnya dirancang untuk mendukung kedua protokol tersebut secara berdampingan. Tujuannya adalah agar satu penyedia identitas terpadu dapat berfungsi sebagai otoritas otentikasi pusat bagi seluruh portofolio aplikasi organisasi, terlepas dari protokol mana yang digunakan secara internal oleh masing-masing aplikasi tersebut.

SSO yang Dimulai oleh Penyedia Layanan (SP-initiated) vs. SSO yang Dimulai oleh Penyedia Identitas (IdP-initiated)

SSO yang dimulai oleh penyedia layanan (Service Provider-initiated atau SP-initiated) adalah alur yang telah dijelaskan secara rinci sebelumnya dalam panduan ini, yaitu pengguna mencoba mengakses aplikasi tertentu secara langsung, aplikasi tersebut mendeteksi bahwa belum ada sesi aktif yang valid untuk pengguna tersebut, lalu mengarahkan pengguna ke penyedia identitas untuk proses autentikasi, sebelum akhirnya mengembalikan pengguna ke aplikasi yang ingin mereka akses sejak awal.

Sebaliknya, SSO yang dimulai oleh penyedia identitas (Identity Provider-initiated atau IdP-initiated) bermula langsung di penyedia identitas itu sendiri, bukan di aplikasi penyedia layanan tertentu. Pengguna pertama-tama masuk (login) ke dasbor atau portal terpusat yang dikelola oleh penyedia identitas—yang biasanya menampilkan, misalnya, kisi-kisi ikon yang mewakili setiap aplikasi yang dapat mereka akses—dan dari sana, mereka cukup mengeklik aplikasi spesifik yang ingin mereka gunakan. Penyedia identitas segera membuat assertion (pernyataan identitas) yang relevan di tempat, tanpa pernah menerima permintaan masuk spesifik apa pun dari aplikasi tersebut sebelumnya, lalu mengirimkan browser pengguna—beserta assertion yang baru dibuat tersebut—langsung ke aplikasi tujuan.

Kedua alur ini umum digunakan dalam praktik nyata, dan sebagian besar penyedia identitas yang andal mendukung keduanya secara bersamaan. Alur yang dimulai oleh IdP (IdP-initiated) sangat populer untuk pengalaman pengguna bergaya "peluncur aplikasi" atau dasbor yang ingin disediakan oleh banyak organisasi bagi karyawan mereka, sedangkan alur yang dimulai oleh SP (SP-initiated) sangat penting untuk menangani skenario sehari-hari yang umum terjadi, di mana pengguna langsung membuka atau mengeklik tautan (bookmark) yang mengarah ke URL aplikasi tertentu tanpa harus melewati dasbor terpisah milik penyedia identitas terlebih dahulu.

Risiko Keamanan SSO

Kekhawatiran yang paling sering muncul adalah bahwa SSO menciptakan titik kegagalan tunggal (single point of failure) bagi seluruh infrastruktur autentikasi organisasi. Jika akun penyedia identitas (identity provider) pengguna berhasil dibobol—baik melalui phishing, pencurian kredensial, atau vektor serangan lainnya—penyerang berpotensi mendapatkan akses tidak hanya ke satu aplikasi terisolasi, melainkan ke setiap aplikasi yang terhubung dengan akun tersebut melalui SSO. Risiko nyata yang sudah dipahami dengan baik inilah yang menjadikan penerapan SSO bersamaan dengan autentikasi multi-faktor yang benar-benar kuat di tingkat penyedia identitas sebagai praktik terbaik yang wajib dan tidak dapat ditawar, bukan sekadar tambahan opsional atau pelengkap semata.

Penyedia identitas itu sendiri, secara alami, menjadi target yang jauh lebih menarik dan bernilai tinggi bagi penyerang, khususnya karena akses luas yang dimungkinkannya. Pembobolan yang berhasil di tingkat penyedia identitas—bukan sekadar pada satu aplikasi individual yang terhubung dengannya—memiliki potensi nyata untuk mengompromikan seluruh ekosistem aplikasi organisasi secara bersamaan. Oleh karena itu, penyedia identitas harus—dan memang perlu—memenuhi standar keamanan yang sangat ketat, serta menjalani pemantauan dan ketelitian operasional yang berkelanjutan.

Risiko kesalahan konfigurasi merupakan kekhawatiran nyata dan praktis lainnya. Implementasi SSO, khususnya yang berbasis SAML, melibatkan sejumlah besar detail konfigurasi—seperti hubungan kepercayaan, praktik pengelolaan sertifikat, dan pemetaan atribut yang tepat antar-sistem. Kesalahan pada salah satu titik konfigurasi ini berpotensi menciptakan kerentanan keamanan nyata yang dapat dieksploitasi, atau sebaliknya, menyebabkan kegagalan login yang membuat frustrasi dan sulit didiagnosis bagi pengguna sah yang memiliki wewenang penuh saat mereka mencoba melakukan pekerjaan mereka.

Jadi, Single Sign-On (SSO) mengatasi masalah mendasar yang muncul secara alami dan dapat diprediksi seiring berkembangnya kumpulan aplikasi software yang terpisah-pisah dalam suatu organisasi, yaitu beban yang kian berat dan tidak berkelanjutan—baik bagi pengguna akhir maupun administrator TI—dalam mengelola secara terpisah sejumlah kredensial unik yang terus bertambah di berbagai sistem yang tidak saling terhubung. Dengan memusatkan proses autentikasi pada satu penyedia identitas tepercaya, serta membuat aplikasi penyedia layanan mengandalkan bukti autentikasi yang telah ditandatangani dan dapat diverifikasi secara kriptografis—alih-alih setiap aplikasi mengumpulkan dan memverifikasi kredensial secara mandiri dan berulang—SSO menghadirkan peningkatan nyata dan signifikan dalam hal kenyamanan pengguna, efisiensi administratif secara keseluruhan, dan—jika diterapkan dengan tepat dan cermat—juga dalam postur keamanan organisasi secara mendasar.