Setiap aplikasi yang saya kembangkan untuk Universitas Pattimura menggunakan sistem Single Sign-On universitas sebagai pintu masuk identitas. Pengguna tidak perlu membuat username dan password baru untuk setiap layanan; mereka masuk melalui akun yang sudah dikenal dan digunakan dalam lingkungan kampus.
Hasil yang terlihat memang hanya sebuah tombol masuk yang lebih sederhana. Namun pekerjaan engineering di belakangnya jauh lebih penting: memastikan identitas dapat dipercaya, callback diproses dengan aman, role lokal dipetakan dengan benar, sesi memiliki batas yang jelas, dan kegagalan tidak membuka celah akses.
SSO dalam satu kalimat
Single Sign-On memungkinkan pengguna melakukan autentikasi melalui satu layanan identitas tepercaya, kemudian mengakses aplikasi yang terhubung tanpa membuat password terpisah di setiap aplikasi.
Ini bukan berarti semua aplikasi memakai satu database atau memberikan izin yang sama. SSO menjawab satu pertanyaan dasar: siapa orang ini? Setiap aplikasi tetap harus menjawab pertanyaan berikutnya: apa yang boleh dilakukan orang ini di dalam sistem?
Pusatkan identitas, bukan seluruh aturan bisnis. Autentikasi menjadi tanggung jawab layanan SSO tepercaya, sedangkan otorisasi tetap dekat dengan data dan alur kerja setiap aplikasi.
Apa yang terjadi ketika pengguna menekan tombol masuk?
Terlepas dari apakah implementasinya memakai OpenID Connect, identitas berbasis OAuth, SAML, atau mekanisme institusi lainnya, alurnya dapat dipahami melalui lima langkah berikut:
- Pengguna membuka aplikasi. Aplikasi melihat bahwa belum ada sesi lokal yang valid.
- Aplikasi mengarahkan pengguna ke SSO kampus.Kredensial dimasukkan hanya pada halaman identitas resmi universitas, bukan di aplikasi yang terhubung.
- SSO memverifikasi pengguna. Kebijakan autentikasi, status akun, dan identitas utama ditangani secara terpusat.
- Aplikasi menerima respons tepercaya. Server memvalidasi respons tersebut sebelum memakai informasi identitas.
- Aplikasi membuat sesi miliknya sendiri.Identitas dicocokkan dengan data lokal, role ditentukan, lalu hanya fitur yang diizinkan yang dibuka.
Setelah alur ini selesai, pengguna merasakan satu akun yang konsisten, sementara setiap aplikasi tetap menjaga batas operasionalnya masing-masing.
Identitas terpusat, tetapi hak akses tetap lokal
Pemisahan ini adalah keputusan desain yang paling penting. Dosen, tenaga kependidikan, atau operator yang berhasil diverifikasi tidak otomatis boleh melakukan semua tindakan pada setiap sistem. Identitas membuktikan bahwa akunnya sah. Otorisasi menghubungkan identitas itu dengan role, unit kerja, tanggung jawab, dan tindakan yang diizinkan.
Sebagai contoh, dua orang dapat sama-sama berhasil masuk melalui SSO kampus. Orang pertama mungkin hanya boleh melihat informasi, sedangkan orang kedua dapat memvalidasi data atau mengelola alur administrasi tertentu. Izin tersebut berada di aplikasi karena aplikasilah yang memahami data dan aturan bisnisnya.
Mengapa saya memakai SSO pada seluruh aplikasi Universitas Pattimura
- Pengalaman yang lebih familier. Pengguna masuk melalui identitas institusi yang sama tanpa mempelajari alur login baru untuk setiap sistem.
- Lebih sedikit duplikasi password. Aplikasi tidak menjadi tempat tambahan untuk membuat, mereset, atau menyimpan password kampus.
- Data identitas lebih konsisten. Sistem dapat memakai pengenal institusi yang sudah diverifikasi, bukan hanya nama atau email yang diketik manual.
- Onboarding dan offboarding lebih jelas.Perubahan akun pusat menjadi titik kontrol pertama, sementara setiap aplikasi tetap mengelola catatan akses lokalnya.
- Dukungan teknis lebih terarah. Operator dapat membedakan masalah identitas dengan masalah izin aplikasi dan memeriksa lapisan yang tepat lebih cepat.
Pekerjaan integrasi yang jarang terlihat pengguna
Memilih pengenal identitas yang stabil
Nama dapat berubah dan email tidak selalu menjadi relational key terbaik. Aplikasi membutuhkan identifier stabil dari penyedia identitas dan harus memastikan satu identitas eksternal hanya terhubung ke satu akun lokal. Aturan ini mencegah akun ganda dan akses tidak sengaja ke data milik orang lain.
Memetakan role secara sengaja
Respons SSO yang berhasil tidak boleh diam-diam memberikan role dengan akses besar. Identitas baru harus mengikuti aturan yang eksplisit: menerima role awal yang aman, dicocokkan dengan data lokal yang sudah disetujui, atau menunggu operator memberikan akses. Kemudahan tidak boleh mengalahkan prinsip least privilege.
Memperlakukan sesi sebagai tanggung jawab aplikasi
SSO mengonfirmasi identitas ketika login, tetapi aplikasi tetap bertanggung jawab atas masa berlaku sesi lokal, regenerasi session ID, perilaku logout, dan perlindungan dari session fixation. Login terpusat tidak menghapus kebutuhan akan pengelolaan sesi yang disiplin.
Merancang kegagalan sebaik merancang keberhasilan
Layanan SSO dapat tidak terjangkau, callback dapat kedaluwarsa, atau pengguna valid di pusat tetapi belum terdaftar secara lokal. Aplikasi harus menolak keadaan yang tidak pasti dengan aman, menampilkan pesan yang membantu, menyimpan log diagnosis tanpa membocorkan rahasia, dan tidak menyediakan login pintas yang tidak terdokumentasi.
Prinsip keamanan yang tidak saya kompromikan
- Validasi respons identitas di server, bukan hanya di browser.
- Terima respons hanya dari issuer, audience, dan callback path yang memang didaftarkan.
- Gunakan kontrol anti-forgery seperti state dan nonce ketika diwajibkan oleh protokol yang digunakan.
- Regenerasi sesi lokal setelah autentikasi dan gunakan cookie yang aman.
- Simpan hanya atribut identitas yang benar-benar dibutuhkan aplikasi.
- Jangan menulis access token, assertion, secret, atau payload sensitif lengkap ke log aplikasi biasa.
- Periksa kembali izin lokal meskipun sesi SSO masih valid.
Apa yang berubah bagi operasional kampus?
Integrasi SSO yang baik membuat aplikasi terpisah terasa seperti satu lingkungan institusi yang saling terhubung. Pengguna tidak menghabiskan perhatian untuk membuat akun baru dan dapat langsung fokus pada pekerjaan yang didukung sistem. Operator memperoleh referensi identitas yang lebih jelas, sedangkan tim engineering memperoleh batas integrasi yang dapat digunakan berulang kali.
Namun kemudahan itu juga membawa tanggung jawab. Kesalahan dalam pemetaan identitas dapat memengaruhi data nyata di lingkungan institusi. Karena itu, saya memperlakukan SSO sebagai bagian dari arsitektur aplikasi—bukan sekadar tombol “Masuk dengan akun kampus” yang ditambahkan pada akhir pengembangan.
Checklist peninjauan praktis
- Apakah kredensial hanya diarahkan ke layanan SSO tepercaya?
- Apakah identitas yang kembali divalidasi penuh di server?
- Apakah satu identitas eksternal dipetakan ke satu pengguna lokal?
- Apakah pengguna baru memperoleh role awal yang aman?
- Bisakah masalah autentikasi dibedakan dari kegagalan otorisasi?
- Bisakah operator mencabut akses lokal tanpa mengubah identitas pusat?
- Apakah timeout, callback gagal, dan layanan tidak tersedia dijelaskan dengan baik?
- Apakah log membantu diagnosis tanpa membocorkan kredensial sensitif?
Hasil yang ingin saya capai
Integrasi SSO terbaik hampir tidak menarik perhatian pengguna. Proses masuk terasa familier, akses yang diterima sesuai, dan berpindah antar layanan kampus tidak lagi menghasilkan akun baru yang harus diingat. Di balik pengalaman sederhana tersebut ada kontrak yang dirancang dengan sengaja antara identitas pusat dan tanggung jawab lokal setiap aplikasi.
Kontrak itulah yang sekarang menjadi fondasi konsisten pada setiap aplikasi Universitas Pattimura yang saya kembangkan: satu identitas kampus tepercaya, berbagai sistem yang fokus pada kebutuhannya, dan hak akses yang tetap eksplisit di tempat pekerjaan nyata berlangsung.