Un server de autorizare emite un token de acces pe care un server de resurse îl acceptă în condiții definite. Clientul poate acționa pentru un utilizator după autorizare delegată sau în numele său propriu într-un flux mașină-la-mașină.
OAuth definește roluri și fluxuri de protocol, nu un singur format de token sau model universal de permisiuni. Pentru aplicațiile orientate spre utilizator, practica curentă de securitate favorizează fluxul cu cod de autorizare cu Proof Key for Code Exchange (PKCE). Implementările trebuie să lege răspunsurile de clientul și URI-ul de redirecționare corect, să protejeze codurile de autorizare și tokenurile de reîmprospătare și să asigure că tokenurile de acces sunt acceptate doar de serverele de resurse intenționate.
Puncte esențiale
Roluri esențialeDistingeți proprietarul resursei, clientul, serverul de autorizare și serverul de resurse; documentați când o componentă îndeplinește mai mult de un rol.
Controale de tokenuriConstrângeți audiența, domeniul, durata de viață și stocarea; validați tokenurile complet; rotiți sau revocați tokenurile de reîmprospătare acolo unde este potrivit; și evitați expunerea tokenurilor bearer în URL-uri sau jurnale.
Alegeri de flux curenteUrmați cea mai bună practică curentă de securitate OAuth: clienții nu ar trebui să folosească grant-ul implicit decât acolo unde riscurile sale specificate de injecție și scurgere sunt atenuate și nu trebuie să folosească grant-ul cu credențiale de parolă ale proprietarului resursei.
Limitare importantăOAuth 2.0 nu definește autentificarea utilizatorului și nu dovedește cine folosește un token de acces. Un token valid nu înlocuiește nici autorizarea la nivel de obiect, funcție sau tranzacție în interiorul serverului de resurse.