Single Sign-On (SSO): Praktis Tapi Ringkih?

Single Sign-On (SSO): Praktis Tapi Ringkih? – Single Sign-On (SSO) menyederhanakan akses dengan mengizinkan pengguna masuk ke berbagai sistem hanya dengan satu pasang kredensial.

Meski memberikan efisiensi nyata pada proses autentikasi, kenyamanan ini menyimpan risiko terpusat yang besar. Kasus kebocoran data di University of Pennsylvania pada tahun 2025 menjadi buktinya.

Dalam insiden tersebut, penyerang berhasil membobol satu akun SSO PennKey dan menggunakan akses tersebut untuk menyusup ke sistem internal seperti:

• VPN.
• Salesforce.
• Qlik
• SAP
• Dan SharePoint.

Dan yang terjadi adalah, memberi dampak nyata dengan data milik 1,2 juta individu sukses digondol peretas.

Kasus ini tidak berarti SSO tidak aman. Jika dikonfigurasi dan dilindungi dengan benar, SSO justru meningkatkan keamanan dengan mengurangi penumpukan kata sandi (password sprawl), menyentralisasi kebijakan akses, dan mempermudah penerapan Multi-Factor Authentication (MFA).

Namun, manfaat ini hanya bisa dipetik jika organisasi memperlakukan SSO sebagai kontrol keamanan yang kritis. Jika satu kali login bisa membuka pintu ke banyak sistem, maka login tersebut wajib diberi perlindungan ekstra ketat.

Pertanyaannya: Apakah login SSO Anda sudah cukup aman? Untuk menjawabnya, organisasi harus melihat lebih jauh dari sekadar “apakah SSO sudah aktif”, dan mulai fokus pada “bagaimana SSO tersebut diamankan”.

1. Mulai dengan Kata Sandi SSO yang Kuat

Anjuran menggunakan kata sandi yang kuat memang bukan hal baru, tetapi mutlak diperlukan jika satu kredensial memegang kunci ke banyak sistem.

Menariknya, kuat tidak harus menyulitkan pengguna; toh, esensi SSO adalah mengurangi hambatan saat autentikasi.

Panduan terbaru dari NIST menekankan pada aspek panjang karakter dan kemudahan penggunaan, serta penyaringan terhadap kata sandi yang lemah atau telah bocor.

• Tanpa MFA: Jika skenario autentikasi satu faktor masih diizinkan, NIST merekomendasikan panjang minimal 15 karakter.
• Dengan MFA: Kata sandi yang dikombinasikan dengan MFA minimal harus 8 karakter, dan sistem harus memfasilitasi pengguna untuk membuat kata sandi hingga 64 karakter.
• NIST juga menyarankan organisasi untuk mencocokkan kata sandi baru dengan daftar cekal (blocklist) berisi kata sandi yang pasaran atau yang pernah bocor.
• Tinggalkan Aturan Usang: NIST tidak lagi menyarankan aturan lama seperti kewajiban mencampur karakter rumit secara acak atau reset kata sandi berkala secara rutin. Aturan usang ini justru memicu pengguna membuat pola yang mudah ditebak (misalnya hanya mengganti angka paling belakang atau menambah simbol di akhir).

2. Terapkan MFA Kebal Serangan Modern

Kata sandi SSO yang kuat tidak boleh menjadi satu-satunya benteng pertahanan. Maraknya infostealer saat ini memudahkan penyerang menguras kata sandi dan data autentikasi dari jarak jauh.

MFA memberikan lapisan perlindungan tambahan agar kata sandi yang telanjur bocor tidak langsung berujung pada pembobolan akun.

Pada sistem SSO, MFA harus diterapkan secara konsisten di seluruh pengguna, aplikasi, dan skenario akses—bukan hanya untuk segelintir akun “berisiko tinggi”.

Perhatikan juga jenis MFA yang digunakan. Kode OTP via SMS memang lebih baik daripada tidak ada sama sekali, tetapi itu bukan opsi terkuat.

Jika memungkinkan, beralihlah ke metode MFA yang kebal peretasan phishing (phishing-resistant), seperti kunci keamanan FIDO2, WebAuthn, atau passkeys, terutama untuk akun administrator dan akses ke sistem sensitif.

3. Amankan Aset di Balik Login SSO

Organisasi juga wajib mengamankan aset-aset yang berada di balik pintu SSO serta mengontrol bagaimana identitas diterbitkan dan dipercayai.

• Akun Admin IdP (Identity Provider): Akun ini memegang kendali untuk mengubah kebijakan autentikasi dan mereset pengguna. Lindungi akun admin dengan phishing-resistant MFA, pisahkan akun admin dari akun kerja harian, terapkan just-in-time access, dan pantau aktivitasnya secara ketat.
• Sertifikat Digital & Kunci Enkripsi: Sertifikat SAML dan kunci penandatangan token (token-signing keys) adalah landasan aplikasi untuk memercayai IdP. Jika bocor, penyerang bisa memalsukan identitas pengguna secara sah. Batasi aksesnya dan lakukan rotasi berkala sebelum kedaluwarsa.
• Kredensial OAuth: Client secrets, kredensial aplikasi, dan refresh tokens dapat memberi penyerang akses jangka panjang tanpa perlu login ulang. Simpan aset ini di dalam vault khusus dan tinjau izin aplikasi secara berkala.
• Hak Akses Pihak Ketiga (Consent Grants): Peretas kerap mencari celah mempertahankan akses lewat izin aplikasi pihak ketiga yang longgar. Batasi persetujuan otomatis dari pengguna dan wajibkan persetujuan admin untuk izin yang sensitif.

Apakah SSO Aman?

SSO tetap sangat layak digunakan selama diimplementasikan dan dilindungi dengan benar. Dari sisi pengguna, SSO mempermudah akses karena mereka tidak perlu mengingat banyak kata sandi. Bagi tim IT, hal ini mengurangi beban kerja helpdesk akibat laporan lupa kata sandi atau akun terkunci.

Dari sudut pandang keamanan, SSO memberikan kendali terpusat untuk mengelola autentikasi. Aplikasi tidak perlu menyimpan kata sandi pengguna secara langsung, melainkan mengandalkan token autentikasi yang aman.

Sentralisasi ini juga mempermudah kepatuhan regulasi (compliance), audit, serta pencabutan hak akses secara cepat saat ada karyawan yang keluar.

SSO memang tidak otomatis aman sejak awal. Namun, ketika dikonfigurasi dengan pengamanan yang ketat (hardened), SSO mampu meningkatkan pengalaman pengguna sekaligus memperkokoh postur keamanan organisasi.

Sumber berita:

WeLiveSecurity