Pred niekoľkými mesiacmi som implementoval server OpenID Connect na správu prístupu pre stovky našich interných aplikácií. Z nášho vlastného vývoja, vhodného v menšom meradle, sme prešli na všeobecne akceptovaný štandard. Prístup cez centrálnu službu výrazne zjednodušuje monotónne operácie, znižuje náklady na implementáciu autorizácií, umožňuje nájsť veľa hotových riešení a nelámať si hlavu pri vývoji nových. V tomto článku budem hovoriť o tomto prechode a nárazoch, ktoré sa nám podarilo trafiť.
Kedysi dávno... Kde to všetko začalo
Pred niekoľkými rokmi, keď bolo interných aplikácií príliš veľa na manuálne spravovanie, sme napísali aplikáciu na riadenie prístupu v rámci spoločnosti. Išlo o jednoduchú aplikáciu Rails, ktorá sa pripájala k databáze s informáciami o zamestnancoch, kde sa konfiguroval prístup k rôznym funkcionalitám. Zároveň sme spustili prvé SSO, ktoré bolo založené na overovaní tokenov na strane klienta a autorizačného servera, token bol prenášaný v šifrovanej podobe s viacerými parametrami a overený na autorizačnom serveri. Nebola to najpohodlnejšia možnosť, pretože každá interná aplikácia musela opísať značnú vrstvu logiky a databázy zamestnancov boli úplne synchronizované s autorizačným serverom.
Po určitom čase sme sa rozhodli zjednodušiť úlohu centralizovanej autorizácie. SSO bola prevedená na vyvažovačku. S pomocou OpenResty bola do Lua pridaná šablóna, ktorá kontrolovala tokeny, vedela, do ktorej aplikácie žiadosť smeruje a vedela skontrolovať, či tam je prístup. Tento prístup výrazne zjednodušil úlohu riadenia prístupu k interným aplikáciám – už nebolo potrebné popisovať dodatočnú logiku v kóde každej aplikácie. V dôsledku toho sme externe uzavreli prevádzku, ale samotná aplikácia nevedela nič o autorizácii.
Jeden problém však zostal nevyriešený. A čo aplikácie, ktoré vyžadujú informácie o zamestnancoch? Pre autorizačnú službu bolo možné napísať API, ale potom by ste museli pre každú takúto aplikáciu pridať ďalšiu logiku. Okrem toho sme sa chceli zbaviť závislosti na jednej z našich vlastných aplikácií, ktorá je ďalej zameraná na preklad do OpenSource, na našom internom autorizačnom serveri. O tom vám povieme inokedy. Riešením oboch problémov bolo OAuth.
Smerom k všeobecne uznávaným štandardom
OAuth je jasný, všeobecne akceptovaný autorizačný štandard, no keďže samotná jeho funkčnosť nestačí, okamžite sa začalo uvažovať o OpenID Connect (OIDC). Samotné OIDC je treťou implementáciou otvoreného autentifikačného štandardu, ktorý sa vyvinul do nadmnožiny protokolu OAuth 2.0 (Open Authorization Protocol). Toto riešenie rieši problém nedostatku údajov o koncovom užívateľovi a zároveň umožňuje zmeniť poskytovateľa autorizácie.
Nevybrali sme si však konkrétneho poskytovateľa a rozhodli sme sa pridať integráciu s OIDC pre náš existujúci autorizačný server. Toto rozhodnutie podporila skutočnosť, že OIDC je veľmi flexibilný, pokiaľ ide o autorizáciu koncového používateľa. Takto bolo možné implementovať podporu OIDC na vašom aktuálnom autorizačnom serveri.
Naša cesta k implementácii vlastného servera OIDC
1) Uveďte údaje do požadovaného formulára
Pre integráciu OIDC je potrebné priniesť aktuálne užívateľské dáta do štandardne zrozumiteľnej podoby. V OIDC sa to nazýva Nároky. Značky sú v podstate posledné polia v databáze používateľov (meno, email, telefón atď.). Existuje , a všetko, čo nie je zahrnuté v tomto zozname, sa považuje za zvyk. Preto prvým bodom, na ktorý musíte venovať pozornosť, ak si chcete vybrať existujúceho poskytovateľa OIDC, je možnosť pohodlne si prispôsobiť nové známky.
Skupina známok sa spája do nasledujúcej podmnožiny – Rozsah. Počas autorizácie sa nevyžaduje prístup ku konkrétnym značkám, ale k rozsahom, aj keď niektoré zo značiek z rozsahu nie sú potrebné.
2) Implementoval potrebné granty
Ďalšou časťou integrácie OIDC je výber a implementácia typov autorizácií, nazývaných granty. Ďalší scenár interakcie medzi vybratou aplikáciou a autorizačným serverom bude závisieť od zvoleného grantu. Približná schéma výberu správneho grantu je uvedená na obrázku nižšie.
Pre našu prvú žiadosť sme použili najbežnejší grant – Autorizačný kód. Jeho rozdiel od ostatných je v tom, že je trojkrokový, t.j. prechádza dodatočným testovaním. Používateľ najprv požiada o povolenie autorizácie, dostane token Autorizačného kódu, následne si s týmto tokenom, ako s cestovným lístkom, vyžiada prístupový token. Všetky hlavné interakcie tohto scenára autorizácie sú založené na presmerovaniach medzi aplikáciou a autorizačným serverom. Viac o tomto grante si môžete prečítať .
OAuth sa drží konceptu, že prístupové tokeny prijaté po autorizácii by mali byť dočasné a mali by sa meniť v priemere každých 10 minút. Udelenie autorizačného kódu je overenie v troch krokoch prostredníctvom presmerovaní, úprimne povedané, vykonávať takýto krok každých 10 minút nie je pre oko práve najpríjemnejšia úloha. Na vyriešenie tohto problému existuje ďalší grant – Refresh Token, ktorý sme využili aj my. Všetko je tu jednoduchšie. Pri overovaní z iného grantu sa okrem hlavného prístupového tokenu vydáva ešte jeden - Refresh Token, ktorý je možné použiť len raz a jeho životnosť je spravidla výrazne dlhšia. S týmto obnovovacím tokenom, keď skončí TTL (Time to Live) hlavného prístupového tokenu, požiadavka na nový prístupový token príde na koncový bod iného grantu. Použitý obnovovací token sa okamžite vynuluje. Táto kontrola je dvojkroková a môže byť vykonaná na pozadí, bez povšimnutia používateľa.
3) Nakonfigurované výstupné formáty používateľských údajov
Akonáhle sú vybrané granty implementované, autorizácia funguje, za zmienku stojí príjem údajov o koncovom užívateľovi. OIDC má na to samostatný koncový bod, kde si môžete vyžiadať používateľské údaje s vaším aktuálnym prístupovým tokenom a ak je aktuálny. A ak sa užívateľské dáta tak často nemenia, no treba ísť po tie aktuálne veľakrát, môžete prísť na riešenie ako sú JWT tokeny. Tieto tokeny sú tiež podporované štandardom. Samotný token JWT sa skladá z troch častí: hlavičky (informácie o tokene), užitočného obsahu (všetky potrebné údaje) a podpisu (podpis, token je podpísaný serverom a v budúcnosti si môžete skontrolovať zdroj jeho podpisu).
V implementácii OIDC sa token JWT nazýva id_token. Možno oň požiadať spolu s bežným prístupovým tokenom a zostáva už len overiť podpis. Na tento účel má autorizačný server samostatný koncový bod s množstvom verejných kľúčov vo formáte . A keď už o tom hovoríme, stojí za zmienku, že existuje ďalší koncový bod, ktorý je založený na štandarde odráža aktuálnu konfiguráciu servera OIDC. Obsahuje všetky adresy koncových bodov (vrátane adresy kruhu verejných kľúčov používaného na podpisovanie), podporované pečiatky a rozsahy, používané šifrovacie algoritmy, podporované granty atď.
Napríklad na Google:
{
"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"
]
}Pomocou id_token teda môžete preniesť všetky potrebné značky do užitočného obsahu tokenu a nemusíte zakaždým kontaktovať autorizačný server so žiadosťou o údaje používateľa. Nevýhodou tohto prístupu je, že zmeny v používateľských údajoch zo servera neprichádzajú okamžite, ale spolu s novým prístupovým tokenom.
Výsledky implementácie
Po implementácii vlastného OIDC servera a nastavení pripojení k nemu na strane aplikácie sme teda vyriešili problém prenosu užívateľských informácií.
Keďže OIDC je otvorený štandard, máme teraz možnosť vybrať si existujúceho poskytovateľa alebo implementáciu servera. Vyskúšali sme Keycloak, ktorý sa ukázal byť veľmi jednoduchý na konfiguráciu; po nastavení a zmene konfigurácií pripojenia na strane aplikácie je pripravený na použitie. Na strane aplikácie ostáva už len zmeniť konfigurácie pripojenia.
Rozprávanie o existujúcich riešeniach
V rámci našej organizácie sme ako prvý OIDC server zhromaždili vlastnú implementáciu, ktorá bola podľa potreby doplnená. Po podrobnom preskúmaní ďalších hotových riešení môžeme povedať, že ide o kontroverzný bod. Rozhodnutie implementovať vlastný server bolo motivované obavami zo strany poskytovateľov z nedostatku potrebnej funkcionality, ako aj z prítomnosti starého systému, ktorý obsahoval rôzne zákazkové oprávnenia pre niektoré služby a uchovával už pomerne veľa údajov o zamestnancoch. . V hotových implementáciách však existujú vymoženosti pre integráciu. Napríklad Keycloak má vlastný systém správy používateľov a dáta sú uložené priamo v ňom a presun vašich používateľov tam nebude zložitý. Na tento účel má Keycloak API, ktoré vám umožní plne vykonávať všetky potrebné prenosové akcie.
Ďalším príkladom certifikovanej, podľa mňa zaujímavej realizácie je Ory Hydra. Je zaujímavý tým, že sa skladá z rôznych komponentov. Na integráciu budete musieť prepojiť svoju službu správy používateľov s ich autorizačnou službou a podľa potreby ju rozšíriť.
Keycloak a Ory Hydra nie sú jediné hotové riešenia. Najlepšie je vybrať implementáciu certifikovanú OpenID Foundation. Tieto riešenia majú zvyčajne odznak certifikácie OpenID.
Ak si nechcete ponechať server OIDC, nezabudnite na existujúcich platených poskytovateľov. Dnes existuje veľa dobrých možností.
čo ďalej
V blízkej budúcnosti sa chystáme uzavrieť návštevnosť interných služieb iným spôsobom. Plánujeme migrovať naše súčasné SSO na balancer pomocou OpenResty na proxy založené na OAuth. Aj tu je veľa hotových riešení, napr.
Dodatočné materiály
– dobrá služba na kontrolu tokenov JWT
— zoznam certifikovaných implementácií OIDC
Zdroj: hab.com