ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 132
Abonament PDF

Securitatea protocolului OAuth 2.0

Silviu Cucuiet
Full stack Developer @ Zenitech



PROGRAMARE


OAuth (Open Authorization) este un protocol standardizat, utilizat pentru autorizarea securizată a accesului la resursele unei aplicații de către o altă aplicație sau serviciu. Este predecesorul OAuth 1.0, care, spre deosebire de acesta, folosea semnături criptografice în loc de tokenuri și code-uri de acces. De asemenea, este mult mai standardizat, flexibil și ușor de folosit decât versiunea anterioară. Există anumite aspecte în care OAuth 1 oferea un nivel mai mare de securitate comparativ cu prima versiune a OAuth 2.0, dar acest lucru nu înseamnă că OAuth 1.0 este întotdeauna mai sigur.

Importanța acestui protocol

OAuth a fost conceput inițial pentru a permite utilizatorilor să ofere acces la conturile lor de pe platforme terțe fără a distribui parola. Printre cei mai populari furnizori de astfel de acces sunt Google, Twitter, Facebook, facilitând accesul la sute de site-uri. Bineînțeles, acest lucru vine cu implicații de securitate.

Securitatea este un aspect vital în cadrul protocolului OAuth, deoarece ne asigurăm că datele noastre personale sunt protejate, prevenim accesul neautorizat, evităm atacurile de phishing și Man-in-the-Middle, menținem integritatea și autenticitatea datelor noastre și construim încrederea noastră ca utilizatori.

Mecanismul bazat pe tokenuri de acces ne permite să acordăm accesul aplicațiilor terțe la resursele noastre, cum ar fi profilul sau fotografii, fără a dezvălui parola noastră direct către aceste aplicații. În acest flux, interacțiunea noastră începe prin redirecționarea către serverul de autorizare, unde confirmăm permisiunile solicitate de aplicația terță. După ce acordăm autorizarea, primim un token de acces pe care aplicația terță îl poate utiliza pentru a accesa resursele noastre în numele nostru. Acest flux simplificat și standardizat oferă o modalitate sigură și convenabilă de a gestiona autorizarea și accesul nostru în mediul digital actual.

Entitățile principale în acest flow sunt:

  1. Utilizatorul: persoana ale cărei date vor fi accesate.

  2. Clientul: este aplicația sau serviciul care solicită accesul la resursele protejate. Acesta poate fi, de exemplu, o aplicație web, o aplicație mobilă sau chiar o altă aplicație de server.

  3. Serverul de autorizare: este serverul care autentifică utilizatorul și autorizează accesul clientului la resursele protejate. Acesta verifică identitatea utilizatorului și, după autentificare, emite un token de acces către client.

  4. Serverul resurselor: este serverul care deține resursele protejate la care clientul solicită acces. Acesta verifică validitatea tokenului de acces primit de la client și oferă sau restricționează accesul la resurse, în funcție de autorizare.

  5. Serverul de autorizare si cel al resurselor pot de multe ori fi același server. Resursele utilizatorului se referă la adresa de e-mail, date de contact, poze de profil, locația și altele.

Înainte de toate

Pentru ca utilizatorul să poată oferi acces, acesta trebuie să aibă un cont activ pe platforma furnizorului. Următorul pas e ca aplicația client să fie înregistrată la furnizor cu niște credențiale pereche, client_id și client_secret. Acestea vor fi unice, iar secretul nu va fi distribuit altor aplicații. Unii dintre primii pași care pot crește securitatea e verificarea tuturor aplicațiilor client care vor să se înregistreze pentru a verifica legitimitatea acestora.

Tipuri de autorizare

În cadrul protocolului OAuth, tipurile de tokenuri sunt:

  1. Authorization Code (Cod de autorizare): Acesta este un cod unic generat de serverul de autorizare în urma autentificării cu succes a utilizatorului. Aplicația client primește acest cod și îl folosește pentru a obține un token de acces.

  2. Access token (Token de acces): Este un token care este emis de serverul de autorizare după schimbul codului de autorizare. Acest token este utilizat de către aplicația client pentru a accesa și obține resurse de la serverul resurselor.

  3. Refresh token (Token de reîmprospătare): Acesta este un token opțional care este emis împreună cu token-ul de acces. Refresh tokenul este utilizat pentru a obține un nou token de acces atunci când acesta expiră.

  4. ID token: Acesta este un token specific OAuth 2.0, care este emis de serverul de autorizare și conține informații despre identitatea utilizatorului autentificat.

De asemenea, access token și ID token pot fi folosite împreună, încapsulate într-un token de tipul JWT care conține și identitatea utilizatorului și accesul la diferite resurse.

Ca bună practică, codul de autorizare nu conține date despre utilizator, identificare sau altele, ci este un cod generat. Acesta este transmis la frontend, spre deosebire de codul de acces sau ID care poate rămâne secret.

Altfel, codul ar putea fi furat printr-un atac de tipul Man-In-the-middle

În figura de mai jos este demonstrat un flow OAuth 2.0 obișnuit.

Posibile riscuri

  1. Furtul sesiunii: redirectarea la pagina de autorizare poate fi făcută de către o aplicație străină care copiază identificatorul aplicației client și modifică scope-ul sau redirect_url -ul tocmai în scopul de a primi codul de autorizare și de a accesa resursele. Serverul de autorizare poate valida datele clientului pentru a se asigura că nu generează coduri pentru utilizatori inexistenți.

  2. Validare insuficientă: codul de autorizare trebuie salvat și apoi validat împreună cu credențialele clientului. Un pas în plus e validarea tuturor datelor cu care codul de autorizare a fost generat(redirect_url, scope).

  3. Transmiterea datelor prin canale securizate: pentru a preveni atacuri de tip MITM, comunicarea între entități se face prin HTTPS. De asemenea, requesturile între servere sunt greu de interceptat, în comparație cu cele de frontend.

  4. Expunerea secretelor: Configurarea sau implementarea incorectă a protocolului OAuth poate duce la expunerea accidentală a cheilor de client sau a cheilor secrete de semnare, facilitând accesul neautorizat la resursele protejate.

  5. Autorizare insuficientă: Configurarea greșită a fluxului de autorizare poate duce la acordarea permisiunilor excesive sau insuficiente, creând riscul de acces neautorizat sau restricționarea inadecvată a resurselor protejate.

  6. Probleme de autentificare: Implementarea incorectă a procesului de autentificare în OAuth poate duce la vulnerabilități precum autentificare slabă, atacuri brute sau furt de identitate.

  7. Probleme de stocare a tokenurilor: Stocarea necorespunzătoare a tokenurilor de acces și refresh poate permite accesul neautorizat la acestea, expunând resursele protejate la abuz sau furt.

Integrarea cu JWT

JWT (JSON Web Token) este un standard deschis utilizat pentru transmiterea securizată a informațiilor între părți în format JSON. Este un format compact și autodescriptiv care poate fi utilizat pentru reprezentarea și transmiterea datelor într-un mod sigur și verificabil. Un JWT constă din trei părți separate de puncte: antet (header), corp (payload) și semnătură.

Unul dintre primii pași care pot fi urmați pentru a crește securitatea unei aplicații care folosește JWT e de a avea mai multe chei de criptare. Astfel, chiar dacă una dintre chei devine compromisă, impactul este minim. De exemplu, o aplicație cu 20.000 de utilizatori, care folosește 100 de chei de criptare e mai sigură pentru că, dacă una dintre chei devine publică, sunt afectați numai ~200 de utilizatori. În acest caz, tokenul trebuie să conțină în antet și identificatorul cheii.

Una dintre limitările JWT-ului este că, dacă se transmit prea multe date despre utilizator cum ar fi roluri, permisiuni, resurse disponibile, tokenul poate deveni prea mare și poate ocupa prea mult spațiu. De obicei, acesta se transmite în request headers, care, pentru unele servere, pot avea maxim 4KB. Trebuie să luăm în considerare și faptul că acest token este în format JSON, adică deține și delimitatori, iar când corpul crește, și semnătura crește.

În final, securitatea este un aspect crucial în implementarea și utilizarea protocolului OAuth. Prin mecanismele sale de securitate, cum ar fi utilizarea canalelor securizate, tokenurile de acces, semnăturile digitale și codurile de autorizare unice, OAuth oferă o soluție robustă pentru protejarea autentificării și autorizării în aplicații și servicii. Este important să acordăm atenție implementării corecte a protocoalelor și să urmăm bunele practici de securitate pentru a asigura un nivel adecvat de protecție.

LANSAREA NUMĂRULUI 148

Agile Craftsmanship

joi, 24 Octombrie, ora 18:30

Colors in Projects (București)

Facebook Meetup StreamEvent YouTube

Agile Leadership &
Ways of Working

miercuri, 30 Octombrie, ora 18:00

ING Hubs Romania (Cluj)

Facebook Meetup StreamEvent YouTube

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects