Istio RequestAuthentication (JWT): Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234
Istio RequestAuthentication (JWT): Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya
Pada artikel sebelumnya kita membahas Istio Authorization Policy, yaitu mekanisme yang digunakan untuk menentukan apakah suatu request diizinkan atau ditolak berdasarkan aturan keamanan yang telah ditentukan. Namun, sebelum sebuah request dapat dievaluasi oleh Authorization Policy, Istio perlu mengetahui terlebih dahulu identitas pengguna atau aplikasi Dewa234 yang mengirimkan request tersebut.
Di sinilah RequestAuthentication berperan. Resource ini memungkinkan Istio memverifikasi JSON Web Token (JWT) yang dikirimkan oleh client. Setelah token berhasil diverifikasi, informasi identitas (claims) dapat digunakan oleh Authorization Policy untuk mengambil keputusan akses.
Pada artikel ini kita akan mempelajari RequestAuthentication secara menyeluruh, mulai dari konsep JWT, proses validasi token, arsitektur, komponen, cara kerja, implementasi pada Istio, hingga contoh konfigurasi YAML dan praktik terbaik di lingkungan production.
Apa Itu RequestAuthentication?
RequestAuthentication adalah resource keamanan pada Istio yang digunakan untuk memverifikasi identitas pengguna atau aplikasi berdasarkan JSON Web Token (JWT). Resource ini tidak menentukan apakah request boleh mengakses suatu layanan, tetapi memastikan bahwa token yang dikirimkan valid dan berasal dari issuer yang dipercaya.
Setelah proses verifikasi berhasil, informasi di dalam JWT seperti subject, issuer, audience, maupun custom claim akan tersedia untuk digunakan oleh Authorization Policy.
Apa Itu JSON Web Token (JWT)?
JSON Web Token atau JWT adalah standar terbuka (RFC 7519) untuk membawa informasi identitas dalam bentuk token yang ditandatangani secara digital. JWT banyak digunakan pada API modern karena ringan, mudah dibawa melalui HTTP Header, dan dapat diverifikasi tanpa harus menyimpan sesi di server.
Header │ Payload │ Signature
JWT biasanya dikirim melalui header HTTP berikut:
Authorization: Bearer eyJhbGciOi...
Mengapa RequestAuthentication Dibutuhkan?
Tanpa proses autentikasi, setiap request yang masuk dianggap anonim sehingga Authorization Policy tidak memiliki informasi identitas yang dapat digunakan untuk menentukan hak akses. RequestAuthentication menyelesaikan masalah tersebut dengan memverifikasi token sebelum request diproses lebih lanjut.
Client │ JWT │ ▼ RequestAuthentication │ Valid? │ ▼ Authorization Policy │ Application
Posisi RequestAuthentication pada Istio
Internet │ Gateway │ HTTPRoute │ RequestAuthentication │ Authorization Policy │ Application
Pada alur di atas, RequestAuthentication bekerja sebelum Authorization Policy. Setelah token berhasil diverifikasi, informasi identitas dapat digunakan untuk menentukan apakah request diizinkan atau ditolak.
Hubungan RequestAuthentication dengan Authorization Policy
Kedua resource ini saling melengkapi. RequestAuthentication bertanggung jawab melakukan autentikasi, sedangkan Authorization Policy melakukan otorisasi.
| Resource | Peran |
|---|---|
| RequestAuthentication | Memverifikasi JWT. |
| Authorization Policy | Menentukan hak akses berdasarkan identitas. |
Dengan memisahkan autentikasi dan otorisasi, Istio memungkinkan administrator menerapkan kebijakan keamanan yang lebih fleksibel dan mudah dipelihara.
Bagaimana Cara Kerja RequestAuthentication?
Ketika client mengirimkan request beserta JWT, Envoy atau Waypoint Proxy akan memeriksa apakah terdapat RequestAuthentication yang berlaku. Token kemudian diverifikasi menggunakan informasi issuer dan public key yang telah dikonfigurasi.
Client │ JWT │ ▼ RequestAuthentication │ Verify Signature │ Check Issuer │ Check Expiration │ Valid │ ▼ Authorization Policy
Apabila token valid, request diteruskan beserta informasi identitas yang terdapat pada JWT. Sebaliknya, jika token tidak valid, request akan ditolak sebelum mencapai aplikasi.
Komponen RequestAuthentication
| Komponen | Fungsi |
|---|---|
| selector | Menentukan workload yang menggunakan autentikasi. |
| jwtRules | Berisi aturan verifikasi JWT. |
| issuer | Menentukan penerbit token yang dipercaya. |
| jwksUri | Lokasi public key untuk memverifikasi signature. |
Fungsi RequestAuthentication
- Memverifikasi JSON Web Token.
- Mengidentifikasi pengguna atau aplikasi.
- Menyediakan claim untuk Authorization Policy.
- Mengurangi risiko token palsu.
- Mendukung Zero Trust Security.
- Mengintegrasikan autentikasi dengan service mesh.
- Meningkatkan keamanan API modern.
Hubungan dengan Ambient Mesh
Pada Ambient Mesh, RequestAuthentication dijalankan melalui Waypoint Proxy ketika diperlukan pemrosesan Layer 7. Hal ini memungkinkan validasi JWT dilakukan tanpa harus memasang sidecar Envoy pada setiap Pod.
Client │ JWT │ Gateway │ Waypoint Proxy │ RequestAuthentication │ Authorization Policy │ Application
Struktur JSON Web Token (JWT)
Sebelum memahami bagaimana RequestAuthentication bekerja, penting untuk mengetahui struktur dasar dari JSON Web Token (JWT). Sebuah JWT terdiri dari tiga bagian utama yang dipisahkan oleh tanda titik (.), yaitu Header, Payload, dan Signature.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwiZXhwIjoxNzYwMDAwMDAwfQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Ketiga bagian tersebut memiliki fungsi yang berbeda namun saling melengkapi dalam proses autentikasi.
Header JWT
Header berisi informasi mengenai algoritma kriptografi yang digunakan untuk menandatangani token serta tipe token yang digunakan.
{
"alg": "RS256",
"typ": "JWT"
}
Istio akan membaca informasi ini sebelum melakukan proses verifikasi signature menggunakan public key yang tersedia pada JWKS.
Payload JWT
Payload berisi informasi identitas atau claims mengenai pengguna maupun aplikasi yang melakukan request.
{
"sub":"user123",
"iss":"https://auth.example.com",
"aud":"payment-api",
"role":"admin"
}
Informasi tersebut nantinya dapat digunakan oleh Authorization Policy untuk menentukan apakah request memiliki hak akses terhadap suatu workload.
Signature JWT
Signature merupakan bagian yang memastikan bahwa token tidak diubah setelah diterbitkan oleh Identity Provider.
Header
│
Payload
│
Private Key
│
▼
Signature
Apabila payload diubah sedikit saja, maka signature tidak lagi valid sehingga RequestAuthentication akan menolak token tersebut.
Claim yang Umum Digunakan
JWT memiliki beberapa claim standar yang sering digunakan pada implementasi Istio.
| Claim | Keterangan |
|---|---|
| iss | Issuer atau penerbit token. |
| sub | Identitas pengguna. |
| aud | Penerima token. |
| exp | Waktu kedaluwarsa token. |
| iat | Waktu token diterbitkan. |
| nbf | Token mulai berlaku. |
Selain claim standar, organisasi juga dapat menambahkan custom claim seperti role, department, region, maupun informasi lain yang diperlukan.
Bagaimana Istio Memverifikasi JWT?
Saat request masuk, Waypoint Proxy atau Envoy akan melakukan beberapa tahapan verifikasi terhadap JWT sebelum request diteruskan ke aplikasi.
Client │ Bearer Token │ ▼ Extract JWT │ Check Issuer │ Check Signature │ Check Expiration │ Valid ? │ ┌─────┴─────┐ ▼ ▼ Yes No │ │ ▼ ▼ Continue Reject
Apabila salah satu proses verifikasi gagal, maka request akan dihentikan dan tidak diteruskan menuju workload.
Issuer (iss)
Issuer adalah pihak yang menerbitkan JWT. Pada konfigurasi RequestAuthentication, administrator menentukan issuer mana yang dipercaya sehingga token dari penerbit lain akan ditolak.
JWT │ Issuer │ https://auth.example.com │ ▼ Trusted
JWKS (JSON Web Key Set)
Agar dapat memverifikasi signature JWT, Istio membutuhkan public key yang disediakan melalui JWKS (JSON Web Key Set).
Identity Provider
│
▼
JWKS Endpoint
│
Public Keys
│
▼
Istio
JWKS memungkinkan proses rotasi kunci dilakukan tanpa harus mengubah konfigurasi seluruh workload.
Field jwksUri
Field jwksUri digunakan untuk menentukan lokasi JWKS yang akan digunakan Istio ketika memverifikasi signature JWT.
https://auth.example.com/.well-known/jwks.json
Istio akan mengambil public key dari alamat tersebut secara otomatis sesuai kebutuhan.
Contoh Konfigurasi RequestAuthentication
apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
name: jwt-auth
spec:
selector:
matchLabels:
app: product
jwtRules:
- issuer: https://auth.example.com
jwksUri: https://auth.example.com/.well-known/jwks.json
Konfigurasi tersebut menginstruksikan Istio agar hanya menerima JWT yang diterbitkan oleh issuer yang telah ditentukan.
Menggunakan JWT Bersama Authorization Policy
Setelah RequestAuthentication berhasil memverifikasi token, informasi claim dapat dimanfaatkan oleh Authorization Policy untuk membatasi akses berdasarkan role, subject, maupun atribut lainnya.
Client │ JWT │ ▼ RequestAuthentication │ Claims │ ▼ Authorization Policy │ ALLOW │ Application
Sebagai contoh, hanya pengguna dengan role admin yang diperbolehkan mengakses endpoint administrasi, sedangkan pengguna biasa hanya dapat mengakses endpoint publik.
Implementasi pada Kubernetes Service Mesh
Dalam lingkungan Kubernetes modern, RequestAuthentication biasanya ditempatkan pada layanan yang menerima request dari pengguna, seperti API Gateway atau service frontend. Dengan demikian, identitas pengguna dapat diverifikasi sejak awal sebelum request diteruskan ke layanan internal lainnya.
Internet │ Gateway │ HTTPRoute │ RequestAuthentication │ Authorization Policy │ Frontend │ Backend Services
Pendekatan ini membantu membangun sistem keamanan berlapis yang sejalan dengan prinsip Zero Trust dan meminimalkan risiko akses tidak sah ke dalam service mesh.
Best Practice Menggunakan RequestAuthentication
Implementasi RequestAuthentication yang baik tidak hanya memastikan JWT berhasil diverifikasi, tetapi juga menjaga agar proses autentikasi tetap aman, mudah dipelihara, dan mampu berkembang mengikuti kebutuhan aplikasi. Pada lingkungan production, administrator sebaiknya menerapkan kebijakan autentikasi secara konsisten di seluruh service yang menerima request dari pengguna.
- Gunakan Identity Provider (IdP) yang terpercaya seperti Keycloak, Auth0, Okta, Azure AD, atau Google Identity.
- Selalu gunakan algoritma asimetris seperti RS256 atau ES256 dibandingkan algoritma simetris untuk lingkungan production.
- Gunakan HTTPS agar JWT tidak dapat disadap selama proses transmisi.
- Batasi masa berlaku token (exp) agar risiko penyalahgunaan token dapat diminimalkan.
- Lakukan rotasi public key secara berkala melalui JWKS.
- Kombinasikan RequestAuthentication dengan Authorization Policy agar autentikasi dan otorisasi berjalan bersama.
- Gunakan PeerAuthentication untuk mengamankan komunikasi antar workload menggunakan mTLS.
- Jangan menyimpan informasi sensitif di dalam payload JWT.
- Lakukan audit terhadap issuer yang dipercaya secara berkala.
- Uji seluruh perubahan konfigurasi pada lingkungan staging sebelum diterapkan ke production.
Monitoring RequestAuthentication
Monitoring membantu administrator memastikan bahwa proses autentikasi berjalan dengan baik. Beberapa metrik yang umum dipantau meliputi jumlah token yang valid, token yang ditolak, serta tingkat keberhasilan autentikasi.
Incoming Request
│
▼
JWT Validation
│
├── Success
├── Failed Signature
├── Invalid Issuer
├── Expired Token
└── Missing Token
Melalui dashboard observability seperti Prometheus, Grafana, maupun Kiali, administrator dapat mengetahui apabila terjadi lonjakan autentikasi yang gagal sehingga tindakan mitigasi dapat dilakukan lebih cepat.
Troubleshooting RequestAuthentication
1. JWT Tidak Valid
Kesalahan ini biasanya muncul apabila signature token tidak sesuai dengan public key yang digunakan oleh Istio.
JWT │ Invalid Signature │ 401 Unauthorized
Pastikan issuer menggunakan pasangan private key dan public key yang benar serta JWKS dapat diakses oleh Istio.
2. Token Sudah Kedaluwarsa
Apabila nilai exp telah terlewati, maka token akan ditolak secara otomatis.
Current Time
>
Token Expiration
│
▼
Rejected
3. Issuer Tidak Cocok
Periksa apakah nilai issuer pada RequestAuthentication sama dengan nilai iss yang terdapat di dalam JWT.
4. JWKS Tidak Dapat Diakses
Pastikan alamat jwksUri dapat diakses dan mengembalikan public key yang benar. Gangguan pada endpoint JWKS dapat menyebabkan seluruh proses autentikasi gagal.
Implementasi RequestAuthentication pada Lingkungan Production
Pada lingkungan production berskala besar, RequestAuthentication umumnya diterapkan pada gateway atau service yang menerima request langsung dari pengguna. Setelah token diverifikasi, identitas pengguna dapat diteruskan ke layanan internal sehingga setiap service tidak perlu melakukan proses autentikasi ulang.
Internet
│
Gateway
│
RequestAuthentication
│
Authorization Policy
│
Frontend Service
│
Order Service
│
Payment Service
│
Notification Service
Pendekatan ini mengurangi beban aplikasi karena proses autentikasi dilakukan secara terpusat pada lapisan service mesh.
Kelebihan RequestAuthentication
- Mendukung autentikasi berbasis standar JWT.
- Terintegrasi langsung dengan Istio Service Mesh.
- Mendukung berbagai Identity Provider.
- Mempermudah implementasi Zero Trust Security.
- Dapat digunakan bersama Authorization Policy.
- Mengurangi kebutuhan autentikasi di tingkat aplikasi.
- Mendukung validasi signature secara otomatis melalui JWKS.
- Mudah diterapkan menggunakan konfigurasi deklaratif YAML.
- Meningkatkan keamanan API modern.
- Kompatibel dengan Ambient Mesh maupun Sidecar Mode.
Kekurangan RequestAuthentication
- Membutuhkan Identity Provider yang dikelola dengan baik.
- Kesalahan konfigurasi issuer atau JWKS dapat menyebabkan seluruh autentikasi gagal.
- Tidak menentukan hak akses pengguna, sehingga tetap memerlukan Authorization Policy.
- JWT yang terlalu besar dapat menambah ukuran setiap request HTTP.
- Membutuhkan pemahaman mengenai konsep JWT dan kriptografi dasar.
Contoh Implementasi pada Platform E-Commerce
Sebuah platform e-commerce memiliki aplikasi web dan mobile yang menggunakan Identity Provider terpusat. Setiap pengguna harus login terlebih dahulu sebelum memperoleh JWT. Token tersebut kemudian dikirim pada setiap request menuju API.
User │ Login │ ▼ Identity Provider │ JWT │ ▼ Gateway │ RequestAuthentication │ Authorization Policy │ Product API │ Order API │ Payment API
Dengan pendekatan tersebut, seluruh layanan dapat memanfaatkan identitas yang sama tanpa perlu mengimplementasikan mekanisme autentikasi secara terpisah pada setiap service.
Baca Juga
Ganti tautan di atas dengan URL artikel yang sesuai di Blogger agar internal linking semakin kuat dan membantu pembaca mempelajari materi secara berurutan.
Artikel Selanjutnya
Setelah memahami bagaimana Istio memverifikasi identitas menggunakan JWT, pembahasan berikutnya akan berfokus pada PeerAuthentication, yaitu mekanisme untuk mengamankan komunikasi antar workload menggunakan Mutual TLS (mTLS).
RequestAuthentication
│
Verify JWT
│
▼
Authorization Policy
│
ALLOW / DENY
│
▼
PeerAuthentication
│
mTLS
│
Secure Communication
Dengan mempelajari PeerAuthentication, Anda akan memahami bagaimana Istio mengenkripsi komunikasi antar layanan sehingga data tetap aman selama berada di dalam cluster Kubernetes.
Pertanyaan yang Sering Diajukan (FAQ)
Apa itu RequestAuthentication?
RequestAuthentication adalah resource keamanan Istio yang digunakan untuk memverifikasi JSON Web Token (JWT) sebelum request diteruskan ke aplikasi.
Apakah RequestAuthentication sama dengan Authorization Policy?
Tidak. RequestAuthentication melakukan autentikasi dengan memverifikasi identitas, sedangkan Authorization Policy menentukan hak akses berdasarkan identitas tersebut.
Apa fungsi issuer?
Issuer menentukan pihak yang dipercaya untuk menerbitkan JWT. Istio hanya akan menerima token dari issuer yang telah dikonfigurasi.
Apa itu JWKS?
JWKS adalah kumpulan public key yang digunakan Istio untuk memverifikasi signature JWT secara otomatis.
Apakah JWT harus selalu dikirim melalui header Authorization?
Pada implementasi API modern, JWT umumnya dikirim melalui header Authorization: Bearer <token>, meskipun beberapa implementasi dapat menggunakan lokasi lain sesuai kebutuhan.
Apakah RequestAuthentication mendukung beberapa issuer?
Ya. Administrator dapat mendefinisikan lebih dari satu aturan JWT apabila aplikasi menerima token dari beberapa Identity Provider yang berbeda.
Apakah RequestAuthentication dapat digunakan tanpa Authorization Policy?
Bisa. Namun RequestAuthentication hanya memverifikasi token dan tidak mengatur hak akses. Untuk kontrol akses yang lengkap, gunakan bersama Authorization Policy.
Mengapa JWT perlu diverifikasi?
Verifikasi memastikan bahwa token benar-benar diterbitkan oleh pihak yang dipercaya, belum kedaluwarsa, dan tidak dimodifikasi oleh pihak lain.
Apakah RequestAuthentication mendukung Ambient Mesh?
Ya. Pada Ambient Mesh, proses validasi JWT dilakukan melalui Waypoint Proxy untuk lalu lintas Layer 7.
Mengapa RequestAuthentication penting?
Karena autentikasi merupakan langkah pertama dalam penerapan Zero Trust Security. Tanpa identitas yang tervalidasi, sistem tidak dapat mengambil keputusan otorisasi secara akurat.
Kesimpulan
Istio RequestAuthentication merupakan komponen penting dalam keamanan Kubernetes Service Mesh yang bertugas memverifikasi identitas pengguna maupun aplikasi melalui JSON Web Token (JWT). Dengan memanfaatkan issuer terpercaya dan JWKS, Istio dapat memastikan bahwa hanya token yang valid yang diteruskan ke tahap berikutnya.
Ketika dikombinasikan dengan Authorization Policy, HTTPRoute, dan PeerAuthentication, RequestAuthentication membentuk fondasi keamanan berlapis yang mendukung penerapan Zero Trust Security pada arsitektur microservices modern. Pendekatan ini tidak hanya meningkatkan keamanan aplikasi, tetapi juga mempermudah pengelolaan autentikasi secara terpusat di lingkungan cloud-native.
