Tipul de autorizare Implicit în OAuth 2.0

Tipul de autorizare Implicit, cunoscut și ca metoda „token", a fost conceput în principal pentru aplicațiile client-side în care clientul nu poate stoca în siguranță un secret al clientului. Astfel de aplicații includ aplicații cu o singură pagină (SPA) sau alte aplicații bazate pe browser. În loc să primească un cod de autorizare care trebuie schimbat pentru un token de acces, aplicația primește token-ul de acces direct.

Tipul de autorizare Implicit în LoadFocus

Cum funcționează tipul de autorizare Implicit?

  1. Redirecționare:
  • Aplicația client redirecționează utilizatorul către endpoint-ul de autorizare al serverului de autorizare OAuth 2.0. Această redirecționare include de obicei parametri de interogare precum client_id, response_type (setat la „token" pentru autorizarea Implicit), redirect_uri (unde serverul de autorizare va redirecționa după acordarea/refuzarea accesului) și scope (indicând nivelul de acces solicitat).
  1. Autentificarea utilizatorului:
  • Utilizatorul se autentifică pe serverul de autorizare (dacă nu este deja autentificat) și revizuiește cererea de acces a aplicației client.
  1. Emiterea token-ului de acces:
  • Dacă utilizatorul acordă accesul, serverul de autorizare îl redirecționează înapoi la aplicația client prin redirect_uri furnizat. URI-ul de redirecționare include token-ul de acces (și expirarea acestuia) direct în fragmentul URL-ului.
  1. Accesarea resursei protejate:
  • Aplicația client extrage token-ul de acces din fragmentul URL și îl stochează (de exemplu, în local storage sau o sesiune). Apoi utilizează acest token pentru a face cereri către serverul de resurse (API) în numele utilizatorului.

Cum să configurați tipul de autorizare Implicit?

  1. Înregistrați aplicația: Începeți prin înregistrarea aplicației la furnizorul OAuth 2.0. Veți primi de obicei un client_id după înregistrarea cu succes.

  2. Configurarea URI-ului de redirecționare: Furnizați un redirect_uri în timpul înregistrării. Serverul de autorizare va redirecționa utilizatorii către acest URI după ce decid acordarea sau refuzarea accesului. Asigurați-vă că acest URI este securizat (de obicei utilizând HTTPS) și poate gestiona extragerea token-ului din fragmentul URL.

  3. Inițierea fluxului OAuth: Redirecționați utilizatorii către endpoint-ul de autorizare al serverului de autorizare cu parametrii necesari. Utilizați biblioteci sau SDK-uri potrivite limbajului sau framework-ului aplicației pentru a facilita acest lucru.

  4. Extragerea și stocarea token-ului: Odată redirecționat înapoi, extrageți token-ul de acces din fragmentul URL. Stocați token-ul în siguranță, luând în considerare opțiunile de stocare client-side precum Web Storage (localStorage sau sessionStorage) sau cookie-uri. Asigurați-vă că este protejat de atacurile cross-site scripting (XSS).

  5. Utilizarea token-ului: Atașați token-ul de acces la cererile API făcute către serverul de resurse.

  6. Gestionarea expirării token-ului: Deoarece autorizarea Implicit nu furnizează de obicei token-uri de reîmprospătare, când un token de acces expiră, ar putea fi necesar să inițiați din nou fluxul OAuth pentru a obține unul nou.

Considerații:

  • Securitate: Tipul de autorizare Implicit este considerat mai puțin securizat decât tipul Authorization Code, în special deoarece token-ul de acces este expus în URL. Aceasta ar putea fi un risc în medii unde URL-urile pot fi jurnalizate sau accesate de terți.

  • Fără token de reîmprospătare: De obicei, autorizarea Implicit nu furnizează token-uri de reîmprospătare. Prin urmare, când un token de acces expiră, întregul flux ar putea trebui repetat.

  • Depreciere: Din cauza problemelor de securitate inerente, documentul OAuth 2.0 Security Best Current Practice recomandă evitarea autorizării Implicit în favoarea Authorization Code cu PKCE (Proof Key for Code Exchange) pentru clienții publici, precum SPA-urile.

Concluzie:

Deși tipul de autorizare Implicit oferă un flux mai simplu pentru aplicațiile client-side, problemele sale de securitate au dus la recomandări împotriva utilizării sale în aplicațiile moderne. Dacă construiți aplicații noi, în special SPA-uri, luați în considerare utilizarea autorizării Authorization Code cu PKCE pentru o abordare mai securizată.