Bagaimana anda menjamin REST API (authentication, authorization, transport)?

Question

IT Interview Practice · Accepted Answer

Menjamin REST API bermakna menjawab tiga soalan pada setiap request: siapa anda (authentication), apa yang anda dibenarkan lakukan (authorization), dan adakah saluran itu peribadi (transport). Oleh sebab REST bersifat stateless, kelayakan (credentials) mesti bergerak bersama setiap request dan bukannya berada dalam session server.

Transport: sentiasa HTTPS

Segala di bawah menganggap . Tanpanya, token dan API key bergerak dalam teks biasa dan boleh dihidu. Ini tidak boleh dirunding — bearer token melalui HTTP ialah token yang bocor.

## Transport: sentiasa HTTPS

Segala di bawah menganggap **TLS/HTTPS**. Tanpanya, token dan API key bergerak dalam teks biasa dan boleh dihidu. Ini tidak boleh dirunding — bearer token melalui HTTP ialah token yang bocor.

## Pilihan authentication

**API key** — rahsia statik dalam header. Ringkas; sesuai untuk server-to-server dan mengenal pasti *aplikasi*, bukan pengguna. Lemah dengan sendirinya (tiada tamat tempoh, tiada scope) melainkan digandingkan dengan lebih banyak.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standard untuk akses **diwakilkan (delegated)** ("benarkan App X membaca data saya tanpa kata laluan saya"). Aplikasi memperoleh **access token** melalui satu flow (cth. Authorization Code) dan menghantarnya sebagai bearer token. Inilah cara "Sign in with Google" dan integrasi pihak ketiga berfungsi.

**JWT (JSON Web Token)** — *format* token yang lazim: token bertandatangan, lengkap-sendiri yang membawa claim (user id, role, tamat tempoh). Server mengesahkan tandatangan — tiada carian pangkalan data diperlukan, yang sesuai dengan REST stateless.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Authorization: scope dan role

Authentication membuktikan identiti; **authorization** memutuskan akses. Token membawa **scope** (`orders:read`, `orders:write`) atau role; server menyemaknya bagi setiap endpoint dan memulangkan `403 Forbidden` apabila ia tidak mencukupi (berbanding `401` untuk auth yang hilang/tidak sah).

```text
Tiada token/token tidak sah → 401 Unauthorized
Token sah, tiada scope      → 403 Forbidden
```

## Perkara penting lain

```text
✓ Access token jangka pendek + refresh token (hadkan radius letupan jika bocor)
✓ Rate limiting (429) untuk menumpulkan brute-force dan penyalahgunaan
✓ Validate/sanitize semua input; jangan sekali-kali percaya client
✓ Prinsip least privilege pada scope
```

## Mengapa ia penting

Keselamatan ialah tempat kesilapan kecil menjadi pelanggaran, jadi penemu duga menggunakan ini untuk melihat sama ada anda menaakulnya secara berstruktur dan bukannya melafazkan buzzword. Isyarat yang mereka cari ialah anda **mengasingkan tiga lapisan** — transport (HTTPS, sentiasa), authentication (membuktikan identiti, secara stateless, melalui bearer token/JWT/OAuth), dan authorization (scope dan least privilege) — dan anda tidak mencampuradukkannya, cth. menggunakan `401` dengan betul untuk "belum disahkan" berbanding `403` untuk "disahkan tetapi tidak dibenarkan." Jawapan yang kukuh menunjukkan kesedaran terhadap trade-off praktikal: JWT mudah dan stateless tetapi sukar dibatalkan sebelum ia tamat tempoh (oleh itu hayat pendek serta refresh token), API key mengenal pasti aplikasi bukan pengguna, dan OAuth wujud khusus supaya pengguna tidak menyerahkan kata laluan mereka kepada pihak ketiga. Mengaitkannya dengan sifat stateless REST — kelayakan pada setiap request, tiada session server — menunjukkan anda memahami *mengapa* keselamatan API kelihatan seperti sekarang.

Transport: sentiasa HTTPS

Pilihan authentication

Authorization: scope dan role

Perkara penting lain

Mengapa ia penting

Soalan berkaitan