Sebuah sistem manajemen identitas dan akses (IAM) mandiri bernama identityCore berhasil dibangun dari nol menggunakan Spring Boot 3.3.5 dan Spring Security 6.3.4. Sistem ini dirancang sebagai alternatif lokal untuk layanan pihak ketiga seperti Auth0, Keycloak, atau Cognito. Pengembangnya memilih pendekatan ini untuk memahami secara mendalam bagaimana setiap komponen keamanan saling terhubung dalam arsitektur modern.
Uji coba lokal berjalan tanpa kendala. Namun, saat aplikasi diarahkan ke domain milik sendiri melalui terowongan jaringan (tunnel) dengan terminasi TLS di sisi edge, sistem otentikasi mendadak mati. Kesalahan yang muncul adalah redirect_uri_mismatch pada proses login OAuth2. Akar masalahnya terletak pada cara Spring Security membangun URI pengalihan yang mengira skema permintaan masih menggunakan HTTP internal, berbeda dengan HTTPS yang terdaftar di penyedia layanan.
IdentityCore menggunakan kombinasi teknologi matang untuk menopang operasionalnya. Lapisan produksi mengandalkan PostgreSQL, sementara lingkungan pengembangan memakai H2. Untuk antarmuka, sistem ini menggabungkan Thymeleaf, HikariCP, serta algoritma hashing BCrypt guna menjaga keamanan kata sandi pengguna. Arsitektur ini sengaja dibuat menyatu antara layanan REST dan MVC dalam satu aplikasi yang sama.
Salah satu fitur unggulan adalah tersedianya tiga jalur login yang berbeda, yakni formulir standar, Google melalui OIDC, dan GitHub via OAuth2. Semua jalur tersebut menyatu pada satu model entitas pengguna (UserEntity). Sistem kendali akses berbasis peran (RBAC) diimplementasikan sebagai data sungguhan melalui RoleEntity dan PermissionEntity yang dapat diedit lewat antarmuka admin, bukan sekadar konstanta statis yang tersebar di kode.
Aspek teknis yang sering diabaikan oleh kebanyakan tutorial adalah perbedaan mendasar antara OAuth2 murni dan OIDC. Google mengembalikan id_token berupa JSON Web Token (JWT) bertanda tangan yang sudah berisi klaim identitas seperti email dan nama. Sebaliknya, GitHub hanya memberikan access_token buram sehingga aplikasi harus melakukan panggilan tambahan ke endpoint /user/emails untuk mengambil alamat email terverifikasi, terutama jika pengguna menyembunyikan data tersebut.
Di Indonesia, banyak startup dan pengembang perangkat lunak masih mengandalkan layanan otentikasi pihak ketiga demi efisiensi waktu. Membangun sistem IAM sendiri seperti identityCore jarang dilakukan, meski menawarkan kendali penuh atas kedaulatan data pelanggan. Insiden bug deploy ini menjadi pengingat bahwa infrastruktur keamanan lokal membutuhkan pemahaman protokol jaringan yang setara dengan pemahaman logika pemrograman.
Jebakan konfigurasi proxy tersebut sangat relevan bagi komunitas teknologi Tanah Air. Penggunaan alat terowongan seperti Ngrok atau Cloudflare Tunnel kerap menjadi solusi cepat untuk demonstrasi produk atau deployment awal. Tanpa pengaturan header X-Forwarded-Proto yang tepat, aplikasi Spring Boot di balik proxy akan terus mengalami kegagalan otentikasi yang membingungkan bagi tim operasional.
Perbandingan dengan praktik di Indonesia menunjukkan bahwa banyak insiden serupa terjadi saat aplikasi Java diletakkan di balik load balancer AWS ALB atau Nginx. Penambahan satu baris konfigurasi server.forward-headers-strategy=framework terbukti menjadi kunci penyelesaian. Konfigurasi ini memerintahkan Spring untuk memercayai header yang dikirim terowongan dan membangun URL dengan skema yang benar tanpa perlu mengubah setup proxy secara manual.
Sang pengembang menegaskan bahwa OAuth2 dan OIDC adalah dua protokol dengan tujuan berbeda yang sering disamaratakan. OAuth2 berfokus pada otorisasi akses, sedangkan OIDC menambahkan lapisan identitas khusus untuk autentikasi. Memperlakukan keduanya secara identik mungkin berhasil di tahap awal, tetapi akan menyebabkan celah keamanan atau kegagalan sistem saat menghadapi kasus nyata.
Pelajaran berharga lainnya adalah perbedaan antara demo yang berjalan dan deployment yang stabil. Konfigurasi SecurityConfig yang sama persis dapat berperilaku berbeda tergantung pada apa yang berada di antara klien dan aplikasi. Selain itu, sentralisasi logika pembuatan pengguna ke dalam satu fungsi provisioning menjadi praktik terbaik agar tidak ada duplikasi pengecekan eksistensi akun yang bisa menyimpang.
Ke depan, tren pembangunan IAM mandiri diprediksi meningkat seiring dengan regulasi perlindungan data pribadi di Indonesia. Kewajiban lokalisasi data membuat perusahaan mulai menghindari ketergantungan penuh pada server otentikasi luar negeri. Memahami bug tingkat rendah seperti ketidakcocokan URI pengalihan akan mencegah waktu henti (downtime) yang merugikan bisnis digital.
Proyek identityCore yang tersedia di repositori GitHub tersebut kini menjadi tolok ukur pembelajaran bagi pengembang yang ingin mendalami arsitektur keamanan. Pendekatan menyatukan jalur provisi pengguna dan penanganan eksepsi global (GlobalExceptionHandler) layak diadopsi secara luas. Hal ini memastikan respons API yang konsisten serta melindungi sistem dari kebocoran jejak tumpukan (stack trace) yang berbahaya.