# SSO Adalah: Pengertian, Cara Kerja, dan Contohnya

> SSO adalah cara login sekali untuk banyak aplikasi. Pahami istilah IdP, cara kerja, SAML vs OpenID Connect, manfaat, risiko, dan cara menerapkannya.

**URL:** https://www.ciptadusa.com/blog/sso-adalah  
**Type:** blog  
**Author:** PT Cipta Dua Saudara  
**Category:** Keamanan Aplikasi  
**Published:** 2026-11-05  
**Cover:** https://www.ciptadusa.com/media/uploads/blog/2026-11/1793845394121-sso-adalah-20261105.webp  

## Article

SSO (single sign-on) adalah cara login yang membuat pengguna cukup masuk satu kali untuk membuka banyak aplikasi. NIST mendefinisikan SSO sebagai proses autentikasi yang memakai satu akun beserta autentikatornya untuk mengakses banyak aplikasi secara mulus, dan umumnya diterapkan dengan protokol federasi ([sumber](https://csrc.nist.gov/glossary/term/single_sign_on)).

Contoh yang paling sering ditemui: karyawan login sekali di pagi hari, lalu bisa membuka email, ERP, CRM, dan dashboard internal tanpa diminta password lagi. Artikel ini membahas pengertian SSO, istilah yang perlu dipahami, cara kerjanya, protokol yang dipakai (SAML dan OpenID Connect), manfaat dan risikonya, serta langkah menerapkannya di aplikasi bisnis.

## Pengertian SSO

Microsoft menjelaskan SSO secara sederhana: pengguna masuk sekali dan bisa menjangkau banyak aplikasi, dengan satu set kredensial ([sumber](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)). Kredensial di sini bisa berupa password, kode MFA, passkey, atau kombinasinya.

Yang membuat SSO berbeda dari "pakai password yang sama di semua aplikasi" adalah letak proses loginnya. Dengan SSO, aplikasi tidak lagi memeriksa password sendiri. Pemeriksaan dilakukan di satu tempat terpusat, lalu aplikasi hanya menerima bukti bahwa pengguna sudah berhasil login.

### Istilah Penting dalam SSO

| Istilah | Arti |
|---|---|
| Identity Provider (IdP) | Sistem pusat yang memeriksa identitas pengguna dan menerbitkan bukti login. SAML menyebut peran ini identity provider ([sumber](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)) |
| Service Provider (SP) / Relying Party | Aplikasi yang dipakai pengguna dan memercayai bukti login dari IdP. SAML menyebutnya service provider ([sumber](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)) |
| Federasi | Hubungan saling percaya antara IdP dan aplikasi, yang menjadi dasar kebanyakan implementasi SSO ([sumber](https://csrc.nist.gov/glossary/term/single_sign_on)) |
| Assertion (SAML) | Pernyataan dari IdP tentang pengguna yang sudah login, dikirim ke aplikasi |
| ID Token (OpenID Connect) | Token keamanan berisi klaim tentang autentikasi pengguna, berbentuk JSON Web Token ([sumber](https://openid.net/specs/openid-connect-core-1_0.html)) |
| Sesi | Status "sudah login" yang disimpan IdP dan masing-masing aplikasi |

## Cara Kerja SSO

Detailnya bergantung pada protokol, tetapi alur login SSO berbasis browser umumnya seperti ini:

1. Pengguna membuka aplikasi, misalnya dashboard penjualan.
2. Aplikasi melihat pengguna belum punya sesi, lalu mengarahkan browser ke halaman login IdP.
3. IdP meminta kredensial, misalnya password dan kode MFA, lalu memeriksanya.
4. Setelah berhasil, IdP mengirim bukti login (SAML assertion atau ID Token) kembali ke aplikasi lewat browser.
5. Aplikasi memvalidasi bukti tersebut: tanda tangan digital, penerbit, tujuan, dan masa berlakunya.
6. Aplikasi membuat sesi sendiri untuk pengguna.
7. Saat pengguna membuka aplikasi kedua, aplikasi itu juga mengarahkan ke IdP. Karena IdP masih punya sesi aktif, pengguna tidak perlu mengetik password lagi dan langsung dikirim kembali dengan bukti login baru.

Langkah ketujuh adalah inti dari SSO: login cukup sekali di IdP, aplikasi lain menumpang sesi tersebut.

## Protokol SSO: SAML dan OpenID Connect

Microsoft Entra ID membagi SSO berbasis federasi ke dua protokol utama: SAML 2.0, yang disebut sebagai standar berbasis XML yang matang dan banyak dipakai di perusahaan, dan OpenID Connect, protokol modern di atas OAuth 2.0 yang memakai token berbasis JSON ([sumber](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)).

### SAML

Security Assertion Markup Language (SAML) adalah standar yang mendefinisikan kerangka untuk bertukar informasi keamanan antar mitra bisnis online ([sumber](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)). SAML banyak dijumpai pada aplikasi enterprise dan SaaS yang dijual ke perusahaan, karena tim IT bisa menghubungkan satu IdP ke banyak aplikasi.

### OpenID Connect (OIDC)

Spesifikasi resminya menyebut OpenID Connect 1.0 sebagai lapisan identitas sederhana di atas protokol OAuth 2.0. OIDC memungkinkan aplikasi memverifikasi identitas pengguna berdasarkan autentikasi yang dilakukan oleh authorization server, sekaligus mendapat informasi profil dasar pengguna ([sumber](https://openid.net/specs/openid-connect-core-1_0.html)). Hasil loginnya berupa ID Token dalam format [JWT](/blog/jwt-adalah) ([sumber](https://openid.net/specs/openid-connect-core-1_0.html)). Tombol "Masuk dengan akun X" di banyak aplikasi umumnya memakai OIDC.

### SSO, OAuth, dan OIDC: Apa Bedanya?

OAuth 2.0 sering disebut bersamaan dengan SSO, padahal tujuannya berbeda. RFC 6749 menjelaskan OAuth 2.0 sebagai kerangka otorisasi yang memungkinkan aplikasi pihak ketiga mendapat akses terbatas ke layanan HTTP ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)). Jadi OAuth mengatur izin akses, bukan pembuktian siapa pengguna. OIDC menambahkan lapisan identitas di atas OAuth, sehingga bisa dipakai untuk login dan SSO ([sumber](https://openid.net/specs/openid-connect-core-1_0.html)).

| Aspek | SAML 2.0 | OpenID Connect | OAuth 2.0 |
|---|---|---|---|
| Fungsi utama | Autentikasi dan SSO | Autentikasi dan SSO | Otorisasi (izin akses) |
| Format | XML ([sumber](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)) | JSON / JWT ([sumber](https://openid.net/specs/openid-connect-core-1_0.html)) | Tergantung jenis token |
| Bukti login | SAML assertion | ID Token | Tidak ada (access token bukan bukti identitas) |
| Umum dipakai di | Aplikasi enterprise dan SaaS B2B | Aplikasi web, mobile, dan API modern | Akses API atas nama pengguna |

Kolom "umum dipakai di" adalah pengamatan tim CDS, bukan aturan dari standar.

### Jenis SSO Lain

Selain federasi, Microsoft Entra ID juga mengenal password-based SSO, yaitu IdP menyimpan kredensial secara aman lalu memasukkannya ke aplikasi, dan linked SSO, yang menurut Microsoft tidak memberikan single sign-on yang sesungguhnya dan dipakai untuk migrasi bertahap ([sumber](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)). Untuk aplikasi baru, pilihan yang lebih tepat adalah SAML atau OIDC.

## Manfaat SSO untuk Bisnis

Microsoft mencatat tiga manfaat utama SSO ([sumber](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)):

- Pengalaman pengguna lebih baik: pengguna menyimpan lebih sedikit kredensial dan lebih jarang login.
- Keamanan lebih kuat: login terpusat membatasi paparan kredensial dan menerapkan kebijakan yang konsisten.
- Beban dukungan lebih ringan: permintaan reset password dan urusan akun ke helpdesk berkurang.

Dari pengalaman tim CDS, ada manfaat operasional lain: saat karyawan keluar, cukup nonaktifkan akunnya di IdP, maka akses ke semua aplikasi yang terhubung ikut tertutup. Tanpa SSO, akun di setiap aplikasi harus dihapus satu per satu dan sering ada yang terlewat. Ini relevan untuk perusahaan yang memakai banyak sistem internal seperti [ERP](/blog/erp-adalah) dan [CRM](/blog/crm-adalah).

## Risiko SSO yang Perlu Diwaspadai

SSO memusatkan login, sehingga risikonya juga terpusat. Poin berikut adalah panduan internal CDS yang dirujuk ke sumber resmi jika tersedia:

- **Satu akun jadi kunci banyak pintu.** Jika akun di IdP dibobol, penyerang bisa masuk ke semua aplikasi yang terhubung. Karena itu, wajibkan MFA di IdP, lebih baik metode yang tahan phishing seperti passkey atau security key. Perlu diingat juga bahwa MFA tidak menutup semua celah, misalnya penyalahgunaan izin OAuth seperti yang kami bahas di [artikel tentang OAuth consent abuse](/blog/mfa-tidak-cegah-oauth-consent-abuse-20260921).
- **Validasi bukti login yang lemah.** OWASP meminta tanda tangan digital SAML divalidasi dengan aman dan memperingatkan serangan signature wrapping ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html)).
- **Respons yang tidak diminta.** OWASP menyebut unsolicited response (login yang dimulai dari IdP) secara desain kurang aman karena tidak ada perlindungan login CSRF ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html)).
- **Sesi yang terlalu panjang.** OWASP menyarankan setiap sesi punya batas waktu tidak aktif dan batas waktu absolut, ditegakkan di sisi server ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)). OWASP juga menyebut autentikasi ulang membantu mengurangi pembajakan sesi, terutama saat memakai IdP eksternal ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)).
- **IdP jadi titik gagal tunggal.** Jika IdP tidak bisa diakses, semua aplikasi ikut tidak bisa dipakai. Siapkan prosedur akses darurat (akun break-glass) yang diawasi ketat.

## Checklist Keamanan Implementasi SSO

Untuk tim developer yang menghubungkan aplikasi ke IdP, berikut poin teknis dari OWASP dan spesifikasi OIDC:

1. Validasi skema XML sebelum memakai dokumen SAML untuk keperluan keamanan apa pun ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html)).
2. Validasi tanda tangan digital, dan pilih elemen dengan ekspresi XPath absolut untuk mencegah signature wrapping ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html)).
3. Pastikan ID permintaan dikembalikan di respons (InResponseTo), dan utamakan masa berlaku respons yang singkat serta sekali pakai ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html)).
4. Untuk OIDC, periksa klaim di ID Token. Klaim iss wajib ada dan berisi identifier penerbit berupa URL https ([sumber](https://openid.net/specs/openid-connect-core-1_0.html)). Cocokkan dengan penerbit yang Anda percaya.
5. Batalkan sesi di sisi server saat pengguna logout; menutup browser tidak bisa diandalkan sebagai logout ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)).
6. Pakai library SAML atau OIDC yang terawat, jangan menulis parser dan validasi token sendiri. Ini panduan internal CDS.

Keamanan SSO juga bergantung pada keamanan [backend](/blog/backend-adalah) dan [API](/blog/api-adalah) aplikasi Anda: sesi, kontrol akses per peran, dan log audit tetap harus dirancang dengan benar.

## Langkah Menerapkan SSO di Aplikasi Bisnis

Urutan berikut adalah panduan internal CDS untuk perusahaan yang ingin menyatukan login beberapa aplikasi:

1. Inventaris aplikasi yang dipakai karyawan, dan catat protokol yang didukung masing-masing (SAML, OIDC, atau belum ada).
2. Pilih IdP. Jika perusahaan sudah memakai layanan email dan direktori karyawan dari satu vendor, IdP bawaan vendor tersebut sering menjadi titik awal paling praktis.
3. Tetapkan kebijakan login di IdP: MFA wajib, batas waktu sesi, dan siapa yang boleh mengakses aplikasi apa.
4. Untuk aplikasi buatan sendiri, tambahkan dukungan OIDC atau SAML memakai library resmi, dan uji di lingkungan staging dulu.
5. Hubungkan aplikasi satu per satu, mulai dari yang paling sering dipakai, sambil menyiapkan jalur login cadangan selama masa transisi.
6. Hubungkan proses HR dengan IdP, sehingga akun dibuat saat karyawan masuk dan dinonaktifkan di hari terakhirnya.
7. Pantau log login di IdP untuk mendeteksi percobaan login yang mencurigakan.

## FAQ Seputar SSO

### SSO adalah singkatan dari apa?

SSO adalah singkatan dari single sign-on, yaitu proses autentikasi yang memakai satu akun untuk mengakses banyak aplikasi ([sumber](https://csrc.nist.gov/glossary/term/single_sign_on)).

### Apa contoh SSO dalam kehidupan sehari-hari?

Karyawan yang login sekali ke akun kantor lalu bisa membuka email, aplikasi HR, dan dashboard internal tanpa login ulang. Contoh lain adalah tombol "Masuk dengan akun X" di aplikasi, yang umumnya memakai OpenID Connect.

### Apakah SSO sama dengan OAuth?

Tidak. OAuth 2.0 adalah kerangka otorisasi untuk memberi aplikasi akses terbatas ke layanan ([sumber](https://www.rfc-editor.org/rfc/rfc6749.html)). SSO berbasis OAuth biasanya memakai OpenID Connect, lapisan identitas di atas OAuth 2.0 ([sumber](https://openid.net/specs/openid-connect-core-1_0.html)).

### Apakah SSO aman?

SSO bisa memperkuat keamanan karena login terpusat dan kebijakannya konsisten ([sumber](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)). Namun akun IdP menjadi target bernilai tinggi, jadi perlu MFA, validasi token yang benar, dan batas waktu sesi.

### Apa bedanya SAML dan OpenID Connect?

SAML 2.0 berbasis XML dan banyak dipakai di perusahaan, sedangkan OpenID Connect dibangun di atas OAuth 2.0 dan memakai token berbasis JSON ([sumber](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)).

### Apakah perusahaan kecil perlu SSO?

Tidak selalu. Menurut pengalaman tim CDS, SSO mulai terasa manfaatnya ketika jumlah aplikasi internal dan karyawan bertambah sehingga pengelolaan akun satu per satu sering terlewat.

## Butuh Bantuan Menerapkan SSO?

Tim CDS membangun aplikasi web, dashboard internal, ERP, dan CRM yang bisa terhubung ke IdP perusahaan lewat SAML atau OpenID Connect, melalui [jasa pembuatan software custom](/services/software). Jika Anda ingin meninjau alur login dan keamanan sistem yang sudah berjalan, mulai dari [konsultasi IT](/services/consulting). Anda juga bisa melihat [karya CDS](/works) untuk proyek yang sudah kami kerjakan.


---

*Markdown version of https://www.ciptadusa.com/blog/sso-adalah — generated for AI agents and LLM crawlers.*