At sikre en REST API betyder at besvare tre spørgsmål ved hver request: hvem er du (authentication), hvad har du lov til at gøre (authorization), og er kanalen privat (transport). Fordi REST er stateless, skal credentials rejse med hver request frem for at bo i en server-session.
Alt nedenfor forudsætter . Uden det rejser tokens og API keys i klartekst og kan aflyttes. Dette er ikke til forhandling — et bearer token over HTTP er et lækket token.
API keys — en statisk hemmelighed i en header. Enkelt; godt til server-to-server og til at identificere en applikation, ikke en bruger. Svage alene (ingen udløb, intet scope), medmindre de parres med mere.
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
OAuth 2.0 — standarden for delegeret adgang ("lad App X læse mine data uden mit password"). Appen får et access token via et flow (fx Authorization Code) og sender det som et bearer token. Det er sådan, "Sign in with Google" og tredjeparts-integrationer fungerer.
JWT (JSON Web Token) — et almindeligt format for tokens: et signeret, selvstændigt token, der bærer claims (user id, roller, udløb). Serveren verificerer signaturen — intet databaseopslag nødvendigt, hvilket passer til stateless REST.
header.payload.signature (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
Authentication beviser identitet; authorization afgør adgang. Tokens bærer scopes (orders:read, orders:write) eller roller; serveren tjekker dem per endpoint og returnerer 403 Forbidden, når de er utilstrækkelige (vs. 401 for manglende/ugyldig auth).
No/invalid token → 401 Unauthorized
Valid token, no scope → 403 Forbidden
✓ Kortlivede access tokens + refresh tokens (begræns skadesomfang ved læk)
✓ Rate limiting (429) for at sløve brute-force og misbrug
✓ Validér/sanitér alt input; stol aldrig på clienten
✓ Princippet om least privilege på scopes
Sikkerhed er der, hvor en lille fejl bliver til et brud, så interviewere bruger dette til at se, om du ræsonnerer om det strukturelt frem for at fremsige buzzwords. Signalet, de leder efter, er, at du adskiller de tre lag — transport (HTTPS, altid), authentication (at bevise identitet, stateless, via bearer tokens/JWT/OAuth) og authorization (scopes og least privilege) — og at du ikke sammenblander dem, fx ved korrekt at bruge 401 for "ikke autentificeret" versus 403 for "autentificeret, men ikke tilladt". Stærke svar viser bevidsthed om de praktiske afvejninger: JWT'er er bekvemme og stateless, men svære at tilbagekalde, før de udløber (derfor korte levetider plus refresh tokens), API keys identificerer apps, ikke brugere, og OAuth findes netop, så brugere ikke afleverer deres password til tredjeparter. At knytte det til REST's statelessness — credentials ved hver request, ingen server-session — viser, at du forstår hvorfor API-sikkerhed ser ud, som den gør.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér