Seorang karyawan telah menyelesaikan hari terakhirnya di perusahaan. Tim terkait menjalankan proses offboarding, akun perusahaan dinonaktifkan, dan akses melalui Single Sign-On atau SSO dinyatakan tidak lagi aktif.

Secara administratif, proses tersebut terlihat selesai.

Namun, ketika perangkat yang sebelumnya digunakan dibuka kembali, salah satu aplikasi internal ternyata masih dapat diakses. Tidak ada permintaan login ulang. Dashboard masih muncul dan beberapa fungsi bahkan tetap dapat digunakan.

Situasi seperti ini menimbulkan pertanyaan penting: jika akun SSO sudah dinonaktifkan, mengapa aplikasi masih mempercayai pengguna tersebut?

Jawabannya terletak pada satu perbedaan yang sering luput diperhatikan. Menonaktifkan identitas tidak selalu sama dengan mencabut seluruh akses yang sudah diberikan kepada identitas tersebut.

Pada arsitektur aplikasi modern, autentikasi, session, token, dan authorization dapat memiliki siklus hidup yang berbeda. Jika hubungan antarbagian tersebut tidak dirancang dengan baik, akun yang sudah dianggap tidak aktif pada sistem pusat masih dapat meninggalkan akses yang tetap berlaku di aplikasi.

SSO Mengendalikan Login, tetapi Belum Tentu Mengendalikan Session Setelahnya

SSO memberikan satu titik autentikasi yang dapat digunakan oleh banyak aplikasi. Pengguna tidak perlu membuat kredensial berbeda untuk setiap sistem dan perusahaan dapat memusatkan pengelolaan identitas melalui Identity Provider.

Dari perspektif operasional, pendekatan ini jauh lebih efisien.

Namun, autentikasi terpusat tidak berarti seluruh aktivitas pengguna sesudah login selalu dikendalikan secara langsung oleh Identity Provider.

Ketika pengguna berhasil melalui proses SSO, sebuah aplikasi dapat membuat session miliknya sendiri. Session tersebut kemudian digunakan untuk mengenali pengguna pada request berikutnya tanpa harus meminta proses autentikasi baru setiap kali sebuah halaman dibuka.

Aplikasi juga dapat menerima atau menyimpan beberapa bentuk bukti akses, seperti access token, refresh token, session cookie, atau local session.

Akibatnya, setelah proses autentikasi selesai, terdapat dua kondisi yang dapat berjalan secara bersamaan.

Identity Provider mengetahui status identitas pengguna.

Sementara itu, aplikasi memiliki bukti bahwa pengguna tersebut sebelumnya sudah berhasil diautentikasi.

Masalah muncul ketika status pada kedua sisi tidak diperbarui secara bersamaan.

Menekan Tombol Disable Bukan Berarti Seluruh Session Langsung Berakhir

Menonaktifkan akun merupakan tindakan yang sangat penting. Namun, dari sisi teknis, tindakan tersebut terutama memastikan bahwa identitas tidak lagi dapat melakukan autentikasi baru.

Session yang sudah terbentuk sebelumnya merupakan persoalan berbeda.

Sebagai gambaran, seorang pengguna masuk ke aplikasi perusahaan pada pukul 08.00 melalui SSO. Setelah autentikasi berhasil, aplikasi memberikan session yang berlaku selama delapan jam.

Pada pukul 10.00, administrator menonaktifkan akun pengguna tersebut.

Jika aplikasi tidak melakukan pemeriksaan ulang terhadap status pengguna dan tidak menerima mekanisme revocation, session yang dibuat pada pukul 08.00 dapat tetap dianggap sah sampai masa berlakunya habis.

Dari sisi Identity Provider, akun sudah tidak aktif.

Dari sisi aplikasi, session belum berakhir.

Keduanya bukan kontradiksi. Keduanya terjadi karena masing-masing komponen menggunakan mekanisme dan siklus hidup yang berbeda.

Di sinilah organisasi perlu membedakan account disabling dengan session revocation.

Yang pertama menghentikan identitas agar tidak memperoleh autentikasi baru. Yang kedua memastikan akses yang sudah terlanjur diberikan tidak terus digunakan.

Jika proses offboarding hanya melakukan tindakan pertama, masih mungkin terdapat jendela waktu ketika akses lama tetap berlaku.

Aplikasi Dapat Memiliki Session yang Tidak Lagi Bergantung pada SSO

Ada anggapan bahwa karena sebuah aplikasi menggunakan SSO, setiap aktivitas pengguna selalu diperiksa kembali ke sistem SSO.

Dalam praktiknya, pendekatan seperti itu tidak selalu digunakan.

Validasi identitas pada setiap request dapat menambah ketergantungan terhadap Identity Provider dan memengaruhi arsitektur aplikasi. Karena itu, banyak aplikasi menggunakan session lokal setelah autentikasi berhasil.

Polanya kurang lebih seperti ini:

Pengguna → Identity Provider → Autentikasi berhasil → Aplikasi → Local session

Pada request berikutnya:

Pengguna → Aplikasi → Local session masih valid → Akses diberikan

Identity Provider mungkin tidak lagi terlibat pada setiap permintaan tersebut.

Keuntungan desain ini adalah aplikasi tetap dapat bekerja secara efisien. Namun, konsekuensinya juga perlu dipahami.

Ketika status identitas berubah di pusat, aplikasi membutuhkan mekanisme agar perubahan tersebut ikut diketahui.

Tanpa mekanisme tersebut, aplikasi masih dapat mempercayai informasi autentikasi lama meskipun kondisi penggunanya sudah berubah.

Access Token, Refresh Token, dan Session Cookie Tidak Memiliki Fungsi yang Sama

Kompleksitas bertambah karena aplikasi modern jarang bergantung pada satu jenis session saja.

Dalam arsitektur OAuth dan OpenID Connect, beberapa komponen dapat digunakan bersamaan.

Access Token

Access token digunakan untuk mengakses resource tertentu. Token biasanya memiliki masa berlaku dan dapat diterima oleh resource server selama memenuhi persyaratan validasi.

Jika access token masih berlaku, perubahan status akun tidak selalu langsung membuat token tersebut berhenti diterima, bergantung pada bagaimana arsitektur dan mekanisme revocation diterapkan.

Refresh Token

Refresh token memiliki fungsi berbeda. Token ini dapat digunakan untuk memperoleh access token baru tanpa meminta pengguna melakukan autentikasi penuh kembali.

Karena itu, refresh token menjadi salah satu bagian penting ketika organisasi ingin benar-benar menghentikan akses.

Standar OAuth bahkan memiliki mekanisme khusus untuk token revocation. Hal tersebut memperlihatkan bahwa penerbitan token dan pencabutan token memang merupakan dua proses yang harus ditangani secara jelas.

Session Cookie

Di sisi lain, aplikasi web dapat membuat session cookie sendiri.

Cookie ini dapat menunjuk pada session yang tersimpan di server aplikasi dan memiliki masa berlaku berbeda dari token yang diberikan oleh Identity Provider.

Artinya, sebuah lingkungan SSO dapat memiliki beberapa lapisan kepercayaan sekaligus.

Menonaktifkan salah satunya belum tentu otomatis menghentikan seluruh lapisan lainnya.

Single Sign-On Tidak Otomatis Berarti Single Sign-Out

SSO sangat efektif dalam menyatukan cara pengguna masuk ke berbagai aplikasi.

Namun, menyatukan proses logout memiliki persoalan tersendiri.

Misalnya, seorang pengguna masuk ke tiga aplikasi menggunakan satu Identity Provider.

Setelah autentikasi, ketiga aplikasi membuat session masing-masing.

Ketika session pada Identity Provider dihentikan, aplikasi pertama mungkin menerima pemberitahuan dan menghapus session lokal. Aplikasi kedua mungkin baru mengetahui perubahan tersebut ketika token diperbarui. Sementara aplikasi ketiga mungkin tidak memiliki mekanisme logout terkoordinasi sama sekali.

Hasilnya, status akses tidak seragam.

OpenID Connect menyediakan beberapa mekanisme untuk menangani kebutuhan tersebut, termasuk RP-Initiated Logout, Front-Channel Logout, Back-Channel Logout, dan mekanisme pengelolaan session.

Back-Channel Logout, misalnya, memungkinkan komunikasi logout dilakukan dari OpenID Provider menuju aplikasi tanpa bergantung sepenuhnya pada aktivitas browser pengguna.

Keberadaan mekanisme tersebut menunjukkan satu hal penting:

Single Sign-On tidak secara otomatis menciptakan Single Sign-Out.

Aplikasi tetap perlu dirancang agar dapat merespons perubahan status session dengan benar.

Offboarding Tidak Cukup Hanya Menghapus Kemampuan Login

Persoalan ini menjadi sangat penting ketika dikaitkan dengan proses offboarding.

Bayangkan perusahaan memiliki belasan atau puluhan aplikasi yang sudah terhubung ke satu Identity Provider.

Ketika seseorang keluar dari perusahaan, akun pusat dinonaktifkan. Namun, sebelumnya pengguna tersebut mungkin telah memiliki akses ke beberapa sistem, seperti aplikasi keuangan, portal proyek, sistem HR, dashboard operasional, aplikasi administrasi, API internal, atau sistem dokumen.

Masing-masing aplikasi dapat memiliki session dan mekanisme authorization sendiri.

Karena itu, proses offboarding yang aman tidak seharusnya hanya menjawab:

“Apakah pengguna tersebut masih bisa login?”

Pertanyaannya perlu diperluas menjadi:

“Apakah seluruh akses yang pernah dimiliki pengguna tersebut sudah benar-benar tidak dapat digunakan?”

Keduanya terlihat mirip, tetapi memiliki cakupan yang sangat berbeda.

Pengguna mungkin memang tidak dapat melakukan autentikasi baru, tetapi masih memiliki session aktif pada browser yang belum ditutup.

Ia mungkin masih mempunyai refresh token.

Perangkat yang sebelumnya ditandai sebagai perangkat tepercaya juga dapat mempertahankan status tertentu.

Bahkan pada aplikasi tertentu, terdapat kemungkinan akun lokal yang masih aktif meskipun akun pusat telah dinonaktifkan.

Deprovisioning dan Session Revocation Juga Bukan Hal yang Sama

Perusahaan yang memiliki ekosistem aplikasi cukup besar biasanya memerlukan mekanisme pengelolaan lifecycle identitas.

Salah satu teknologi yang sering digunakan adalah SCIM atau System for Cross-domain Identity Management.

Dengan provisioning dan deprovisioning, perubahan pengguna dari sistem identitas dapat diteruskan ke aplikasi lain. Misalnya, ketika pengguna dinonaktifkan, akun pada aplikasi downstream juga ikut dinonaktifkan.

Mekanisme ini sangat membantu mengurangi akun yang tertinggal.

Namun, deprovisioning user masih perlu dibedakan dari penghentian session aktif.

Sebuah akun lokal dapat berhasil dinonaktifkan, sementara session yang sudah terbentuk tetap tersedia sampai aplikasi melakukan invalidasi.

Dengan demikian, perusahaan sebenarnya menghadapi beberapa pekerjaan sekaligus:

menonaktifkan identitas, menghapus atau menyesuaikan authorization, menghentikan session, dan mencabut token yang masih dapat digunakan.

Keempatnya perlu bergerak dalam arah yang sama.

Semakin Lama Session Bertahan, Semakin Panjang Window of Exposure

Session yang panjang memang memberikan kenyamanan.

Pengguna tidak perlu berkali-kali melakukan autentikasi dan pekerjaan tidak terganggu oleh permintaan login yang terlalu sering.

Namun, setiap keputusan mengenai session lifetime juga memiliki konsekuensi keamanan.

Misalnya, sebuah aplikasi memiliki session yang tetap aktif selama beberapa hari selama pengguna menggunakan perangkat yang sama.

Jika status pengguna berubah beberapa menit setelah session dibuat, aplikasi dapat terus memberikan akses selama tidak ada mekanisme reevaluasi.

Window of exposure kemudian menjadi lebih panjang.

Karena itu, pengelolaan session tidak cukup hanya menentukan angka timeout.

Tim perlu memperhatikan beberapa faktor secara bersamaan, seperti:

• idle timeout;
• absolute session timeout;
• access token lifetime;
• refresh token lifecycle;
• persistent login;
• remembered device;
• mekanisme revocation;
• kebutuhan reauthentication untuk aktivitas sensitif.

Tujuannya bukan membuat seluruh session sesingkat mungkin, melainkan memastikan perubahan penting pada identitas dapat memengaruhi keputusan akses dalam waktu yang sesuai dengan tingkat risikonya.

Perubahan Hak Akses Juga Dapat Menghadapi Masalah yang Sama

Risiko ini tidak hanya muncul ketika seorang pengguna keluar dari perusahaan.

Bayangkan administrator memiliki akses tinggi terhadap sebuah sistem.

Kemudian perusahaan memindahkannya ke posisi lain dan privilege administrator dicabut pada Identity Provider atau sistem IAM.

Pertanyaan berikutnya adalah apakah session aktif mengetahui perubahan tersebut.

Jika informasi role atau permission hanya dibaca ketika login, session lama berpotensi terus membawa hak akses sebelumnya sampai autentikasi berikutnya.

Akibatnya, secara administratif pengguna sudah kehilangan privilege, tetapi secara teknis aplikasi masih menjalankan keputusan authorization berdasarkan informasi lama.

Fenomena ini dapat disebut sebagai stale session atau session yang masih membawa keadaan kepercayaan sebelumnya.

Karena itu, user lifecycle dan access lifecycle seharusnya dipandang sebagai satu proses yang saling terhubung.

Akun yang Dikompromikan Membuat Kecepatan Revocation Menjadi Lebih Penting

Kebutuhan pencabutan akses juga muncul ketika sebuah akun diduga telah disusupi.

Dalam kondisi tersebut, administrator biasanya bergerak cepat:

password di-reset, akun dinonaktifkan, atau login baru diblokir.

Namun, apabila penyerang sudah memperoleh session atau token sebelumnya, menghentikan kemampuan login baru saja mungkin belum cukup.

Organisasi perlu mengetahui:

Apakah session aktif ikut berakhir?

Apakah refresh token masih dapat menghasilkan token baru?

Apakah access token lama tetap diterima?

Apakah aplikasi lain yang sudah memiliki local session masih dapat digunakan?

Apakah API tetap menerima credential lama?

Pertanyaan tersebut menentukan seberapa efektif respons insiden benar-benar memutus akses penyerang.

Keamanan identitas karena itu tidak berhenti pada proses autentikasi. Kemampuan menghentikan kepercayaan dengan cepat sama pentingnya dengan kemampuan memberikan kepercayaan dengan benar.

Offboarding yang Aman Harus Melihat Seluruh Lapisan Akses

Ketika sebuah akun perlu dinonaktifkan, perusahaan sebaiknya tidak hanya melihat satu dashboard Identity Provider.

Beberapa lapisan berikut perlu diperhatikan.

Identity Provider

Pastikan identitas pusat sudah dinonaktifkan sehingga autentikasi baru tidak lagi diperbolehkan.

SSO Session

Periksa apakah session pada Identity Provider masih aktif dan bagaimana mekanisme penghentiannya.

Application Session

Pastikan aplikasi yang terhubung dapat mengakhiri session lokal ketika status pengguna berubah.

Access dan Refresh Token

Evaluasi bagaimana token dicabut dan berapa lama token lama masih dapat digunakan.

Provisioning

Pastikan status akun pada aplikasi downstream ikut diperbarui.

Authorization

Role dan permission yang pernah diberikan perlu dihentikan atau disesuaikan.

API Access

Periksa apakah terdapat token, API credential, atau akses lain yang tidak bergantung langsung pada session browser.

Trusted Device dan Persistent Login

Pastikan mekanisme yang mempertahankan akses pada perangkat tidak membuat akun yang sudah dinonaktifkan tetap dipercaya.

Dengan melihat seluruh lapisan tersebut, offboarding berubah dari sekadar proses administratif menjadi proses penghapusan kepercayaan secara menyeluruh.

Penetration Testing Perlu Menguji Apa yang Terjadi Setelah Akun Dinonaktifkan

Dalam pengujian SSO, pengecekan tidak seharusnya berhenti pada pertanyaan apakah login berhasil atau apakah pengguna tanpa hak dapat melewati autentikasi.

Lifecycle session perlu ikut diuji.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Pengujian dapat dilakukan dengan melihat kondisi sebelum dan setelah status akun berubah.

Misalnya, pengguna melakukan autentikasi dan memperoleh session aktif. Administrator kemudian menonaktifkan akun tersebut.

Setelah itu perlu diperiksa apakah:

• halaman aplikasi masih dapat dibuka;
• API masih menerima request;
• access token masih berfungsi;
• refresh token masih dapat memperoleh token baru;
• local session masih aktif;
• logout Identity Provider memengaruhi aplikasi;
• perubahan role langsung berlaku;
• perangkat dengan persistent session masih dipercaya;
• aplikasi meminta autentikasi ulang pada aktivitas berisiko tinggi.

Pendekatan seperti ini dapat menemukan persoalan yang tidak terlihat hanya dengan menguji halaman login.

Aplikasi mungkin memiliki implementasi SSO yang benar ketika memberikan akses, tetapi masih memiliki kelemahan ketika harus mencabut akses.

Lima Pertanyaan yang Perlu Dijawab oleh Tim IT dan Security

Perusahaan yang sudah menggunakan SSO dapat melakukan evaluasi awal dengan lima pertanyaan sederhana.

1. Apa yang Terjadi pada Session Aktif ketika Akun Dinonaktifkan?

Jika jawabannya adalah “menunggu session expired”, organisasi perlu mengetahui berapa lama periode tersebut dan apakah sesuai dengan tingkat risiko aplikasi.

2. Bagaimana Aplikasi Mengetahui Status Pengguna Berubah?

Apakah melalui validasi token, komunikasi dengan Identity Provider, event tertentu, atau hanya saat pengguna melakukan login berikutnya?

3. Bagaimana Refresh Token Dicabut?

Jika refresh token masih dapat digunakan, access token baru berpotensi terus diterbitkan bergantung pada implementasi dan kebijakan Identity Provider.

4. Apakah Logout Terkoordinasi antara Identity Provider dan Aplikasi?

Logout pada satu komponen tidak boleh diasumsikan otomatis mengakhiri seluruh session lain tanpa adanya mekanisme yang memang mendukung perilaku tersebut.

5. Apakah Offboarding Mencakup Session, Role, Token, dan Akun Lokal?

Jika proses hanya menonaktifkan satu akun pusat, perusahaan perlu memastikan tidak ada bentuk akses lain yang tertinggal.

Kelima pertanyaan ini dapat memperlihatkan apakah implementasi SSO benar-benar mengelola lifecycle akses, bukan hanya menyediakan pengalaman login yang lebih praktis.

SSO Menyatukan Identitas, tetapi Penghentian Akses Tetap Harus Dirancang

Keuntungan SSO sulit dipisahkan dari transformasi aplikasi perusahaan saat ini. Identitas dapat dikelola lebih terpusat, pengalaman pengguna menjadi lebih sederhana, dan tim IT memiliki kontrol yang lebih baik dibandingkan ketika setiap aplikasi mengelola kredensial sendiri.

Namun, keberhasilan implementasi SSO tidak dapat diukur hanya dari seberapa mudah pengguna masuk ke aplikasi.

Sistem juga perlu mampu menjawab satu pertanyaan yang sama pentingnya:

Seberapa cepat perusahaan benar-benar dapat menghentikan akses ketika identitas tersebut tidak lagi dipercaya?

Pada titik inilah desain session management, token revocation, logout, deprovisioning, dan authorization menjadi penting.

Menonaktifkan akun seharusnya bukan akhir proses. Tindakan tersebut harus diikuti oleh mekanisme yang memastikan aplikasi, API, token, session, dan sistem downstream memahami bahwa kepercayaan terhadap pengguna tersebut juga telah berakhir.

Karena dalam keamanan identitas, kemampuan memberikan akses hanyalah separuh pekerjaan.

Separuh lainnya adalah memastikan akses dapat dihentikan ketika seharusnya berhenti.

Pastikan Implementasi SSO Tidak Menyisakan Akses yang Seharusnya Sudah Berakhir

Kelemahan pada session dan lifecycle akses sering sulit terlihat dalam aktivitas sehari-hari. Aplikasi tetap berfungsi, SSO berjalan normal, dan pengguna dapat masuk tanpa kendala.

Masalah biasanya baru terlihat ketika kondisi berubah: akun dinonaktifkan, privilege dicabut, pengguna keluar dari perusahaan, perangkat hilang, atau sebuah identitas terindikasi mengalami kompromi.

Fourtrezz membantu perusahaan melakukan Vulnerability Assessment dan Penetration Testing untuk mengidentifikasi kerentanan pada aplikasi maupun infrastruktur sebelum risiko tersebut dimanfaatkan oleh pihak yang tidak berwenang.

Layanan Penetration Testing Fourtrezz mencakup pengujian web application, API, desktop application, aplikasi Android dan iOS, jaringan, serta server, dengan pendekatan Greybox maupun Blackbox sesuai kebutuhan perusahaan.

Pengujian dapat membantu perusahaan mengevaluasi tidak hanya mekanisme login, tetapi juga session management, authorization, token lifecycle, integrasi SSO, API security, serta perilaku aplikasi ketika status akses pengguna berubah.

Bagi perusahaan yang sudah menggunakan SSO atau sedang mengintegrasikan sistem internal dengan Identity Provider, pengujian keamanan dapat membantu memastikan bahwa akses tidak hanya diberikan dengan benar, tetapi juga dapat dicabut ketika tidak lagi diperlukan.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]