Slovník pojmů

OpenID Connect

OAuth může udělit přístup k API. OpenID Connect navíc standardizuje, jak ověřit identitu přihlášeného uživatele pomocí ID tokenu.

Stručná definice

Přihlášení uživatele nad autorizačním základem OAuth.

OpenID Connect (OIDC) rozšiřuje OAuth 2.0 o autentizaci a standardní ID token. Klient požádá o scope openid, uživatel se přihlásí u OpenID Providera a klient může po ověření tokenu založit vlastní relaci. Je to běžný základ pro SSO a tlačítko „Přihlásit přes …“.

Úspěšné OIDC přihlášení neznamená, že člověk může spravovat vše v dané aplikaci. OIDC potvrzuje externí identitu; lokální role, organizace a oprávnění k jednotlivým datům zůstávají odpovědností aplikace.

Použití

Kde OIDC řeší skutečný problém identity

Hodí se, když aplikace důvěřuje poskytovateli identity místo vlastního úložiště hesel.

přihlášení zaměstnance do interní aplikace přes firemního identity providera
SSO pro administraci, B2B portál nebo více interních služeb
napojení zákaznické aplikace na externí identitu
získání standardizované identity bez ukládání vlastního hesla
vazba externího uživatele přes stabilní dvojici issuer a subject

Praktický příklad

Přihlášení zaměstnance do interní administrace

Aplikace zná firemního OIDC providera. Z Discovery přečte jeho endpointy, uloží state a nonce, pak zaměstnance přesměruje na login s PKCE. Po návratu porovná state, vymění code a validuje ID token včetně podpisu z JWKS, issueru, audience, expirace a nonce.

Lokální účet dohledá podle issuer + sub. E-mail slouží jako zobrazovaný údaj. Teprve poté aplikace zkontroluje, zda je uživatel členem organizace a má roli pro administraci; ID token se neposílá jako access token do interního API.

Jak funguje

OIDC Code flow s PKCE

Klient musí důvěřovat konkrétnímu issueru a pečlivě ověřit návrat i ID token.

Discovery Aplikace z důvěryhodného issueru získá metadata: authorization endpoint, token endpoint a jwks_uri.
Auth request Pošle response_type=code, scope openid, state, nonce a PKCE challenge na přesně definovanou redirect URI.
Přihlášení OpenID Provider ověří uživatele a vrátí code se stejným state do klientovy relace.
Token exchange Klient ověří state a vymění code spolu s verifierem za token response.
Validace a relace Ověří podpis, issuer, audience, expiraci a nonce ID tokenu, pak vytvoří vlastní session a použije lokální autorizaci.

Důležité pojmy

Identita, tokeny a důvěryhodné klíče

Token lze přečíst, ale jeho text není důvěryhodný bez úplného ověření.

OP a RP

OpenID Provider uživatele autentizuje a vydává ID token. Relying Party je klientská aplikace, která poskytovateli důvěřuje a ověřuje token.

ID token a access token

ID token je statement o přihlášení pro konkrétní klient. Access token je credential pro resource server, například UserInfo endpoint nebo jiné API. Nejsou zaměnitelné.

Iss, sub a aud

Issuer určuje poskytovatele, subject stabilní identitu uživatele a audience klienta, pro kterého byl token vydán. Externí účet je vhodné vázat na issuer + sub, ne na e-mail.

State, nonce a JWKS

State brání podvrženému návratu do relace, nonce váže ID token ke konkrétnímu přihlášení a JWKS poskytuje veřejné klíče pro ověření podpisu a rotaci.

Vztah k podobným pojmům

Identita není automaticky oprávnění k API.

OIDC, OAuth a JWT mají rozdílnou roli, i když se v jednom přihlášení často potkají.

OAuth 2.0: Autorizační základ pro delegovaný přístup. OIDC nad ním standardizuje autentizaci uživatele.
JWT: Častý formát ID tokenu. Dekódování JWT není validace podpisu ani identity.
API: API chrání access token určený pro jeho audience, ne bez dalšího ID token vydaný klientské aplikaci.
RBAC: Lokální role a přístup k organizaci je businessová autorizace; nevzniká automaticky z úspěšného loginu.

Výhody a omezení

Centrální identita bez vlastní implementace hesel.

Přínosy

SSO a standardizovaný login bez vlastního heslového úložiště
možnost využít MFA a politiky identity providera
stabilní vazba identity přes issuer a subject
Discovery a JWKS usnadňují práci s podporovaným providerem

Rizika

použít ID token jako bearer token pro API
důvěřovat tokenu jen proto, že jej lze Base64URL dekódovat
vázat uživatele pouze na měnitelný e-mail
přijímat libovolný issuer nebo klíč z tokenu

Hranice použití

Provider identity je bezpečnostní závislost aplikace.

OIDC dává smysl pro interní systémy a více aplikací se společnou identitou. Je nutné počítat s výpadkem providera, rotací klíčů a s tím, že uživatele nelze bezpečně identifikovat jen zobrazovaným e-mailem.

Aplikace nemá přijmout issuer, JWKS URL ani algoritmus z neověřeného vstupu. Pracuje s předem důvěryhodným issuerem, ověřuje podpis, přesné iss a aud, časové claims a nonce tam, kde byl poslán. ID token ani UserInfo se nelogují jako celek.

Na co myslet

Přihlášení dokončit až po úplné validaci.

Důležitá je vazba všech kroků na jednu autentizační transakci.

Authorization Code s PKCE, state a nonce uložené v původní relaci
přesně registrovaná redirect URI a důvěryhodný issuer
ověření podpisu, iss, aud, exp a nonce ID tokenu
JWKS cache podporující rotaci, ne libovolné URL z hlavičky tokenu
lokální RBAC a organizace odděleně od externí identity

Časté otázky

Co je potřeba skutečně ověřit

Je OpenID Connect totéž co OAuth 2.0?

Ne. OIDC stojí nad OAuth 2.0 a přidává standardizovanou autentizaci uživatele a ID token.

Mohu použít ID token pro volání API?

Obvykle ne. ID token je určený klientské aplikaci; API očekává access token se svou audience a oprávněním.

Jaký je rozdíl mezi state a nonce?

State svazuje browser návrat s původní relací. Nonce váže konkrétní ID token k auth requestu a omezuje replay.

Proč nestačí z tokenu přečíst e-mail?

Bez validace může být token podvržený, cizí nebo expirovaný. E-mail navíc není stabilní primární identita.

Jak řeším integrace s externími službami

Identitu, API přístup a lokální oprávnění držím odděleně.

U integračních aplikací řeším bezpečné tokeny, návratové toky a návaznost externí identity na vlastní pravidla přístupu.

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