Autentificare: key, OAuth, JWT

Serviciile își protejează API-urile prin autentificare. Cele trei mecanisme comune: cheie API (simplă), OAuth 2 (acces în numele unui utilizator, cu token care expiră), și JWT (token semnat, verificabil fără interogare). Fiecare are implicații de securitate diferite.

Cheie API

// simplu: un secret trimis într-un header
GET /v1/produse
Authorization: Bearer sk_live_abc123...

// sau ca parametru (mai puțin sigur, apare în log-uri):
GET /v1/produse?api_key=abc123

OAuth 2 (rezumat)

• Folosit când aplicația ta acționează în numele unui utilizator (ex: „conectează contul Google").
• Utilizatorul autorizează pe site-ul furnizorului → primești un „authorization code" → îl schimbi pe un „access token" (scurt) și un „refresh token" (lung).
• Access token-ul expiră (ex: 1 oră) — îl reînnoiești cu refresh token-ul, fără să deranjezi utilizatorul.
• Stochezi token-urile criptate, legate de utilizator.

JWT

Un token semnat care conține date (claims) despre cine ești și ce poți. Serviciul îl verifică cu o cheie publică, fără să interogheze o bază de date. Are expirare încorporată. Folosit des pentru autentificare între servicii (server-to-server).

Reguli comune tuturor

• Cheile și secretele stau în variabile de mediu, niciodată în cod.
• Nu le loga (nici în request logs, nici în mesaje de eroare).
• Rotește-le periodic; ai un plan dacă una e compromisă.
• Folosește chei separate per mediu (test/producție) și, dacă e posibil, cu permisiuni restrânse (scopes).

Semnături de cerere

Unele API-uri (AWS, unele procesatoare de plăți) cer să semnezi fiecare cerere cu un hash calculat din conținut + secret + timestamp. Protejează împotriva modificării și a reluării. Bibliotecile oficiale ale furnizorului fac asta pentru tine.

Client cu cheie din mediu

class SmsClient
{
    public function __construct(
        private string $apiKey = "",
    ) {
        $this->apiKey = $this->apiKey ?: config("services.sms.key");
    }

    public function trimite(string $catre, string $text): void
    {
        Http::withToken($this->apiKey)
            ->timeout(10)
            ->post("https://api.sms.ro/v1/messages", [
                "to" => $catre, "body" => $text,
            ])
            ->throw();
    }
}

Exercițiu

Pentru un serviciu cu cheie API (email, SMS), scrie o clasă client care citește cheia din config/mediu, are timeout, și aruncă o excepție la răspuns de eroare. Testeaz-o cu sandbox-ul furnizorului. Verifică că cheia NU apare în niciun log.

Greșeli frecvente

• Cheia API scrisă direct în cod sau comisă în Git.
• Cheia trimisă ca query param și apare în log-urile serverului.
• Nu tratezi expirarea access token-ului OAuth (nu folosești refresh token-ul).
• Aceeași cheie în test și producție.

De reținut

• Cheie API: simplu; OAuth: acces delegat cu token care expiră; JWT: token semnat verificabil.
• Secrete din mediu, niciodată logate, rotite periodic.
• Chei separate per mediu, cu scopes minime.
• Folosește bibliotecile oficiale pentru semnături de cerere.

Pe scurt

Alege mecanismul potrivit (cheie / OAuth / JWT), ține secretele în mediu, tratează expirarea token-urilor, și nu le loga niciodată.

Întrebări de alegere: cine deleagă accesul; ce operații; ce durată; cum se revocă; unde se păstrează secretul?
Cheie server: nu ajunge în browser.
Token: nu se pune în URL sau log.
JWT: semnătură și claims verificate, nu doar payload citit.
OAuth: flux documentat de furnizor.

Documentație și surse

• HTTP overview — MDN
• OWASP Top 10 — OWASP