Menyelami Lebih Dalam tentang Authentication dalam Microservices

Apa Itu Layanan Autentikasi

Autentikasi adalah proses verifikasi identitas pengguna untuk memberikan akses dan izin yang diperlukan untuk menggunakan sistem. Layanan yang menyediakan fungsi ini disebut layanan autentikasi. Dalam aplikasi perangkat lunak monolitik tradisional, semua ini terjadi dalam aplikasi yang sama, tetapi dalam arsitektur microservices, sistem terdiri dari beberapa layanan. Setiap microservice memiliki tugasnya sendiri dalam arsitektur seperti ini, sehingga mengimplementasikan proses otorisasi dan autentikasi secara terpisah untuk setiap microservice tidak sepenuhnya efektif.

Artikel ini akan membandingkan autentikasi tradisional dan autentikasi microservice. Dan menunjukkan perubahan dalam autentikasi yang dibawa oleh perubahan dalam arsitektur. Terakhir, kami akan menganalisis berbagai layanan autentikasi dalam arsitektur microservice serta kelebihan dan kekurangan dalam implementasinya.

Layanan Autentikasi dalam Arsitektur Tradisional

Pada awal pengembangan layanan oleh perusahaan, semua fungsi diimplementasikan dalam aplikasi yang sama. Kami menyebut model ini sebagai "monolitik" untuk membedakannya dari arsitektur "microservice" yang lebih mainstream saat ini.

Aplikasi monolitik terdiri dari satu unit yang tidak dapat dibagi. Biasanya dikembangkan secara independen oleh unit bisnis terpisah dan digabungkan ke dalam lingkungan yang sama saat di-deploy. Semua ini terintegrasi dengan erat untuk menyediakan semua fungsi dalam satu unit. Unit ini memiliki semua sumber daya yang dibutuhkan. Keuntungan dari aplikasi monolitik adalah mudah untuk di-deploy dan di-iterasi. Ini cocok untuk perusahaan yang lebih independen dengan sedikit lini bisnis.

Seiring dengan semakin kompleksnya bisnis yang dikembangkan oleh perusahaan, kita akan menemukan bahwa layanan tunggal tidak lagi dapat memenuhi kebutuhan iterasi cepat dalam kehidupan nyata. Kita perlu memisahkan sistem raksasa ini dan memastikan bahwa panggilan antara fungsi yang ada dapat dilakukan dengan normal. Untuk mengatasi masalah ini, ESB (Enterprise Service Bus) muncul.

"Enterprise service bus" adalah saluran yang menghubungkan berbagai layanan perusahaan. Keberadaan ESB adalah untuk mengintegrasikan layanan yang berbeda dengan protokol yang berbeda. ESB menyediakan layanan seperti penerjemahan dan perutean permintaan klien, sehingga layanan yang berbeda dapat saling terhubung dengan mudah. Seperti yang dapat Anda tebak dari namanya, konsep ini mengadopsi model komunikasi dalam prinsip komposisi komputer - bus, semua sistem yang perlu berkomunikasi dengan sistem eksternal terhubung ke ESB. Anda dapat menggunakan sistem yang ada untuk membangun sistem terdistribusi heterogen yang longgar.

ESB telah menerjemahkan dan merutekan permintaan sehingga layanan yang berbeda dapat berkomunikasi satu sama lain. Metode pemanggilan layanan ESB tradisional adalah setiap kali pemanggil harus dirutekan terlebih dahulu melalui ESB pusat ke layanan.

Arsitektur Monolitik

Autentikasi pengguna dan manajemen sesi relatif sederhana: autentikasi dan otorisasi terjadi dalam aplikasi yang sama, biasanya menggunakan skema autentikasi berbasis sesi. Setelah diautentikasi, sesi dibuat dan disimpan di server. Setiap komponen dapat mengakses dan menggunakannya untuk memberi tahu dan mengotorisasi permintaan selanjutnya. ID sesi dikirim ke klien dan digunakan untuk mengaitkan semua permintaan berikutnya dengan sesi saat ini.

Arsitektur ESB

Di bawah arsitektur ESB, semua proses antara layanan diproses melalui bus ESB. Karena arsitektur ESB berasal dari arsitektur monolitik, metode autentikasi tidak berubah dibandingkan dengan arsitektur monolitik.

Layanan Autentikasi dalam Arsitektur Microservice

Migrasi dari arsitektur monolitik ke arsitektur microservice memiliki banyak keuntungan. Namun, sebagai arsitektur terdistribusi, arsitektur microservice memiliki area serangan yang lebih besar, sehingga lebih menantang untuk berbagi konteks pengguna. Oleh karena itu, layanan autentikasi yang berbeda diperlukan di bawah arsitektur microservice untuk merespons tantangan keamanan yang lebih besar.

Kita dapat membagi layanan autentikasi di bawah arsitektur microservice menjadi tiga kategori berikut:

1. Mengimplementasikan autentikasi pada setiap microservice
2. Mengimplementasikan autentikasi melalui layanan autentikasi
3. Mengimplementasikan autentikasi melalui API gateway

Setiap pendekatan memiliki kelebihan dan kekurangan tertentu.

Mengimplementasikan Autentikasi pada Setiap Microservice

Karena setiap microservice dipisahkan dari arsitektur monolitik, transisi alami untuk mengimplementasikan autentikasi adalah setiap microservice mengimplementasikannya sendiri.

Setiap microservice harus mengimplementasikan jaminan keamanan independennya sendiri, yang diberlakukan di setiap titik masuk. Pendekatan ini memberdayakan tim microservices untuk membuat keputusan otonom tentang implementasi solusi keamanan mereka. Namun, pendekatan ini memiliki beberapa kekurangan:

• Logika keamanan perlu diimplementasikan berulang kali di setiap microservice. Ini menyebabkan duplikasi kode antara layanan.
• Ini mengalihkan perhatian tim pengembangan dari fokus pada layanan utama mereka.
• Setiap microservice bergantung pada data autentikasi pengguna yang tidak dimilikinya.
• Sulit untuk dipelihara dan dipantau.

Salah satu opsi untuk meningkatkan solusi ini adalah menggunakan pustaka autentikasi bersama yang dimuat pada setiap microservice. Ini akan mencegah duplikasi kode, dan tim pengembangan hanya akan fokus pada domain bisnis mereka. Namun, masih ada kekurangan yang tidak dapat diselesaikan oleh perbaikan ini. Karena pustaka autentikasi bersama masih perlu memiliki data identitas pengguna yang sesuai, juga perlu memastikan bahwa setiap microservice menggunakan versi pustaka autentikasi yang sama. Pustaka autentikasi bersama lebih seperti hasil dari pemisahan layanan yang buruk.

Kelebihan: implementasi cepat, independensi yang kuat

Kekurangan: duplikasi kode antara layanan; pelanggaran prinsip tanggung jawab tunggal; kesulitan dalam pemeliharaan

Mengimplementasikan Autentikasi Melalui Layanan Autentikasi

Karena sulit bagi setiap microservice untuk mengimplementasikan autentikasi sendiri, dan menggunakan pustaka autentikasi bersama melanggar niat awal pemisahan microservice, bisakah pustaka autentikasi bersama ditingkatkan menjadi layanan autentikasi khusus?

Dalam kasus ini, semua akses dikontrol oleh layanan yang sama, mirip dengan fungsi autentikasi dalam aplikasi monolitik. Setiap layanan bisnis harus mengirim permintaan otorisasi terpisah ke modul kontrol akses saat melakukan operasi.

Namun, pendekatan ini memperlambat layanan dan meningkatkan interkoneksi antara layanan. Dan setiap microservice akan bergantung pada layanan autentikasi "tunggal" ini. Ini rentan terhadap kegagalan titik tunggal dan reaksi berantai yang menyebabkan kerusakan tambahan.

Kelebihan: Setiap microservice memiliki tanggung jawab tunggal, dan autentikasi terpusat

Kekurangan: Kegagalan titik tunggal; peningkatan latensi permintaan

Mengimplementasikan Autentikasi Melalui API Gateway

Saat bermigrasi ke arsitektur microservices, satu pertanyaan yang perlu dijawab adalah bagaimana microservices berkomunikasi satu sama lain. ESB yang disebutkan di atas adalah salah satu pendekatan, tetapi lebih umum, API gateway digunakan. API gateway adalah titik masuk tunggal untuk semua permintaan. Ini memberikan fleksibilitas dengan bertindak sebagai antarmuka pusat untuk mengonsumsi microservices ini. Sebuah microservice yang perlu mengakses microservice lain (mulai sekarang, kami akan menyebutnya sebagai "klien" untuk membedakannya dari microservice yang diaksesnya) tidak memiliki akses langsung ke layanan, tetapi mengirim permintaan ke API gateway yang bertanggung jawab untuk merutekan klien ke layanan upstream.

Karena semua permintaan harus melalui API gateway terlebih dahulu, ini adalah kandidat yang bagus untuk menegakkan masalah autentikasi. Ini mengurangi latensi (panggilan ke layanan autentikasi) dan memastikan bahwa proses autentikasi konsisten di seluruh aplikasi.

Misalnya, menggunakan plugin jwt-auth dari APISIX, kita dapat mengimplementasikan autentikasi di gateway.

1. Kita harus mengkonfigurasi beberapa informasi identitas pengguna (nama, kunci, dll.) di APISIX.
2. Menurut kunci pengguna yang diberikan, memulai permintaan tanda tangan ke APISIX untuk mendapatkan token JWT pengguna.
3. Kemudian, ketika klien perlu mengakses layanan upstream, ia membawa token JWT, dan APISIX bertindak sebagai API gateway untuk memproksi akses ini.
4. Terakhir, APISIX akan menyelesaikan operasi autentikasi menggunakan token JWT.

Tentu saja, segala sesuatu memiliki kelebihan dan kekurangan, dan tidak ada teknologi yang sempurna tanpa kekurangan. Menggunakan API gateway untuk menyelesaikan autentikasi masih memiliki beberapa masalah. Menyelesaikan masalah ini di gateway kurang aman dibandingkan menyelesaikan autentikasi dalam setiap microservice. Misalnya, jika API gateway dikompromikan, itu akan mengekspos semua microservices di belakangnya. Tetapi risikonya relatif. Dibandingkan dengan layanan autentikasi tunggal, masalah menggunakan API gateway lebih ringan.

Kelebihan: Perlindungan efektif untuk microservices backend; microservices tidak perlu menangani logika autentikasi apa pun

Kekurangan: Kegagalan titik tunggal

Ringkasan

Dalam berbagai skenario, kita akan membutuhkan skema autentikasi yang berbeda. Dalam aplikasi monolitik, autentikasi terjadi dalam aplikasi yang sama, dan server menyimpan semua sesi. Di era microservices, aplikasi monolitik telah berevolusi menjadi layanan terdistribusi, dan metode autentikasi tradisional tidak berlaku. Dalam arsitektur microservice, kita memiliki tiga metode autentikasi untuk dipilih:

1. Mengimplementasikan autentikasi pada setiap microservice
2. Mengimplementasikan autentikasi melalui layanan autentikasi
3. Mengimplementasikan autentikasi melalui API gateway

Setiap opsi memiliki kelebihan dan kekurangan sendiri, yang perlu dianalisis secara detail sesuai dengan situasinya.