Před několika měsíci jsem implementoval server OpenID Connect pro správu přístupu pro stovky našich interních aplikací. Od našeho vlastního vývoje, vhodného v menším měřítku, jsme přešli na obecně uznávaný standard. Přístup přes centrální službu výrazně zjednodušuje monotónní operace, snižuje náklady na implementaci autorizací, umožňuje najít mnoho hotových řešení a nelámat si hlavu při vývoji nových. V tomto článku budu mluvit o tomto přechodu a hrbolech, které se nám podařilo vyplnit.
Kdysi dávno... Jak to všechno začalo
Před pár lety, kdy bylo příliš mnoho interních aplikací pro ruční ovládání, jsme napsali aplikaci pro řízení přístupu v rámci firmy. Jednalo se o jednoduchou aplikaci Rails, která se napojovala na databázi s informacemi o zaměstnancích, kde se konfiguroval přístup k různým funkcionalitám. Zároveň jsme zvedli první SSO, které bylo založeno na ověřování tokenů ze strany klienta a autorizačního serveru, token byl přenášen v šifrované podobě s několika parametry a ověřen na autorizačním serveru. Nebyla to nejpohodlnější možnost, protože každá interní aplikace musela popisovat značnou vrstvu logiky a databáze zaměstnanců byly zcela synchronizovány s autorizačním serverem.
Po nějaké době jsme se rozhodli zjednodušit úkol centralizované autorizace. SSO bylo převedeno na balancer. S pomocí OpenResty byla do Lua přidána šablona, která kontrolovala tokeny, věděla, do které aplikace požadavek směřuje, a uměla kontrolovat, zda tam je přístup. Tento přístup značně zjednodušil úlohu řízení přístupu k interním aplikacím – v kódu každé aplikace již nebylo nutné popisovat další logiku. Tím jsme provoz externě uzavřeli a samotná aplikace o autorizaci nic nevěděla.
Jeden problém však zůstal nevyřešen. A co aplikace, které potřebují informace o zaměstnancích? Bylo možné napsat API pro autorizační službu, ale pak byste museli pro každou takovou aplikaci přidat další logiku. Kromě toho jsme se chtěli zbavit závislosti na jedné z našich samostatně psaných aplikací, orientovaných v budoucnu na překlad do OpenSource, na našem interním autorizačním serveru. O tom si povíme někdy jindy. Řešením obou problémů bylo OAuth.
na běžné standardy
OAuth je srozumitelný, obecně uznávaný autorizační standard, ale protože pouze jeho funkčnost nestačí, začali okamžitě uvažovat o OpenID Connect (OIDC). Samotné OIDC je třetí implementací otevřeného autentizačního standardu, který přešel do doplňku přes protokol OAuth 2.0 (otevřený autorizační protokol). Toto řešení odstraňuje problém nedostatku dat o koncovém uživateli a zároveň umožňuje změnit poskytovatele oprávnění.
Nevybrali jsme si však konkrétního poskytovatele a rozhodli jsme se přidat integraci s OIDC pro náš stávající autorizační server. Ve prospěch tohoto rozhodnutí byla skutečnost, že OIDC je velmi flexibilní z hlediska autorizace koncových uživatelů. Tak bylo možné implementovat podporu OIDC na vašem aktuálním autorizačním serveru.
Náš způsob implementace vlastního serveru OIDC
1) Uveďte data do požadované podoby
Pro integraci OIDC je nutné převést aktuální uživatelská data do podoby srozumitelné standardu. V OIDC se tomu říká Nároky. Nároky jsou v podstatě poslední pole v databázi uživatelů (jméno, e-mail, telefon atd.). Existuje a vše, co není uvedeno v tomto seznamu, je považováno za zvyk. Prvním bodem, kterému je třeba věnovat pozornost, pokud si chcete vybrat stávajícího poskytovatele OIDC, je možnost pohodlného přizpůsobení nových značek.
Skupina puncovních značek je sloučena do následující podmnožiny - Rozsah. Během autorizace není vyžadován přístup ke konkrétním značkám, ale k oborům, i když některé značky z rozsahu nejsou potřeba.
2) Realizoval potřebné dotace
Další částí integrace OIDC je výběr a implementace typů oprávnění, tzv. grantů. Další scénář interakce mezi vybranou aplikací a autorizačním serverem bude záviset na vybraném udělení. Příklad schématu výběru správné dotace je znázorněn na obrázku níže.
Pro naši první žádost jsme použili nejběžnější grant, Autorizační kód. Jeho rozdíl od ostatních je v tom, že je třístupňový, tzn. prochází dalším testováním. Uživatel nejprve zažádá o autorizační povolení, obdrží token - Autorizační kód, následně si tímto tokenem, jakoby s jízdenkou na cestu, vyžádá přístupový token. Veškerá hlavní interakce tohoto autorizačního skriptu je založena na přesměrování mezi aplikací a autorizačním serverem. Více o tomto grantu si můžete přečíst .
OAuth se drží konceptu, že přístupové tokeny získané po autorizaci by měly být dočasné a měly by se měnit nejlépe každých 10 minut v průměru. Udělení autorizačního kódu je třífázové ověření prostřednictvím přesměrování, každých 10 minut takový krok udělat, upřímně řečeno, není pro oči nejpříjemnější úkol. K vyřešení tohoto problému existuje další grant – Refresh Token, který jsme použili i u nás. Tady je všechno jednodušší. Při ověřování z jiného grantu je kromě hlavního přístupového tokenu vydán ještě jeden - Refresh Token, který lze použít pouze jednou a jeho životnost je obvykle mnohem delší. S tímto obnovovacím tokenem, když skončí TTL (Time to Live) hlavního přístupového tokenu, požadavek na nový přístupový token přijde na koncový bod jiného udělení. Použitý obnovovací token se okamžitě vynuluje. Tato kontrola je dvoukroková a lze ji provádět na pozadí, pro uživatele nepostřehnutelně.
3) Nastavte vlastní výstupní formáty dat
Po implementaci vybraných grantů funguje autorizace, za zmínku stojí získávání dat o koncovém uživateli. OIDC má pro to samostatný koncový bod, kde si můžete vyžádat uživatelská data s vaším aktuálním přístupovým tokenem a pokud je aktuální. A pokud se data uživatele tak často nemění a potřebujete se mnohokrát řídit těmi aktuálními, můžete přijít na takové řešení, jako jsou JWT tokeny. Tyto tokeny jsou také podporovány standardem. Samotný JWT token se skládá ze tří částí: hlavičky (informace o tokenu), payloadu (případné potřebné údaje) a podpisu (podpis, token je podepsán serverem a později můžete zkontrolovat zdroj jeho podpisu).
V implementaci OIDC se token JWT nazývá id_token. Lze o něj požádat spolu s běžným přístupovým tokenem a zbývá jen ověřit podpis. Autorizační server má pro to samostatný koncový bod se skupinou veřejných klíčů ve formátu . A když už jsme u toho, stojí za zmínku, že existuje další koncový bod, který vychází ze standardu odráží aktuální konfiguraci serveru OIDC. Obsahuje všechny adresy koncových bodů (včetně adresy svazku veřejných klíčů používaného pro podepisování), podporované značky a rozsahy, použité šifrovací algoritmy, podporované granty atd.
Například na Googlu:
{
"issuer": "https://accounts.google.com",
"authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
"device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
"revocation_endpoint": "https://oauth2.googleapis.com/revoke",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
"response_types_supported": [
"code",
"token",
"id_token",
"code token",
"code id_token",
"token id_token",
"code token id_token",
"none"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"scopes_supported": [
"openid",
"email",
"profile"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"client_secret_basic"
],
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"family_name",
"given_name",
"iat",
"iss",
"locale",
"name",
"picture",
"sub"
],
"code_challenge_methods_supported": [
"plain",
"S256"
],
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}Pomocí id_token tedy můžete přenést všechny potřebné puncovní značky do datové části tokenu a nemusíte pokaždé kontaktovat autorizační server s žádostí o uživatelská data. Nevýhodou tohoto přístupu je, že změna uživatelských dat ze serveru nepřichází okamžitě, ale spolu s novým přístupovým tokenem.
Výsledky implementace
Po implementaci vlastního OIDC serveru a konfiguraci připojení k němu na straně aplikace jsme tedy vyřešili problém přenosu informací o uživatelích.
Vzhledem k tomu, že OIDC je otevřený standard, máme možnost vybrat si stávajícího poskytovatele nebo implementaci serveru. Vyzkoušeli jsme Keycloak, který se ukázal jako velmi pohodlný na konfiguraci, po nastavení a změně konfigurací připojení na straně aplikace je připraven. Na straně aplikace zbývá pouze změnit konfigurace připojení.
Povídání o existujících řešeních
V rámci naší organizace jsme jako první OIDC server sestavili vlastní implementaci, která byla dle potřeby doplňována. Po podrobném přezkoumání dalších hotových řešení můžeme říci, že se jedná o diskutabilní bod. Ve prospěch rozhodnutí implementovat vlastní server se objevily obavy na straně poskytovatelů z absence potřebné funkcionality, stejně jako přítomnost starého systému, ve kterém byla různá vlastní oprávnění pro některé služby a poměrně hodně údajů o zaměstnancích již bylo uloženo. V hotových implementacích však existují vymoženosti pro integraci. Například Keycloak má vlastní systém správy uživatelů a data se ukládají přímo v něm a nebude těžké tam vaše uživatele předběhnout. K tomu má Keycloak API, které vám umožní plně provádět všechny potřebné přenosové akce.
Dalším příkladem certifikované, dle mého názoru zajímavého provedení je Ory Hydra. Je zajímavý, protože se skládá z různých komponent. Chcete-li integrovat, budete muset propojit službu správy uživatelů s jejich autorizační službou a podle potřeby ji rozšířit.
Keycloak a Ory Hydra nejsou jedinými běžně dostupnými řešeními. Nejlepší je zvolit implementaci certifikovanou OpenID Foundation. Tato řešení mají obvykle odznak certifikace OpenID.
Pokud si nechcete ponechat svůj OIDC server, nezapomeňte také na stávající placené poskytovatele. Dnes existuje mnoho dobrých možností.
Co je další
V blízké budoucnosti se chystáme uzavřít provoz pro interní služby jiným způsobem. Plánujeme převést naše současné jednotné přihlašování na balanceru pomocí OpenResty na proxy založené na OAuth. Zde již existuje mnoho hotových řešení, například:
Další materiály
– dobrá služba pro ověřování tokenů JWT
- seznam certifikovaných implementací OIDC
Zdroj: www.habr.com