OAuth

Cum funcționează OAuth

OAuth separă aplicația care solicită accesul de serviciul care deține resursele protejate. În fluxul general apar proprietarul resursei, aplicația client, serverul de autorizare și serverul de resurse.

Aplicația solicită o autorizare. Proprietarul resursei poate aproba permisiunile cerute, iar serverul de autorizare emite un authorization code sau un access token. Dacă primește un authorization code, aplicația îl schimbă ulterior pentru un access token. Clientul prezintă tokenul serverului de resurse pentru a accesa operațiunile permise.

OAuth permite și accesul acordat direct aplicației, în nume propriu, atunci când scenariul nu implică aprobarea unui utilizator.

Rolul scope-urilor și tokenurilor

Parametrul scope controlează resursele și operațiunile pe care le permite un access token. Aplicația trebuie să compare scope-urile acordate cu cele necesare funcțiilor sale. Permisiunile primite pot fi diferite de cele solicitate.

Access tokenurile au o durată de viață limitată. Un refresh token poate permite obținerea unor tokenuri noi atât timp cât rămâne valid. Refresh tokenurile trebuie păstrate într-un spațiu sigur.

Tokenurile Bearer necesită protecție atentă. Oricine deține un asemenea token îl poate utiliza fără să demonstreze posesia unei chei criptografice. Tokenul trebuie protejat atât la stocare, cât și în timpul transmiterii. Pentru cererile HTTP, metoda recomandată este trimiterea lui în antetul Authorization, nu în parametrul query al URL-ului, unde poate ajunge în loguri.

OAuth este un protocol de autorizare. Pentru folosirea OAuth în autentificare, documentația Google indică OpenID Connect. În aplicațiile native, cererea de autorizare trebuie realizată printr-un agent extern, de regulă browserul, nu printr-un web-view controlat de aplicație.

În activitatea SEO, OAuth poate avea un rol operațional atunci când un instrument intern, un conector sau o automatizare trebuie să acceseze un API protejat, inclusiv un Google API. Configurarea clientului, a scope-urilor, a tokenurilor și a fluxului de autorizare determină dacă integrarea poate primi datele sau poate executa operațiunile permise.

Scope-urile trebuie verificate după autorizare, deoarece cele acordate pot să nu coincidă cu cele solicitate. Funcțiile care depind de permisiuni neacordate trebuie dezactivate.

OAuth oferă acces la resurse protejate numai în limitele permisiunilor asociate tokenului. Funcționarea unei integrări autorizate pentru o aplicație nu acordă automat acces altor aplicații sau servicii care nu dețin autorizarea necesară.

O platformă românească de programări vrea să adauge un eveniment în calendarul utilizatorului. Aplicația solicită acces numai când utilizatorul apasă butonul „Adaugă în calendar”. Utilizatorul aprobă permisiunea, iar aplicația primește un access token cu scope-ul acordat.

Tokenul este trimis către API în antetul HTTP:

Authorization: Bearer ACCESS_TOKEN

Aplicația verifică scope-ul primit înainte de activarea funcției. Dacă permisiunea necesară nu a fost acordată, funcția dependentă de acel API este dezactivată. Tokenul nu este introdus în URL.

1. Verifică în consola furnizorului dacă tipul de client OAuth corespunde platformei aplicației.
2. Controlează URL-ul de redirecționare și confirmă că răspunsul revine la destinația configurată.
3. Inspectează răspunsul serverului de autorizare și compară scope-urile acordate cu cele necesare aplicației.
4. Verifică dacă tokenul este transmis prin antetul Authorization, fără a-i expune valoarea.
5. Testează accesul la resursa protejată și tratează răspunsurile de eroare ale serverului.
6. Pentru o integrare Google, folosește OAuth 2.0 Playground pentru demonstrarea fluxului și consultă Google API Console pentru credențialele clientului.

1. Folosește o bibliotecă OAuth bine verificată, potrivită platformei și furnizorului.
2. Solicită scope-urile incremental, atunci când funcția are nevoie de acces.
3. Compară permisiunile acordate cu permisiunile necesare înainte de activarea funcțiilor dependente.
4. Transmite tokenurile Bearer prin antetul HTTP Authorization și protejează-le la stocare și transport.
5. Păstrează refresh tokenurile într-un spațiu sigur și gestionează situațiile în care nu mai sunt valide.
6. Pentru aplicațiile native, deschide autorizarea într-un agent extern, de regulă browserul, nu într-un web-view controlat de aplicație.