Slovník pojmů

OAuth 2.0

OAuth 2.0 řeší delegovanou autorizaci API, ne automaticky přihlášení uživatele. Standardní identitní vrstvu nad ním poskytuje OpenID Connect.

Stručná definice

Přístup k API bez předávání uživatelského hesla.

OAuth odděluje heslo uživatele od přístupu třetí aplikace. Uživatel nebo služba se ověří u autorizačního serveru, který klientovi vydá omezený access token pro chráněný resource server. Token má mít jasný účel, rozsah a omezenou životnost.

OAuth nestandardizuje jednotný důkaz identity přihlášeného člověka, význam businessových rolí ani podobu API. Access token může být neprůhledná hodnota nebo JWT; klient nemá z formátu tokenu odvozovat pravidla. Přihlášení „přes poskytovatele“ a ID token řeší OpenID Connect.

Použití

Pro delegovaný přístup k chráněným zdrojům

OAuth umožní udělit omezené oprávnění, které lze oddělit od běžného hesla.

propojení e-shopu s marketplace pro čtení objednávek a zápis produktů
interní aplikace s omezeným přístupem k API podle scopes
serverová synchronizace služby se službou přes client credentials
obnova krátkodobého access tokenu pomocí chráněného refresh tokenu
oddělení přístupu uživatele od technického účtu workeru

Praktický příklad

Marketplace přístup pro e-shop

Obchodník propojí e-shop s marketplace. Aplikace jej přesměruje na autorizační server s požadovaným scope orders.read a products.write. Po návratu ověří state a spolu s PKCE verifierem vymění krátkodobý code za token; heslo obchodníka nikdy nevidí ani neukládá.

Noční skladová synchronizace může mít vlastní client credentials, protože nejedná jménem konkrétního uživatele. Tokeny jsou ukládány a rotovány jako citlivé údaje a každý zápis do marketplace řeší vlastní idempotenci pro retry po timeoutu.

Jak funguje

Authorization Code flow s PKCE

Pro přihlášeného uživatele je běžnou volbou authorization code; PKCE chrání odcizený kód před uplatněním jiným klientem.

Příprava Klient vytvoří state pro svázání návratu s relací a code_verifier, z něhož odvodí S256 code_challenge.
Přesměrování Prohlížeč jde na authorization endpoint s client_id, přesně registrovanou redirect URI, scope, state a challenge.
Autorizace Authorization server ověří uživatele a případně získá jeho souhlas s omezeným rozsahem přístupu.
Výměna kódu Klient ověří state a na token endpoint odešle code s verifierem; confidential client se navíc autentizuje jako klient.
Volání zdroje Access token se použije jen vůči správnému resource serveru a s minimálním potřebným scope.

Důležité pojmy

Kdo token vydává a kdo jej používá

Pojmy oddělují identitu, klienta a chráněný zdroj.

Client, resource owner a servery

Client žádá přístup, resource owner jej může udělit, authorization server vydává tokeny a resource server chrání API. Client nemusí být browser.

Scope a token

Scope omezuje hrubý rozsah, například orders.read. Nenahrazuje kontrolu, zda klient smí změnit konkrétní objednávku daného tenantu.

Public a confidential client

SPA a mobilní aplikace nedokážou bezpečně držet dlouhodobý client secret. Serverová aplikace může přihlašovací údaje chránit, ale i pro ni je PKCE vhodná obrana.

Client Credentials

Tok pro službu jednající vlastním jménem. Neobsahuje přihlášení člověka ani jeho souhlas a nesmí se vydávat za uživatelský login.

Vztah k podobným pojmům

OAuth token není synonymem přihlášení ani JWT.

Bezpečná integrace potřebuje správně rozlišit účel tokenu a bezpečnostní hranici.

OpenID Connect: Přidává standardizovanou autentizaci uživatele a ID token nad autorizačním základem OAuth 2.0.
JWT: Formát tokenu, který OAuth může, ale nemusí používat. JWT samo neurčuje scope ani flow.
API: Resource server musí token ověřit a pak rozhodnout o konkrétním přístupu.
Autorizace aplikace: Lokální role či RBAC jsou samostatná businessová pravidla; scope je nenahradí.

Výhody a omezení

Omezený přístup bez sdílení hesla.

Přínosy

třetí aplikace nepotřebuje uživatelské heslo
přístup lze omezit rozsahem, cílem a životností
token nebo refresh token lze odděleně revokovat
jasné rozlišení uživatelského a technického přístupu

Rizika

client secret v prohlížeči či mobilní aplikaci není tajemství
volná redirect URI otevírá cestu k odcizení kódu
neověřený state dovoluje podvržení návratu
tokeny v URL, logu či trace jsou únik přístupových údajů

Hranice použití

Použít flow podle typu klienta a skutečné identity.

Authorization Code s PKCE je vhodný pro aplikaci, která jedná jménem uživatele. Client Credentials naopak reprezentuje službu. Zastaralé flow, která předávají token přes front channel nebo uživatelské heslo aplikaci, nejsou běžnou volbou pro nové integrace.

Redirect URI se registruje a kontroluje přesně, state se ukládá k dané transakci a access či refresh token se nedává do URL ani logu. Resource server stále musí validovat audience, scope a vlastní pravidla nad konkrétními daty.

Na co myslet

Token je citlivý credential, ne pohodlný datový formát.

Bezpečnost spočívá ve flow, validačních pravidlech i provozním zacházení s tokeny.

Authorization Code flow s PKCE S256 a ověřeným state
přesně registrované redirect URI bez volných wildcardů
minimální scopes, omezená životnost a ochrana refresh tokenu
žádné tokeny, code ani secret v URL, logu nebo repozitáři
ověření přístupu k cílovému API i po úspěšném vydání tokenu

Časté otázky

Co OAuth 2.0 není

Je OAuth 2.0 přihlášení?

Ne. OAuth řeší delegovaný přístup k chráněným zdrojům. Pro standardní přihlášení a identitu uživatele slouží OpenID Connect.

Je access token vždy JWT?

Ne. Může být i opaque hodnota. Klient má s tokenem zacházet jako s credentialem, ne spoléhat na jeho formát.

Je Client Credentials vhodné pro uživatelský login?

Ne. Tento tok reprezentuje klienta nebo službu, nikoli uživatele.

Stačí scope orders.write pro každou změnu objednávky?

Ne. Scope omezuje rozsah tokenu; API stále kontroluje konkrétní tenant, objekt a vlastní pravidla autorizace.

Jak řeším API a integrace v praxi

Přístup k externí službě odděluji od běžných hesel.

U integračních rozhraní řeším rozsah přístupu, expiraci a obnovu tokenů, retry i provozní chybové stavy.

Jak pracuji s API a integracemi Nezávazně probrat projekt