Penambangan Proses Autentikasi: Disiplin CIAM Selanjutnya

1. Pengantar#

Kunci sandi (passkeys) mendorong CIAM maju. Tim terbaik mulai menginstrumentasi perjalanan login dari ujung ke ujung, mengklasifikasikan kesalahan yang belum pernah mereka catat sebelumnya, dan melihat telemetri sisi klien untuk pertama kalinya. Sebagian besar tim identitas belum sampai di sana: belum ada lapisan observabilitas autentikasi yang nyata, tidak ada grafik kejadian per sesi, tidak ada data seremonial sisi klien. Upaya, keberhasilan, dan kegagalan di sisi server masih menjadi gambaran keseluruhan.

Penambangan proses autentikasi (authentication process mining) adalah langkah logis berikutnya, tetapi hanya setelah data kejadian yang mendasarinya ada. Tanpa lapisan observabilitas, tidak ada yang bisa ditambang. Dengan adanya hal itu, disiplin baru menjadi tersedia. Ini meminjam langsung dari penambangan proses bisnis (business process mining), yang mengubah log kejadian ERP mentah menjadi alur kerja yang dioptimalkan pada tahun 2010-an. Saat diterapkan pada identitas, ini membandingkan perjalanan login yang dirancang dengan perjalanan yang sebenarnya dialami, memunculkan jalur penyimpangan, dan kemudian menutup celah tersebut dengan autentikasi step-up yang terperinci, aturan penekanan (suppression rules), atau perubahan UX yang diukur secara ujung ke ujung (end-to-end).

Artikel ini membingkai ulang apa yang seharusnya dibangun oleh tim CIAM di atas lapisan observabilitas autentikasi.

1.1 Pertanyaan yang Dijawab oleh Artikel ini#

Dalam artikel ini, kita membahas pertanyaan-pertanyaan berikut:

1. Apa yang dilakukan penambangan proses untuk BPM, dan apa paralel langsungnya untuk autentikasi?
2. Mengapa peluncuran kunci sandi memunculkan celah ini, dan mengapa log autentikasi tidak pernah cukup dengan sendirinya?
3. Seperti apa sebenarnya model kejadian penambangan proses autentikasi dari ujung ke ujung?
4. Bagaimana penambangan proses terhubung ke autentikasi step-up dan otorisasi yang terperinci?
5. Apa artinya ini bagi lanskap vendor CIAM dan bagi tim identitas yang sudah memiliki IDP?

2. Apa yang Dilakukan Penambangan Proses untuk BPM#

2.1 Dari Log Kejadian hingga Proses yang Dioptimalkan#

Penambangan proses bisnis muncul dari kesadaran bahwa setiap ERP, CRM, atau sistem tiket menulis log kejadian yang, ketika direkonstruksi, mengungkapkan alur kerja yang sebenarnya, bukan yang ada di wiki. Pesanan pembelian yang seharusnya melewati tiga pemberi persetujuan ternyata melewati dua di antaranya 40% dari waktu tersebut. Alur klaim yang didokumentasikan sebagai garis lurus berulang pada dirinya sendiri sebanyak lima kali untuk 18% klaim. Alat penambangan proses seperti yang dipopulerkan oleh Celonis membangun kembali grafik tersebut dari kejadian berstempel waktu dan memungkinkan operator menanyakan pertanyaan baru: di mana proses yang dialami menyimpang dari proses yang dirancang, dan apa biaya dari penyimpangan tersebut?

2.2 Paralel dalam Autentikasi#

Autentikasi memiliki struktur yang sama. Setiap login adalah rangkaian kejadian berstempel waktu: halaman dimuat, pengidentifikasi dimasukkan, tantangan dipilih, biometrik diminta, asersi dikembalikan. Paralel strukturalnya tepat. Perbedaan praktisnya adalah bahwa, tidak seperti ERP atau CRM, data kejadian ini belum berada di log IDP Anda - setidaknya tidak dalam bentuk terperinci yang dibutuhkan penambangan proses. IDP mencatat hasil masuk (sign-in) dan metode yang digunakan. Mereka tidak mencatat seremonial sisi klien di bawahnya: pemanggilan Conditional UI, permintaan biometrik, pemilihan manajer kredensial, pengabaian diam-diam sebelum permintaan mencapai server. Lapisan pra-asersi tersebut harus diinstrumentasi di lapisan SDK front-end dan dirakit kembali menjadi grafik per sesi sebelum penambangan proses dapat beroperasi di atasnya.

Setelah datanya ada, teknik yang sama berlaku: perjalanan kunci sandi yang dirancang vs. perjalanan kunci sandi yang dialami, alur pemulihan yang dirancang vs. alur pemulihan yang dialami, step-up yang dirancang vs. step-up yang dialami. Disiplin akademis seputar pekerjaan ini semakin matang. Titik masuk yang berguna adalah Process Mining Manifesto dari IEEE Task Force on Process Mining, yang menjabarkan pengecekan kesesuaian (conformance checking), analisis varian, dan peningkatan sebagai tiga teknik inti. Masing-masing memetakan secara satu-ke-satu pada autentikasi.

3. Mengapa Peluncuran Kunci Sandi Memunculkan Celah Tersebut#

3.1 Kunci Sandi Memaksa Tim untuk Memikirkan Ulang Pencatatan Frontend#

Autentikasi kata sandi klasik mencatat tiga hal di sisi server: upaya, keberhasilan, kegagalan. Itu cukup untuk menjalankan sistem kata sandi, karena mode kegagalannya sederhana: pengguna salah mengetik string, dan upaya berikutnya berhasil atau tidak. Dengan kunci sandi, momen kritis berpindah ke frontend: Conditional UI terpicu, browser memutuskan apakah akan memunculkan prompt, manajer kredensial menawarkan pilihan, tantangan biometrik berhasil atau ditutup. Semua ini terjadi pada perangkat konsumen, sebelum asersi mencapai backend.

Pergeseran itulah yang menyebabkan banyak tim kini memikirkan ulang cara mereka mencatat perilaku sisi klien. Tanpa instrumentasi frontend, mereka tidak dapat melihat mengapa pengguna churn, langkah apa yang diambil pengguna sebelum login, atau apa yang sebenarnya terjadi ketika upaya login tidak selesai. Log server hanya menunjukkan ketidakhadiran, bukan penyebabnya. Lihat pembahasan mendalam kami tentang observabilitas autentikasi untuk taksonomi kejadian lengkapnya.

3.2 Celah antara Perjalanan yang Dirancang dan Perjalanan yang Dialami#

Setelah tim memiliki kejadian sisi klien, mereka bisa melihat sesuatu yang baru: perjalanan kunci sandi yang dirancang (mendarat di halaman login, melihat tombol kunci sandi, ketuk, autentikasi, selesai) digunakan oleh mungkin 30% pengguna yang memenuhi syarat. 70% sisanya menyimpang melalui bidang kata sandi, login sosial, tautan ajaib (magic links), atau ditinggalkan sepenuhnya. Itu adalah masalah penambangan proses, bukan masalah pencatatan (logging). Sejumlah kode kesalahan WebAuthn tambahan tidak akan menutup celah itu dengan sendirinya.

3.3 Mengapa Log Autentikasi Tidak Pernah Cukup#

Log autentikasi dengan sendirinya memberi tahu Anda hasilnya. Mereka tidak memberi tahu Anda jalurnya. Tingkat keberhasilan login sebesar 92% di semua metode dapat menyembunyikan tingkat pengabaian 40% di jalur kunci sandi dan tingkat pengabaian 15% di jalur kata sandi, yang pada akhirnya terlihat "baik-baik saja". Penambangan proses menolak rata-rata tersebut. Ini bersikeras untuk melihat setiap varian secara terpisah dan kemudian memeringkat varian berdasarkan frekuensi, biaya, dan tingkat kegagalan.

4. Seperti Apa Sebenarnya Penambangan Proses Autentikasi#

4.1 Model Kejadian: Proses, Kejadian, dan Klasifikasi Hasil#

Unit analisisnya bukanlah kejadian tunggal, melainkan sebuah proses: satu upaya login atau penambahan kredensial penuh di perangkat konsumen, dari saat permukaan auth dimuat hingga saat sesi selesai atau ditinggalkan. Setiap proses berisi aliran kejadian terperinci, membawa metadata pengidentifikasi, dan berakhir pada klasifikasi hasil yang lebih kaya daripada sekadar "berhasil atau gagal" biner.

Metadata proses. Setiap proses memiliki ID proses dan stempel waktu (timestamp). Ini terikat pada aplikasi, OS, browser, dan merek perangkat. Ini ditandai dengan kategori pengunjung (pengguna nyata, penguji manual, penguji otomatis, belum diklasifikasikan) sehingga otomatisasi dan lalu lintas bot dapat disegmentasikan sebelum metrik apa pun dihitung. Ini juga membawa skor proses dan jumlah kejadian, yang merupakan dua sinyal paling sederhana untuk "seberapa kompleks sesi khusus ini."

Inisiasi login. Setiap proses mencatat bagaimana alur dimulai. Jenis inisiasi utama adalah text-field (pengguna mengetik pengidentifikasinya), one-tap (pengidentifikasi yang disimpan digunakan kembali), dan cui (Conditional UI memunculkan kredensial tanpa klik tombol eksplisit). Inisiasi adalah sebuah dimensi, bukan metrik: penerapan yang sama dapat terlihat sangat berbeda pada kohort cui dibandingkan pada kohort text-field, dan membuat rata-rata di antara keduanya menyembunyikan perilaku yang justru ingin diungkapkan oleh penambangan proses.

Klasifikasi hasil. Alih-alih "berhasil" atau "gagal," hasilnya adalah salah satu dari beberapa kelas yang memetakan ke perilaku yang berbeda. Contoh untuk kunci sandi adalah sebagai berikut:

• completed - seremonial selesai dan pengguna diautentikasi.
• filtered-explicit-abort - pengguna melihat prompt dan secara eksplisit membatalkan.
• filtered-implicit-abort - pengguna pergi atau habis waktu tanpa memutuskan.
• filtered-passkey-intel - lapisan kecerdasan sisi klien secara sengaja menekan jalur kunci sandi, biasanya karena kombinasi perangkat/OS diketahui bermasalah.
• filtered-no-start - alur tidak pernah melampaui langkah awal.
• not-loaded - permukaan auth tidak pernah selesai memuat.

Seremonial penambahan (pembuatan kredensial) memiliki klasifikasi paralel, termasuk kasus completed-exclude-credentials ketika pengguna sudah memiliki kredensial.

Lapisan funnel dan inventaris. Di atas proses, terdapat dua agregat lapisan yang penting. Lapisan funnel mengelompokkan proses dari waktu ke waktu berdasarkan hasil, inisiasi, status penyelesaian, OS, dan aplikasi, baik untuk login maupun penambahan. Lapisan inventaris kredensial mengelompokkan kunci sandi yang ada berdasarkan status sinkronisasi (disinkronkan vs. tidak disinkronkan), transportasi (internal, hybrid, usb, nfc, ble, smart-card), autentikator (Apple, Google Password Manager, iCloud Keychain, Windows Hello, 1Password, Bitwarden, Dashlane, YubiKey), OS, dan browser. Tanpa lapisan inventaris, mustahil untuk menanyakan apakah varian penyimpangan tertentu terkonsentrasi pada manajer kredensial atau kondisi sinkronisasi tertentu.

Inilah bentuk minimum yang membuat penambangan proses dapat ditangani. Setiap kejadian membawa cukup metadata untuk dikelompokkan, difilter, dan diperingkat. Setiap proses dapat dilacak satu per satu, yang memungkinkan contoh pengerjaan di bawah ini.

4.2 Jalur Bahagia vs. Analisis Penyimpangan#

Setelah kejadian disimpan sebagai grafik terarah per sesi, Anda dapat mengajukan pertanyaan penambangan proses: berapa persentase sesi yang mengikuti jalur bahagia (happy path), dan untuk yang tidak, apa lima varian penyimpangan teratas berdasarkan frekuensi? Dalam data analitik kami, lima varian teratas biasanya menyumbang 85% dari semua penyimpangan. Memperbaiki dua di antaranya biasanya mengubah angka lebih banyak daripada pengujian A/B apa pun pada jalur bahagia.

4.3 Deteksi Pergeseran Kohort#

Varian menyimpang. Pembaruan browser, peluncuran OS, perubahan manajer kredensial dapat membuat varian yang sebelumnya kecil tiba-tiba menjadi dominan. Deteksi pergeseran kohort (cohort drift detection) adalah disiplin mengamati distribusi varian per kohort perangkat/OS/browser dari waktu ke waktu, alih-alih hanya melihat tingkat keberhasilan agregat. Inilah cara tim menangkap regresi diam-diam dalam hitungan jam, bukan kuartal.

5. Dari Penambangan Proses hingga Step-up Terperinci#

5.1 Mengapa Step-up Kurang Dimanfaatkan#

Autentikasi step-up telah ada selama lebih dari satu dekade. Hal ini kurang dimanfaatkan karena sebagian besar tim menerapkan step-up dengan cara yang sama terlepas dari risikonya: memaksa OTP pada setiap transaksi di atas ambang batas. Itu adalah aturan yang kaku, bukan keputusan yang diberi skor risiko (risk-scored). Ini menciptakan hambatan pada 95% transaksi bernilai tinggi yang sah untuk menghentikan 5% yang mencurigakan.

5.2 Perjalanan Berskor Risiko#

Dengan data penambangan proses, Anda dapat menilai suatu sesi secara terus-menerus. Reputasi perangkat, tingkat keberhasilan dasar kohort, anomali waktu, penyimpangan dari jalur historis pengguna itu sendiri, identitas manajer kredensial, reputasi IP. Skor risiko tersebut kemudian mendorong keputusan step-up yang terperinci: memerlukan faktor kedua hanya ketika skor risiko sesi melebihi ambang batas nilai transaksi. Sesi berisiko rendah untuk transaksi bernilai tinggi akan lolos. Sesi berisiko tinggi untuk transaksi bernilai rendah akan diminta step-up.

6. Apa Artinya ini bagi Lanskap Vendor CIAM#

6.1 Desain Perjalanan sebagai Disiplin Spesialis#

Industri identitas secara historis telah menggabungkan desain perjalanan di dalam IDP. Mesin orkestrasi di dalam Okta, Ping, ForgeRock, Auth0, dan lainnya memungkinkan Anda mengonfigurasi alur. Apa yang tidak mereka lakukan dengan baik adalah mengamatinya. Ketidakcocokan itulah yang membuka ruang bagi lapisan analitik spesialis.

6.2 Mengapa Tidak Ada IDP yang Menyediakan ini secara Bawaan#

Vendor IDP mengoptimalkan control plane: siapa yang dapat masuk, dengan kredensial apa, di bawah kebijakan apa. Penambangan proses adalah disiplin data-plane: setiap kejadian, pada skala besar, dinormalisasi di berbagai kombinasi OS/browser/manajer kredensial. Volume kejadian, kardinalitas, dan garis dasar lintas pelanggan semuanya bertentangan dengan pembuatan IDP bawaan. Lihat catatan lapangan dalam panduan beli-vs-bangun untuk kunci sandi kami untuk pola yang sama yang diterapkan pada lapisan SDK.

6.3 Lapisan Analitik sebagai Kategori Baru#

Apa yang muncul adalah lapisan analitik dan adopsi tipis yang berada di atas IDP, menelan kejadian dari front-end, menormalisasinya terhadap garis dasar lintas penerapan, dan memberikan umpan balik ke dalam keputusan orkestrasi. Ini tidak menggantikan IDP. Ini membuat IDP dapat diukur.

7. Bagaimana Corbado Membantu dengan Penambangan Proses Autentikasi#

Corbado menyediakan lapisan pengukuran dan adopsi yang berada di atas IDP yang ada. Ini terintegrasi dengan Okta, Auth0, Ory, ForgeRock, dan tumpukan kustom tanpa menggantikannya. Apa yang ditambahkan secara khusus adalah kemampuan penambangan proses:

• Taksonomi Kejadian End-to-end. SDK sisi klien menangkap seremonial penuh dari muatan halaman hingga asersi, termasuk kejadian pra-pengidentifikasi, pemanggilan Conditional UI, dan pemilihan manajer kredensial.
• Analisis Varian Siap Pakai. Platform ini merekonstruksi grafik perjalanan per kohort dan memeringkat varian penyimpangan berdasarkan frekuensi, peluang pemulihan, dan biaya.
• Peringatan Pergeseran Kohort. Ketika distribusi varian bergeser untuk OS, browser, atau manajer kredensial tertentu, platform menandainya sebelum menjadi masalah hari ke-2.
• Garis Dasar Lintas Penerapan. Karena Corbado mengagregasi data anonim di seluruh lingkungan pelanggan, kesalahan atau regresi baru yang muncul di satu penerapan diklasifikasikan dan didokumentasikan sebelum mencapai penerapan Anda. Lihat mengapa Corbado untuk pendekatan lengkapnya.
• Umpan Balik ke Orkestrasi. Keputusan step-up berskor risiko dan aturan penekanan dapat didorong kembali ke IDP atau ditangani di lapisan adopsi, termasuk sakelar pemutus dinamis (kill-switches) dan dorongan (nudging) khusus kohort.

8. Kesimpulan#

Kunci sandi (passkeys) bukanlah tujuan akhirnya. Mereka adalah pendorong instrumentasi yang memaksa gelombang pertama tim CIAM untuk mencatat kejadian sisi klien sama sekali. Setelah lapisan observabilitas itu ada, disiplin baru duduk di atasnya: penambangan proses autentikasi. Inilah cara tim identitas beralih dari "apakah login berhasil" menjadi "varian perjalanan mana yang diambil pengguna ini, berapa biayanya, dan bagaimana sesi berikutnya harus diarahkan secara berbeda." Tim yang membangun lapisan observabilitas terlebih dahulu, dan lapisan penambangan proses segera setelahnya, akan menetapkan tolok ukur untuk kategori tersebut. Tim yang tetap berada pada tingkat keberhasilan agregat akan terus melewatkan varian sistemik di bawahnya.

Tentang Corbado

Corbado adalah Passkey Intelligence Platform untuk tim CIAM yang menjalankan autentikasi consumer dalam skala besar. Kami membantu Anda melihat apa yang tidak bisa ditunjukkan oleh log IDP dan tool analytics generik: device, versi OS, browser, dan credential manager mana yang mendukung passkey; mengapa enrollment tidak menjadi login; di mana flow WebAuthn gagal; dan kapan update OS atau browser diam-diam merusak login — semuanya tanpa mengganti Okta, Auth0, Ping, Cognito, atau IDP internal Anda. Dua produk: Corbado Observe menambah observability untuk passkey dan metode login lainnya. Corbado Connect menghadirkan managed passkey dengan analytics terintegrasi (berdampingan dengan IDP Anda). VicRoads menjalankan passkey untuk 5M+ pengguna dengan Corbado (aktivasi passkey +80%). Bicara dengan pakar Passkey →

FAQ#

Apa itu Penambangan Proses Autentikasi?#

Penambangan proses autentikasi (authentication process mining) adalah penerapan teknik penambangan proses bisnis pada log kejadian login. Ini merekonstruksi grafik kejadian terarah per sesi, membandingkan perjalanan autentikasi yang dialami dengan perjalanan yang dirancang, dan memeringkat varian penyimpangan berdasarkan frekuensi dan biaya. Ini berada di atas observabilitas autentikasi dan di bawah orkestrasi.

Apa Bedanya dengan Analitik Autentikasi?#

Analitik autentikasi melaporkan metrik seperti tingkat keberhasilan login, tingkat putus (drop-off), dan tingkat penggunaan kunci sandi. Penambangan proses melangkah lebih jauh dengan merekonstruksi urutan kejadian penuh per sesi dan menanyakan varian perjalanan mana yang ada, seberapa sering masing-masing terjadi, dan di mana masing-masing menyimpang dari jalur bahagia yang dirancang. Analitik melaporkan hasil. Penambangan proses menjelaskan jalur.

Mengapa Adopsi Kunci Sandi Membuat Disiplin ini Diperlukan?#

Peluncuran kunci sandi (passkeys) adalah alasan pertama mengapa tim CIAM sama sekali menginstrumentasi kejadian sisi klien. Setelah kejadian tersebut ada, metrik agregat menyembunyikan terlalu banyak: tingkat keberhasilan 92% dapat menutupi tingkat pengabaian 40% di jalur kunci sandi. Penambangan proses menolak rata-rata tersebut dan memaksa tim untuk melihat varian secara terpisah.

Bagaimana Penambangan Proses Terhubung ke Autentikasi Step-up?#

Autentikasi step-up bekerja paling baik ketika dinilai berdasarkan risiko (risk-scored) daripada berbasis aturan. Penambangan proses memberikan bukti tingkat sesi (garis dasar kohort, penyimpangan dari jalur historis pengguna, reputasi perangkat) yang memungkinkan mesin step-up membuat keputusan terperinci alih-alih keputusan ambang batas yang kaku.

Apakah IDP Saya akan Menyediakan ini secara Bawaan?#

Tidak mungkin dalam waktu dekat. IDP mengoptimalkan control plane. Penambangan proses adalah disiplin data-plane dengan volume kejadian tinggi dan kardinalitas tinggi di seluruh kombinasi OS, browser, dan manajer kredensial. Polanya cocok dengan apa yang kita lihat di lapisan SDK saat ini, seperti yang dibahas dalam panduan beli-vs-bangun kami.

Apa Hal Pertama yang Harus Diukur oleh Tim CIAM?#

Mulailah dengan frekuensi varian pada jalur kunci sandi: berapa persentase sesi yang mengikuti jalur bahagia, dan apa lima varian penyimpangan teratas yang diperingkat berdasarkan frekuensi? Satu bagan tersebut biasanya cukup untuk mengungkapkan dua atau tiga perbaikan yang paling mendorong adopsi kunci sandi secara keseluruhan.