Autorizační server vydává přístupový token, který server prostředků akceptuje za definovaných podmínek. Klient může jednat za uživatele po delegované autorizaci či za sebe v toku stroj-stroj.
OAuth definuje role a toky protokolu, nikoli jeden formát tokenu či univerzální model oprávnění. U aplikací orientovaných na uživatele současná bezpečnostní praxe preferuje tok autorizačního kódu s Proof Key for Code Exchange (PKCE). Implementace musí vázat odpovědi na správného klienta a redirect URI, chránit autorizační kódy a refresh tokeny a zajistit, že přístupové tokeny jsou akceptovány pouze jejich zamýšlenými servery prostředků.
Klíčové body
Základní roleRozlišujte vlastníka prostředku, klienta, autorizační server a server prostředků; dokumentujte, kdy jedna komponenta vykonává více než jednu roli.
Kontroly tokenůOmezte publikum, rozsah, životnost a úložiště; validujte tokeny kompletně; rotujte či rušte refresh tokeny, kde je vhodné; a vyhýbejte se vystavování bearer tokenů v URL či logách.
Aktuální volby tokůŘiďte se nejlepší současnou praxí bezpečnosti OAuth: klienti by neměli používat implicit grant kromě případů, kde jsou jeho specifikovaná rizika injekce a úniku zmírněna, a nesmějí používat grant přihlašovacích údajů vlastníka prostředku.
Důležité omezeníOAuth 2.0 nedefinuje autentizaci uživatele ani nedokazuje, kdo přístupový token používá. Platný token také nenahrazuje autorizaci na úrovni objektů, funkcí či transakcí uvnitř serveru prostředků.