A jogosítási kiszolgáló hozzáférési tokent bocsát ki, amelyet az erőforrás-kiszolgáló meghatározott feltételek mellett elfogad. A kliens delegált jogosítás után felhasználó nevében, vagy gép-gép folyamatban önmaga nevében járhat el.
Az OAuth szerepeket és protokollfolyamatokat határoz meg, nem egy tokenformátumot vagy egyetemes jogosultságmodellt. A felhasználói alkalmazásoknál a jelenlegi biztonsági gyakorlat a Proof Key for Code Exchange-hel (PKCE) kiegészített authorization code-folyamatot részesíti előnyben. Az implementációknak a válaszokat a megfelelő klienshez és redirect URI-hez kell kötniük, védeniük kell az authorization code-okat és a refresh tokeneket, és biztosítaniuk kell, hogy a hozzáférési tokeneket csak a kijelölt erőforrás-kiszolgálók fogadják el.
Legfontosabb pontok
AlapszerepekKülönböztessék meg az erőforrás-tulajdonost, a klienst, a jogosítási kiszolgálót és az erőforrás-kiszolgálót; dokumentálják, ha egy komponens egynél több szerepet tölt be.
TokenkontrollokKorlátozzák a célközönséget, a hatókört, az élettartamot és a tárolást; a tokeneket teljesen érvényesítsék; a refresh tokeneket indokolt esetben rotálják vagy vonják vissza; és kerüljék a bearer tokenek URL-ekben vagy naplókban való megjelenítését.
Aktuális folyamatválasztásokKövessék az OAuth biztonsági legjobb gyakorlatát: a kliensek az implicit grantet csak a meghatározott injektálási és szivárgási kockázatok mérséklése mellett használhatják, a resource owner password credentials grantet pedig nem használhatják.
Fontos korlátAz OAuth 2.0 nem határoz meg felhasználó-hitelesítést, és nem bizonyítja, ki használja a hozzáférési tokent. Az érvényes token nem helyettesíti az objektum-, funkció- vagy tranzakciószintű jogosítást az erőforrás-kiszolgálón belül sem.