Edge Authentication and Authorization
Authentication and Authorization at the Edge
Memahami basic auth, auth_request, external auth, OIDC proxy pattern, JWT validation, mTLS identity, identity headers, dan trust boundary.
Part 019 — Authentication and Authorization at the Edge
1. Tujuan Part Ini
Authentication dan authorization di edge sering terlihat sederhana:
cek user sebelum request masuk ke backend
Dalam enterprise Java/JAX-RS system, kalimat itu berbahaya kalau tidak dibedah.
Edge layer seperti NGINX dapat membantu melakukan:
basic authentication
IP allowlist
mTLS client certificate validation
subrequest ke external auth service
OIDC/OAuth2 proxy integration
header-based identity propagation
coarse-grained route protection
Tetapi edge layer tidak otomatis menggantikan authorization aplikasi.
Part ini membangun mental model untuk menjawab:
apa yang sebaiknya dilakukan NGINX?
apa yang tetap harus dilakukan Java/JAX-RS service?
header identitas mana yang bisa dipercaya?
di mana trust boundary dimulai?
apa yang terjadi kalau auth service down?
bagaimana auth failure terlihat di log dan metrics?
Targetnya bukan hafal directive. Targetnya adalah bisa mereview desain auth di proxy layer tanpa menciptakan celah privilege escalation, spoofed identity, atau outage karena dependency auth yang rapuh.
2. Mental Model: Authentication, Authorization, and Identity Propagation
Pisahkan tiga hal berikut:
| Konsep | Pertanyaan utama | Contoh |
|---|---|---|
| Authentication | Siapa pemanggilnya? | user, service account, client certificate subject |
| Authorization | Boleh melakukan apa? | boleh akses route, tenant, order, quote, admin API |
| Identity propagation | Bagaimana identitas diteruskan? | header, token, mTLS identity, session, trace context |
NGINX sering berada di antara client dan backend:
client
-> load balancer
-> NGINX / ingress
-> Java/JAX-RS service
Di posisi ini, NGINX dapat menjadi enforcement point untuk beberapa policy, tetapi ia tidak tahu domain rule aplikasi kecuali rule itu dieksternalisasi ke auth service.
Contoh domain rule yang biasanya bukan tanggung jawab NGINX:
user A hanya boleh melihat quote milik tenant X
sales rep hanya boleh edit quote sebelum status submitted
partner hanya boleh submit order untuk product family tertentu
admin internal boleh override validation tertentu
Rule seperti itu membutuhkan domain context, data ownership, workflow state, dan audit trail. Itu biasanya harus berada di application/domain layer atau dedicated policy engine, bukan di konfigurasi NGINX statis.
3. Edge Auth Is a Trust Boundary, Not Just Middleware
Auth di edge adalah boundary.
Boundary berarti:
semua request dari luar dianggap tidak dipercaya
hanya request yang melewati enforcement point boleh membawa identity header
identity header dari client luar harus dibuang atau ditimpa
backend hanya boleh percaya header dari proxy yang trusted
Kesalahan umum:
Client mengirim X-User-ID: admin
NGINX meneruskan header apa adanya
Java service percaya X-User-ID
attacker menjadi admin secara logis
Proxy harus memiliki policy eksplisit:
proxy_set_header X-User-ID "";
proxy_set_header X-Authenticated-User $auth_user;
Atau lebih aman:
hapus semua inbound identity header yang tidak trusted
set ulang identity header hanya setelah auth berhasil
backend memvalidasi bahwa request datang dari trusted proxy/network
4. Apa yang Layak Dilakukan di NGINX Layer
NGINX cocok untuk policy yang relatif coarse-grained dan dekat dengan HTTP/network boundary.
Contoh yang cocok:
reject request tanpa client certificate
protect internal dashboard dengan basic auth
blokir route admin dari public internet
validasi session/token melalui external auth service
memaksa redirect HTTP ke HTTPS
menolak request dari IP yang tidak diizinkan
menambah identity header setelah external auth sukses
menolak request sebelum menyentuh expensive Java endpoint
NGINX kurang cocok untuk:
tenant-level authorization kompleks
row-level permission
workflow state authorization
entitlement berbasis katalog produk
dynamic policy dengan banyak dependency domain
fine-grained audit decision di level entity
Rule praktis:
Edge may authenticate.
Edge may enforce coarse access.
Application must still protect domain actions.
5. Basic Auth: Useful, but Narrow
Basic auth di NGINX berguna untuk use case sederhana:
internal temporary endpoint
staging environment
low-risk admin page behind VPN
basic protection untuk static diagnostic page
Contoh:
location /internal/status {
auth_basic "restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://status-service;
}
Kelebihan:
sederhana
mudah dipahami
bisa diterapkan tanpa perubahan aplikasi
Kelemahan:
credential lifecycle lemah jika tidak dikelola baik
tidak cocok untuk user enterprise SSO
tidak membawa authorization domain
sering tidak punya audit identity yang kaya
raw password file harus diamankan
Untuk production enterprise API, basic auth biasanya bukan identity architecture utama. Ia lebih sering menjadi emergency/temporary/internal control.
6. IP Allowlist and Network-Based Access
NGINX dapat membatasi akses berdasarkan IP:
location /admin/ {
allow 10.0.0.0/8;
allow 192.168.0.0/16;
deny all;
proxy_pass http://admin-api;
}
Namun IP allowlist hanya aman jika real client IP benar.
Di belakang load balancer, NGINX bisa melihat:
IP load balancer
IP node Kubernetes
IP NAT gateway
IP corporate proxy
IP client asli
Jika real IP tidak dipreservasi, allowlist bisa salah total.
Hal yang harus dipastikan:
apakah X-Forwarded-For trusted?
apakah real_ip_header diset?
apakah set_real_ip_from hanya untuk trusted LB?
apakah proxy protocol digunakan?
apakah cloud LB melakukan source IP preservation?
Contoh real IP hardening:
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
Jangan menerima X-Forwarded-For dari internet tanpa trusted boundary. Header itu mudah dipalsukan oleh client.
7. mTLS Identity at the Edge
mTLS memungkinkan NGINX memvalidasi client certificate.
Flow sederhana:
client memiliki certificate
NGINX meminta client certificate saat TLS handshake
NGINX memvalidasi certificate terhadap trusted CA
jika valid, request diterima
NGINX dapat meneruskan subject/fingerprint ke backend
Contoh konseptual:
server {
listen 443 ssl;
ssl_certificate /etc/nginx/tls/server.crt;
ssl_certificate_key /etc/nginx/tls/server.key;
ssl_client_certificate /etc/nginx/ca/client-ca.crt;
ssl_verify_client on;
location /partner-api/ {
proxy_set_header X-Client-Cert-Subject $ssl_client_s_dn;
proxy_set_header X-Client-Cert-Verify $ssl_client_verify;
proxy_pass http://partner-api;
}
}
Kekuatan mTLS:
identity berbasis certificate, bukan hanya bearer token
cocok untuk service-to-service atau partner integration
bisa menjadi strong client authentication
Risiko mTLS:
certificate lifecycle kompleks
revocation sulit jika tidak didesain
CA trust salah bisa membuka akses luas
header forwarding subject bisa dipalsukan jika tidak dibersihkan di edge
backend sering menganggap certificate subject sebagai authorization penuh
mTLS membuktikan identitas teknis client. Ia tidak otomatis menjawab apakah client boleh melakukan action domain tertentu.
8. auth_request: External Authorization Pattern
auth_request adalah pattern penting di NGINX.
Mental model:
request utama datang ke NGINX
NGINX membuat subrequest internal ke auth service
auth service menjawab allow/deny
jika allow, request utama diteruskan ke backend
jika deny, request utama dihentikan di edge
Contoh:
location /api/ {
auth_request /_auth;
auth_request_set $auth_user $upstream_http_x_auth_user;
auth_request_set $auth_tenant $upstream_http_x_auth_tenant;
proxy_set_header X-Authenticated-User $auth_user;
proxy_set_header X-Authenticated-Tenant $auth_tenant;
proxy_pass http://jaxrs-api;
}
location = /_auth {
internal;
proxy_pass http://auth-service/validate;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Original-Method $request_method;
}
Interpretasi umum:
2xx dari auth service -> allow
401/403 -> deny
status lain -> dianggap error
Kelebihan:
logic auth bisa dikelola di service terpisah
aplikasi utama tidak perlu menerima request unauthenticated
bisa reuse untuk banyak backend
bisa centralize token/session validation
Kelemahan:
auth service menjadi dependency di critical path
latency auth menambah latency semua request
failure auth bisa menyebabkan outage luas
caching keputusan auth harus sangat hati-hati
body request tidak ideal untuk decision kompleks
9. External Auth Service Design
Auth service untuk auth_request harus didesain sebagai production dependency, bukan helper kecil.
Ia harus jelas tentang:
input apa yang dibaca
header apa yang dipercaya
output header apa yang dihasilkan
status code apa yang berarti allow/deny/error
timeout dan retry policy
fail-open atau fail-closed policy
cacheability decision
observability
rate limit
HA dan scaling
Kontrak response yang baik:
204 No Content -> allow
401 Unauthorized -> unauthenticated
403 Forbidden -> authenticated but not allowed
5xx -> auth system error
Header output:
X-Auth-User
X-Auth-Tenant
X-Auth-Scopes
X-Auth-Subject
X-Auth-Session-ID
Tetapi header output harus diperlakukan sebagai internal contract antara auth service, NGINX, dan backend. Client publik tidak boleh bisa menginjeksi header yang sama.
10. OIDC/OAuth2 Proxy Pattern
NGINX open source tidak menjadi full OIDC identity provider client secara default.
Pattern umum:
client
-> NGINX
-> oauth2-proxy / external auth service
-> identity provider
-> NGINX
-> Java/JAX-RS backend
OIDC proxy menangani:
redirect login
callback
session cookie
token validation
refresh token jika berlaku
user info
identity header generation
NGINX menangani:
routing
TLS
auth_request subrequest
header cleanup
header propagation
error page/redirect behavior
Pertanyaan senior engineer:
apakah flow browser atau API machine-to-machine?
apakah unauthorized API harus 401 JSON atau redirect login?
apakah cookie session aman untuk domain/path?
apakah token audience divalidasi?
apakah scopes/roles dipetakan dengan benar?
apakah identity header dilindungi dari spoofing?
Jangan mencampur browser login behavior dengan API behavior tanpa desain eksplisit. API client biasanya mengharapkan 401/403, bukan HTML redirect ke login page.
11. JWT Validation at the Edge
JWT validation di edge memiliki dua model besar:
NGINX Plus/native module atau product-specific feature
external auth service yang memvalidasi JWT
custom module/script/lua/njs tergantung platform
Untuk NGINX Open Source standar, jangan mengasumsikan JWT validation native tersedia. Banyak environment memilih external auth service atau API gateway untuk JWT.
JWT validation yang benar harus memeriksa:
signature
issuer
audience
expiration
not-before
algorithm
key rotation / JWKS
scope/role claim
clock skew
revocation strategy jika dibutuhkan
Kesalahan fatal:
hanya decode JWT tanpa verify signature
percaya alg dari token secara buta
tidak memeriksa audience
tidak menangani key rotation
tidak membedakan access token dan ID token
meneruskan seluruh token ke backend/log tanpa redaction
Untuk Java/JAX-RS backend, edge JWT validation bisa mengurangi beban validasi awal. Tetapi backend tetap perlu memastikan bahwa route/action domain dilindungi sesuai policy.
12. Header-Based Identity Propagation
Setelah auth berhasil, NGINX sering meneruskan identity ke backend lewat header.
Contoh:
proxy_set_header X-Authenticated-User $auth_user;
proxy_set_header X-Authenticated-Tenant $auth_tenant;
proxy_set_header X-Authenticated-Scopes $auth_scopes;
Prinsip utama:
identity header harus dibuat oleh trusted component
identity header dari external client harus dibuang
backend harus tahu header mana yang authoritative
header harus cukup untuk audit, tetapi tidak membocorkan data sensitif
Header propagation yang buruk:
client -> X-Authenticated-User: admin
NGINX -> proxy_set_header tidak menghapus header lama
backend -> percaya header admin
Header propagation yang lebih aman:
# clear untrusted inbound identity headers
proxy_set_header X-User-ID "";
proxy_set_header X-Role "";
proxy_set_header X-Tenant-ID "";
# set only trusted values after auth
proxy_set_header X-Authenticated-User $auth_user;
proxy_set_header X-Authenticated-Tenant $auth_tenant;
Di Java/JAX-RS, buat filter eksplisit yang membaca trusted headers hanya jika request berasal dari trusted proxy/network.
13. Where Authorization Should Live
Authorization sering punya beberapa layer:
| Layer | Cocok untuk | Tidak cocok untuk |
|---|---|---|
| Cloud LB/WAF | IP, DDoS, coarse protection | user-level business rule |
| NGINX | route protection, external auth, mTLS, header cleanup | entity-level permission kompleks |
| API Gateway | auth, quota, subscription, API product policy | deep domain workflow rule |
| Java/JAX-RS app | domain authorization, tenant isolation, workflow state | generic edge filtering |
| Policy engine | central policy decision | raw traffic routing |
Untuk quote/order domain, authorization sering bergantung pada:
tenant
account
quote ownership
order lifecycle status
sales channel
role
entitlement
commercial rule
approval state
Rule ini terlalu kaya untuk dipaksakan ke NGINX config. NGINX dapat menjaga pintu masuk, tetapi domain service tetap harus menjaga state transition dan data access.
14. Auth Failure Semantics
Jangan campur 401 dan 403.
401 Unauthorized -> belum authenticated atau credential invalid
403 Forbidden -> authenticated tetapi tidak punya izin
404 Not Found -> kadang dipakai untuk menyembunyikan resource, tapi harus konsisten
500/502/503/504 -> auth infrastructure failure, bukan user denial
Untuk API enterprise, response auth harus predictable.
Contoh JSON error:
{
"error": "unauthorized",
"message": "Authentication is required",
"correlationId": "..."
}
Atau:
{
"error": "forbidden",
"message": "You are not allowed to access this resource",
"correlationId": "..."
}
NGINX dapat menggunakan error_page untuk menstandardisasi response, tetapi hati-hati agar tidak menyembunyikan root cause auth service failure.
15. Fail-Open vs Fail-Closed
Auth dependency failure memaksa pilihan kritis:
fail-closed -> tolak request saat auth tidak bisa diverifikasi
fail-open -> izinkan request saat auth service gagal
Untuk public API, production enterprise system biasanya fail-closed.
Fail-open hanya mungkin untuk kasus yang sangat terbatas dan harus disetujui security, misalnya:
low-risk static content
non-sensitive health route
internal fallback dengan kompensasi kuat
Risiko fail-closed:
auth service outage menjadi customer-facing outage
Risiko fail-open:
unauthorized access saat dependency auth gagal
Senior engineer harus memastikan policy ini eksplisit, bukan efek samping timeout/default NGINX.
16. Timeout and Retry for Auth Service
Auth service berada di critical path.
Jika setiap request API membutuhkan auth check, maka auth latency menjadi bagian dari request latency.
Contoh risiko:
backend Java cepat 50 ms
auth service lambat 800 ms
client melihat API lambat
application team disalahkan padahal bottleneck di auth path
Auth subrequest harus punya timeout jelas:
location = /_auth {
internal;
proxy_pass http://auth-service/validate;
proxy_connect_timeout 1s;
proxy_send_timeout 1s;
proxy_read_timeout 2s;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
}
Retry auth harus hati-hati.
Jika auth service overload, retry bisa memperburuk:
request spike -> auth slow -> NGINX retry -> auth makin overload -> outage lebih luas
Rule praktis:
Auth timeout must be shorter than user-facing API timeout.
Auth retry must be deliberate.
Auth failures must be visible separately from backend failures.
17. Caching Auth Decisions
Caching auth decision terlihat menarik untuk performance.
Tetapi pertanyaannya sulit:
berapa lama keputusan boleh valid?
bagaimana jika user dicabut aksesnya?
apakah token revoked?
apakah tenant role berubah?
apakah permission bergantung resource ID?
apakah decision berbeda untuk method/path/body?
Auth cache aman untuk kasus terbatas:
short TTL
coarse token/session validation
non-critical permission
clear cache key
explicit revocation trade-off
Auth cache berbahaya untuk:
admin privilege
financial/commercial action
tenant isolation
state-changing API
high-risk operation
Jika menggunakan cache, cache key harus minimal mencakup:
subject
method
path atau route group
scope/tenant
relevant token/session identity
Jangan cache authorization hanya berdasarkan IP.
18. Kubernetes Ingress Authentication Patterns
Dalam Kubernetes, auth dapat muncul sebagai:
Ingress annotation untuk external auth
ConfigMap global
server/configuration snippet
sidecar auth proxy
API gateway sebelum ingress
service mesh authorization
application-level filter
Contoh konseptual annotation external auth pada controller berbasis NGINX:
metadata:
annotations:
nginx.ingress.kubernetes.io/auth-url: "http://auth-service.auth.svc.cluster.local/validate"
nginx.ingress.kubernetes.io/auth-response-headers: "X-Auth-User,X-Auth-Tenant,X-Auth-Scopes"
Catatan penting:
annotation berbeda antar controller
community ingress-nginx berbeda dari F5 NGINX Ingress Controller
fitur OIDC/JWT/native auth bisa product-specific
snippets bisa berbahaya jika tidak digovernance
Jangan menyalin annotation dari internet tanpa mencocokkan controller yang benar.
19. Auth in AWS, Azure, On-Prem, and Hybrid Deployment
Auth boundary bisa berpindah tergantung deployment.
AWS/EKS:
Route 53 -> ALB/NLB -> NGINX Ingress -> Service -> Pod
Kemungkinan auth layer:
AWS WAF
ALB authentication feature jika digunakan
API Gateway / Cognito jika digunakan
NGINX external auth
application JWT validation
Azure/AKS:
Azure Front Door -> Application Gateway -> NGINX Ingress -> Service -> Pod
Kemungkinan auth layer:
Azure API Management
Azure Front Door/WAF
Application Gateway integration
NGINX auth_request
application authorization
On-prem/hybrid:
corporate firewall -> enterprise reverse proxy -> NGINX -> private Kubernetes -> Java service
Kemungkinan auth layer:
enterprise SSO
mTLS partner certificate
VPN/private network
internal API gateway
application authorization
Internal verification wajib karena setiap organisasi bisa menaruh auth di layer berbeda.
20. Java/JAX-RS Backend Considerations
Backend Java/JAX-RS tidak boleh pasif menerima semua header.
Hal yang perlu ada di aplikasi:
trusted proxy configuration
request filter untuk membaca identity context
reject jika identity header wajib tidak ada
clear separation authn vs authz
tenant isolation check
domain-level authorization
correlation ID propagation
audit event untuk sensitive action
Contoh pseudo-flow di JAX-RS filter:
public void filter(ContainerRequestContext ctx) {
String user = ctx.getHeaderString("X-Authenticated-User");
String tenant = ctx.getHeaderString("X-Authenticated-Tenant");
if (user == null || tenant == null) {
throw new NotAuthorizedException("Missing authenticated identity");
}
// Build internal security context.
// Do not treat this as permission to access every tenant resource.
}
Jangan jadikan identity header sebagai global bypass authorization.
21. Security Concerns
Security concern utama di edge auth:
spoofed identity header
Host header injection
improper trust of X-Forwarded-* headers
fail-open behavior tidak disengaja
OIDC redirect mismatch
token leakage in logs
mTLS CA terlalu luas
auth service SSRF exposure
basic auth file leakage
snippet annotation abuse
CORS + auth misconfiguration
Hardening minimum:
strip untrusted identity headers
set identity headers only after auth
limit who can change Ingress auth annotations
protect auth service from public access
redact Authorization/Cookie headers in logs
use HTTPS/mTLS to auth service if boundary requires
monitor 401/403/5xx auth separately
22. Observability for Edge Auth
Auth harus terlihat sebagai dependency terpisah.
Log fields yang berguna:
request_id
client_ip
host
method
path
status
auth_status
auth_user_hash
auth_tenant
auth_upstream_time
upstream_status
request_time
Jangan log raw token.
Jangan log full cookie.
Jangan log PII yang tidak perlu.
Untuk dashboard:
401 rate
403 rate
auth service 5xx
auth subrequest latency
auth timeout count
auth denied by route
auth denied by tenant/scope if available
top paths denied
Tanpa observability ini, auth incident sering terlihat seperti application outage atau generic 502.
23. Failure Modes
Common failure modes:
401 untuk semua request karena cookie/token tidak diteruskan ke auth service
403 karena scope mapping salah
502 karena auth service tidak reachable
504 karena auth service timeout
redirect loop pada OIDC login
API client menerima HTML login page
backend percaya spoofed identity header
mTLS client cert valid tetapi tenant mapping salah
certificate rotation membuat semua partner gagal
Ingress auth annotation tidak berlaku karena controller berbeda
CORS preflight gagal karena auth diterapkan ke OPTIONS tanpa pengecualian
Debugging sequence:
cek apakah request mencapai NGINX
cek status NGINX utama
cek auth subrequest status
cek auth service log
cek header yang dikirim ke auth service
cek header yang diteruskan ke backend
cek backend authorization log
cek correlation ID end-to-end
24. PR Review Checklist
Gunakan checklist ini saat review perubahan auth di NGINX/Ingress:
Apakah perubahan ini authentication, authorization, atau identity propagation?
Layer mana yang menjadi source of truth?
Apakah identity header dari client dibersihkan?
Apakah backend hanya percaya trusted proxy?
Apakah unauthorized API mengembalikan 401/403, bukan redirect HTML?
Apakah CORS preflight dipertimbangkan?
Apakah auth service timeout jelas?
Apakah fail-open/fail-closed eksplisit?
Apakah auth response header dibatasi?
Apakah token/cookie tidak bocor ke log?
Apakah route sensitive punya protection tambahan?
Apakah perubahan annotation sesuai controller yang digunakan?
Apakah ada dashboard/alert untuk auth failure?
Apakah rollback jelas?
25. Internal Verification Checklist
Untuk konteks CSG/team, jangan mengasumsikan arsitektur auth. Verifikasi:
Apakah auth dilakukan di cloud LB, API gateway, NGINX, service mesh, atau aplikasi?
Apakah ada IdP/OIDC provider resmi?
Apakah ada OAuth2 proxy atau external auth service?
Apakah Ingress memakai community ingress-nginx atau F5 NGINX Ingress Controller?
Annotation auth apa yang didukung dan diizinkan?
Apakah snippets diaktifkan?
Apakah NGINX Open Source atau NGINX Plus?
Apakah fitur JWT native tersedia atau harus external auth?
Header identity apa yang authoritative?
Apakah backend Java/JAX-RS punya trusted proxy filter?
Bagaimana tenant identity diteruskan?
Bagaimana audit event dibuat untuk action sensitive?
Apakah Authorization/Cookie/log redaction sudah benar?
Apakah auth service punya SLO, dashboard, dan runbook?
Apakah certificate/mTLS dipakai untuk partner atau internal service?
Bagaimana emergency access dan rollback dilakukan?
26. Anti-Patterns
Menganggap NGINX auth menggantikan domain authorization aplikasi.
Meneruskan X-User-ID dari client tanpa sanitization.
Menerima X-Forwarded-For dari internet sebagai trusted identity.
Menggunakan basic auth sebagai enterprise SSO jangka panjang.
Menaruh complex business authorization di rewrite/config NGINX.
Membiarkan API client mendapat redirect HTML saat token invalid.
Tidak membedakan 401 dan 403.
Fail-open tanpa approval security.
Auth service critical path tanpa timeout/metrics.
Logging Authorization header atau cookie penuh.
Mengaktifkan snippets auth tanpa governance.
Mengasumsikan JWT validation tersedia di semua varian NGINX.
Menggunakan mTLS subject sebagai izin domain penuh.
Tidak menguji CORS preflight.
27. Practical Senior Engineer Heuristics
Authentication can be centralized; authorization remains contextual.
Identity headers are safe only after a trusted proxy sets them.
Every external identity header should be guilty until proven trusted.
Auth service latency is API latency.
Auth service outage is production outage unless designed otherwise.
JWT decoded is not JWT verified.
mTLS proves client identity, not business permission.
401/403 correctness matters for client behavior and incident diagnosis.
OIDC browser flows and API machine flows should not be mixed carelessly.
Edge auth must be observable as its own dependency.
28. Ringkasan
NGINX dapat menjadi layer penting untuk authentication dan coarse authorization, terutama dalam enterprise system yang membutuhkan TLS, mTLS, external auth, OIDC proxy pattern, IP restriction, dan identity propagation.
Tetapi NGINX bukan pengganti domain authorization di Java/JAX-RS service.
Target pemahaman senior engineer:
membedakan authn, authz, identity propagation
memahami trust boundary header
menggunakan auth_request dengan benar
menilai kapan basic auth, mTLS, JWT, atau OIDC proxy cocok
melihat auth service sebagai critical dependency
mendesain 401/403/5xx semantics yang jelas
menjaga backend tetap melakukan domain authorization
mereview perubahan auth sebagai security architecture change
Auth yang baik tidak hanya menolak request yang salah. Auth yang baik membuat boundary sistem jelas, dapat diaudit, dapat di-debug, dan tidak memberi celah bagi spoofed identity atau privilege escalation.
29. Referensi Resmi untuk Diverifikasi
NGINX auth_request module:
https://nginx.org/en/docs/http/ngx_http_auth_request_module.html
NGINX basic auth module:
https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html
NGINX Ingress Controller documentation:
https://docs.nginx.com/nginx-ingress-controller/
You just completed lesson 19 in build core. Use the series map if you want to review the broader track, or continue directly into the next lesson while the context is still warm.
Keep the momentum while the lesson is still fresh. Move backward for review or continue forward into the next concept.