Moderní protokoly SAML, OAuth a OpenID Connect pro autentizaci a autorizaci

K čemu protokoly SAML, OAuth a OIDC využijeme?

Protokoly SAML 2.0, OAuth 2.0 a OpenID Connect (OIDC) jsou otevřené standardy, které můžeme využít k více účelům. SAML spíše v Enterprise prostředí, OIDC a OAuth (někdy se mluví o OAuth2, i když je myšlena kombinace OAuth / OpenID Connect) veřejně.

Základní rozdíl je, že SAML a OpenID Connect slouží k autentizaci, kdežto OAuth k autorizaci. Přitom nejde přímo o ověření uživatele u jeho poskytovatele identity (tam, kde má vytvořený účet). Ale o výměnu důvěryhodných informací o identitě a oprávněních mezi poskytovatelem identity a aplikací třetí strany (aniž by aplikace znala přihlašovací údaje uživatele).

Prakticky jde o situaci, že se do nějaké webové aplikace či cloudové služby můžeme přihlásit pomocí jiného účtu (například účtu Google nebo ve firemním prostředí Microsoft Entra ID). Případně získáme přístup k našim vybraným datům (delegovaný přístup).

Tyto protokoly nejsou žádnou novinkou. SAML 2.0 byl představen v roce 2005, OAuth 2.0 v roce 2012 a OpenID Connect publikován v roce 2014.

Obecné termíny

• Autentizace (Authentication) - ověření identity (kdo uživatel/aplikace je), jde o potvrzení, že osoba je ta, za kterou se vydává
• Autorizace (Authorization) - oprávnění (co smí ověřený uživatel dělat nebo k čemu má přístup), jde o ověření, že osoba má oprávnění provést to, o co se snaží
• Single Sign-On (SSO) - jednorázové přihlášení, umožňuje uživatelům přihlásit se jednou a získat přístup k více aplikacím (bez opětovného zadávání přihlašovacích údajů)

Centrální účet a federovaná identita

Když má uživatel pro každou aplikaci vlastní účet, tak vznikají různé problémy:

• správa mnoha různých přihlašovacích údajů (zjednodušeně hesel)
• složitost změny v mnoha systémech
• každá aplikace má svoje zabezpečení a jinou politiku hesel
• horší přehled a auditovatelnost

Řešením je důvěryhodný centrální poskytovatel identity s bezpečnou autentizací a politikami. Máme jeden účet a jedny přihlašovací údaje (heslo, MFA). Federovaná identita řeší to, že nezávislé aplikace důvěřují centrálnímu poskytovali a přijímají jeho potvrzení o identitě uživatele.

Jednotné přihlášení (SAML, OIDC)

Primární využití je možnost přihlásit se jedním (centrálním, federovaným) účtem k různým aplikacím. Ve firemním prostředí jde například o účty Microsoft Entra ID (používá se SAML nebo OAuth/OIDC). Ve spotřebitelské oblasti může jít o účet Google, Facebook, Apple či Microsoft (používá se OAuth/OIDC).

Můžeme se tak snadno a bezpečně přihlásit do aplikace či služby (webové stránky, typicky se využívá HTTPS protokol) třetí strany. Pokud jsme přihlášeni k našemu účtu (třeba Entra ID či Google), tak se nemusíme znovu přihlašovat (proběhne SSO). Naše heslo (autentizační údaje) se nikdy nedostane k třetí straně. Pro přihlášení do cílové aplikace se používá zabezpečený kód (token), který obsahuje informace o uživateli/identitě (může jít třeba o atributy, skupiny, role).

Tyto protokoly neřeší způsob či metodu autentizace, tedy samotný proces ověření. Slouží k přenosu výsledku autentizace (pomocí assertion/token, že tento uživatel je ověřen), mezi Identity Providerem a aplikací/službou. Vlastní přihlášení uživatele (identity) provádí Identity Provider (třeba Entra ID) a ten určuje způsob ověření (třeba jestli stačí pouze heslo nebo je potřeba MFA).

Aplikace či služba může získat některé údaje z našeho profilu (účtu). Proto bychom měli toto přihlášení používat pouze pro důvěryhodné třetí strany. Často je také možné založit účet v nové aplikaci (u třetí strany), aniž bychom vyplňovali údaje, protože se využijí data z našeho primárního účtu.

V praxi může jít o firemní aplikaci, která se napojí na firemní účty v Entra ID. Nebo nějakou spotřebitelskou aplikaci (e-shop, cloudová služba apod.), která se napojí třeba na Google účet.

Průběh přihlášení

Obecný a zjednodušený průběh přihlášení klienta (Authentication Flow) k aplikaci je následující:

• uživatel přistupuje k aplikaci (Service Provider / Relying Party)
• aplikace nalezne Identity Providera (musí mít jeho konfiguraci) a přesměruje uživatele (prohlížeč) na něj
• pokud uživatel není přihlášen, tak musí provést autentizaci (pomocí hesla, MFA, dle politiky IdP)
• Identity Provider vytvoří potvrzení identity (SAML assertion nebo OIDC token/authorization code)
• Identity Provider přesměruje uživatele zpět do aplikace a předá jí toto potvrzení
• aplikace ověří platnost a podpis potvrzení a dokončí přihlášení uživatele

Přístup k datům nebo API (OAuth)

Nějaké aplikaci či službě můžeme umožnit omezený a autorizovaný přístup k našim datům. Aplikaci nedáváme své přihlašovací údaje, ale delegujeme oprávnění přistoupit k datům u nějakého API. Aplikace přistupuje naším jménem, ale v omezeném (schváleném) rozsahu.

Příkladem je třeba mobilní poštovní aplikace, která přistupuje k emailům a kalendáři uživatele (jako je aplikace Gmail nebo Apple Mail). Aplikace pro elektronické podepisování (jako DocuSign), které povolíme přístup na OneDrive. Či administrátorské nástroje (jako Graph Explorer), které využijí Microsoft Graph API a naším jménem čtou/zapisují data v Entra tenantu.

Komunikace mezi službami (OAuth)

Client Credentials Flow umožňuje autentizovat přímo aplikaci (službu, démona nebo skript) jejími vlastními přihlašovacími údaji (client id a client secret nebo certifikát). Tak získá Access token bez zásahu uživatele a jedná sama za sebe.

V Entra ID se aplikaci přiřazují Application permissions (místo Delegated permissions). Díky tomu má aplikace většinou širší přístup (třeba ke všem poštovním schránkám v tenantu). Proto je potřeba používat opatrně a dobře zabezpečit.

SAML 2.0 (Security Assertion Markup Language)

• primárně řeší (federovanou, mezidoménovou) autentizaci a SSO (neřeší autorizaci, neumožňuje přístup k datům)
• slouží k výměně autentizačních informací mezi účastníky (IdP a SP), přihlašování zaměstnanců do více systémů jedním účtem, hlavně ve firemním prostředí
• mezi předávanými atributy uživatele mohou být i autorizační informace (role, členství ve skupinách), které může využít služba/aplikace
• data jsou formátovaná pomocí XML
• používá SAML Assertion (prohlášení), což je XML dokument obsahující identitu a atributy uživatele (autentizační a autorizační data, například jméno, email, členství ve skupinách), podepisuje se certifikátem IdP (aplikace ověřuje podpis), může být šifrovaný
• pro komunikaci se typicky využívá HTTPS, případně SOAP, kde se přenáší XML dokumenty
• implementace SAML je složitější než OAuth2/OIDC, má větší režii, zpracování XML je náročnější, podpis XML je složitější a náchylnější na chyby a útoky

Role ověřovacího procesu

• Principal - uživatel, který se přihlašuje
• Service Provider (SP) - poskytovatel služby (aplikace), ke které se uživatel přihlašuje
• Identity Provider (IdP) - poskytovatel identity (SAML Assertion), který uživatele autentizuje, jde třeba o Entra ID

Pozn.: Obrázky vytvořila AI podle mého zadání (a vnesla trochu své invence).

OAuth 2.0 (Open Authorization)

• primárně řeší autorizaci (oprávnění, přístup k datům)
• prostřednictvím Access token poskytuje aplikacím třetích stran omezený přístup (na definovaný Scope) k datům uživatele bez sdílení hesla, umožňuje aplikaci delegovaný přístup k API, integrace typu Povolit aplikaci přístup k mému kalendáři
• data jsou formátovaná pomocí JSON, pro token se většinou využívá JSON Web Token (JWT), i když to není předepsáno (obecně jde o opaque string)
• používá Access token (s krátkou platností) pro autorizaci (pro větší bezpečnost může být nejprve vrácen Authorization Code, který poté aplikace vymění za Access token), navíc může být použit Refresh token (s dlouhou dobou platnosti) pro získání nového Access token
• OAuth 2.0 podporuje řadu scénářů (specifikace používá termín Grant type, v praxi se často využívá Flow), základní Implicit Flow nebo bezpečnější Authorization Code Flow, přímo aplikace se autentizuje v Client Credentials Flow
• existuje i Device Authorization Flow pro zařízení s omezeným vstupem (chytré TV, IoT), zařízení zobrazí kód, uživatel ho zadá a přihlásí se na jiném zařízení (mobil, PC), zařízení pak na pozadí obdrží Access token
• důležité je zdůraznit, že uživatel musí být u Authorization Server ověřený (takže může být vyvoláno přihlášení), ale jeho identita nepředává aplikaci (to provádí OpenID Connect)
• pro komunikaci se využívá REST API přes HTTPS

Role ověřovacího procesu

• Resource Owner - uživatel, kterému data/zdroj patří a který uděluje souhlas s přístupem
• Client - aplikace, která žádá o přístup ke zdroji jménem uživatele
• Authorization Server - vydává Access Token po úspěšné autentizaci a udělení souhlasu vlastníkem, třeba Entra ID
• Resource Server - API/služba, ke které se připojujeme a která poskytuje data, třeba Microsoft Graph

OpenID Connect (OIDC)

• řeší autentizaci (a SSO), je postavené na OAuth 2.0 a rozšiřuje ho o identitní vrstvu
• v praxi se často využívá OIDC dohromady s OAuth2 (v jednom procesu), protože aplikace potřebuje přihlásit uživatele a získat přístup k nějakým datům
• účel je podobný jako SAML, slouží k SSO přihlášení uživatelů do více systémů jedním účtem (využívá se na webu, pro cloudové a mobilní aplikace, situace typu Přihlásit se pomocí Google účtu)
• obsahuje funkci získávání souhlasu (consent), kdy uživatel dává souhlas se sdílením osobních údajů (atributů)
• data jsou formátovaná pomocí JSON, pro token se musí použít JSON Web Token (JWT)
• používá ID token s identitou a atributy uživatele (claims), podepisuje se klíčem OpenID Providera (aplikace ověřuje podpis), může být šifrovaný
• pro komunikaci se využívá REST API přes HTTPS

Role ověřovacího procesu

OIDC používá jiné názvy, ale role jsou stejné jako u OAuth.

• End User - uživatel, který se přihlašuje
• Relying Party (RP) - aplikace (služba), ke které se uživatel přihlašuje
• OpenID Provider (OP / IdP) - provádí autentizaci a vydává ID token, třeba Entra ID nebo Keycloak