Πώς ασφαλίζετε ένα REST API (authentication, authorization, transport);

Question

IT Interview Practice · Accepted Answer

Η ασφάλιση ενός REST API σημαίνει την απάντηση σε τρεις ερωτήσεις σε κάθε request: **ποιος είσαι** (authentication), **τι επιτρέπεται να κάνεις** (authorization), και **είναι ιδιωτικό το κανάλι** (transport). Επειδή το REST είναι **stateless**, τα διαπιστευτήρια πρέπει να ταξιδεύουν με κάθε request αντί να ζουν σε ένα session του server.

## Transport: πάντα HTTPS

Όλα τα παρακάτω προϋποθέτουν **TLS/HTTPS**. Χωρίς αυτό, tokens και API keys ταξιδεύουν σε plaintext και μπορούν να παρακολουθηθούν. Αυτό δεν είναι διαπραγματεύσιμο — ένα bearer token πάνω από HTTP είναι ένα διαρρευσμένο token.

## Επιλογές authentication

**API keys** — ένα στατικό μυστικό σε ένα header. Απλό· καλό για server-to-server και για την ταυτοποίηση μιας *εφαρμογής*, όχι ενός χρήστη. Αδύναμα από μόνα τους (χωρίς λήξη, χωρίς scope) εκτός αν συνδυαστούν με περισσότερα.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — το πρότυπο για **εξουσιοδοτημένη (delegated)** πρόσβαση ("άσε την App X να διαβάσει τα δεδομένα μου χωρίς τον κωδικό μου"). Η εφαρμογή αποκτά ένα **access token** μέσω ενός flow (π.χ. Authorization Code) και το στέλνει ως bearer token. Έτσι λειτουργούν το "Sign in with Google" και οι ενσωματώσεις τρίτων.

**JWT (JSON Web Token)** — ένα συνηθισμένο *φορμά* για tokens: ένα υπογεγραμμένο, αυτοτελές token που μεταφέρει claims (user id, roles, expiry). Ο server επαληθεύει την υπογραφή — δεν χρειάζεται αναζήτηση στη βάση δεδομένων, πράγμα που ταιριάζει στο stateless REST.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Authorization: scopes και roles

Η authentication αποδεικνύει την ταυτότητα· η **authorization** αποφασίζει την πρόσβαση. Τα tokens μεταφέρουν **scopes** (`orders:read`, `orders:write`) ή roles· ο server τα ελέγχει ανά endpoint και επιστρέφει `403 Forbidden` όταν είναι ανεπαρκή (έναντι `401` για ελλιπές/άκυρο auth).

```text
No/invalid token         → 401 Unauthorized
Valid token, no scope    → 403 Forbidden
```

## Άλλα ουσιώδη

```text
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
```

## Γιατί έχει σημασία

Η ασφάλεια είναι εκεί όπου ένα μικρό λάθος γίνεται παραβίαση, οπότε οι συνεντευξιαστές το χρησιμοποιούν για να δουν αν συλλογίζεστε γι' αυτήν δομικά παρά αν απαγγέλλετε buzzwords. Το σήμα που ψάχνουν είναι ότι **διαχωρίζετε τα τρία επίπεδα** — transport (HTTPS, πάντα), authentication (απόδειξη ταυτότητας, με stateless τρόπο, μέσω bearer tokens/JWT/OAuth), και authorization (scopes και least privilege) — και ότι δεν τα συγχέετε, π.χ. χρησιμοποιώντας σωστά το `401` για "μη πιστοποιημένος" έναντι του `403` για "πιστοποιημένος αλλά χωρίς άδεια". Οι δυνατές απαντήσεις δείχνουν επίγνωση των πρακτικών ανταλλαγών: τα JWTs είναι βολικά και stateless αλλά δύσκολα να ανακληθούν πριν λήξουν (εξ ου και οι σύντομοι χρόνοι ζωής συν refresh tokens), τα API keys ταυτοποιούν εφαρμογές όχι χρήστες, και το OAuth υπάρχει ειδικά ώστε οι χρήστες να μη δίνουν τον κωδικό τους σε τρίτους. Η σύνδεσή του με το statelessness του REST — διαπιστευτήρια σε κάθε request, χωρίς session server — δείχνει ότι κατανοείτε *γιατί* η ασφάλεια API μοιάζει όπως μοιάζει.

Transport: πάντα HTTPS

Επιλογές authentication

Authorization: scopes και roles

Άλλα ουσιώδη

Γιατί έχει σημασία

Σχετικές ερωτήσεις