In pear moanne lyn implementearre ik in OpenID Connect-tsjinner om tagong te behearjen foar hûnderten fan ús ynterne applikaasjes. Fan ús eigen ûntjouwings, handich op lytsere skaal, binne wy oergien nei in algemien akseptearre standert. Tagong fia de sintrale tsjinst simplifies gâns ientoanige operaasjes, ferleget de kosten fan útfiering autorisaasjes, kinne jo fine in protte klearmakke oplossingen en net rack dyn harsens by it ûntwikkeljen fan nije. Yn dit artikel sil ik prate oer dizze oergong en de bulten dy't wy slagge om te foljen.
Lang lyn... Hoe't it allegear begûn
In pear jier lyn, doe't d'r tefolle ynterne applikaasjes wiene foar manuele kontrôle, hawwe wy in applikaasje skreaun om tagong te kontrolearjen binnen it bedriuw. It wie in ienfâldige Rails-applikaasje dy't ferbûn wie mei in databank mei ynformaasje oer meiwurkers, wêr't tagong ta ferskate funksjonaliteit konfigureare waard. Tagelyk hawwe wy de earste SSO opwekke, dy't basearre wie op 'e ferifikaasje fan tokens fan' e kant fan 'e kliïnt en de autorisaasjetsjinner, it token waard yn fersifere foarm mei ferskate parameters ferstjoerd en ferifiearre op' e autorisaasjetsjinner. Dit wie net de meast handige opsje, om't elke ynterne applikaasje in flinke laach logika moast beskriuwe, en de wurknimmerdatabases wiene folslein syngronisearre mei de autorisaasjetsjinner.
Nei in skoft hawwe wy besletten om de taak fan sintrale autorisaasje te ferienfâldigjen. SSO waard oerdroegen oan de balancer. Mei help fan OpenResty waard in sjabloan tafoege oan Lua dy't tokens kontrolearre, wist hokker applikaasje it fersyk gie, en koe kontrolearje oft d'r tagong wie. Dizze oanpak sterk ferienfâldige de taak fan it kontrolearjen fan tagong ta ynterne applikaasjes - yn 'e koade fan elke applikaasje wie it net mear nedich om ekstra logika te beskriuwen. As gefolch hawwe wy it ferkear ekstern sluten, en de applikaasje sels wist neat oer autorisaasje.
Ien probleem bleau lykwols net oplost. Hoe sit it mei applikaasjes dy't ynformaasje nedich binne oer meiwurkers? It wie mooglik om in API te skriuwen foar de autorisaasjetsjinst, mar dan moatte jo ekstra logika tafoegje foar elke sa'n applikaasje. Derneist woene wy de ôfhinklikens fan ien fan ús selsskreaune applikaasjes, oriïntearre yn 'e takomst foar oersetting yn OpenSource, op ús ynterne autorisaasjetsjinner kwytreitsje. Wy prate der in oare kear oer. De oplossing foar beide problemen wie OAuth.
oan mienskiplike noarmen
OAuth is in begryplike, algemien akseptearre autorisaasjestandert, mar om't allinich de funksjonaliteit net genôch is, begon se fuortendaliks OpenID Connect (OIDC) te beskôgjen. OIDC sels is de tredde ymplemintaasje fan 'e iepen autentikaasjestandert, dy't streamde yn in add-on oer it OAuth 2.0-protokol (in iepen autorisaasjeprotokol). Dizze oplossing slút it probleem fan it gebrek oan gegevens oer de ein brûker, en makket it ek mooglik om te feroarjen de autorisaasje provider.
Wy hawwe lykwols gjin spesifike provider keazen en besletten om yntegraasje mei OIDC ta te foegjen foar ús besteande autorisaasjetsjinner. Yn it foardiel fan dit beslút wie it feit dat OIDC tige fleksibel is yn termen fan autorisaasje foar einbrûkers. Sa wie it mooglik om OIDC-stipe te ymplementearjen op jo hjoeddeistige autorisaasjetsjinner.
Us manier om ús eigen OIDC-tsjinner te ymplementearjen
1) De gegevens brocht nei de winske foarm
Om OIDC te yntegrearjen, is it nedich om de hjoeddeistige brûkersgegevens yn in foarm te bringen dy't begryplik is troch de standert. Yn OIDC wurdt dit Claims neamd. Oanspraken binne yn wêzen lêste fjilden yn 'e brûkersdatabase (namme, e-post, telefoan, ensfh.). Bestiet , en alles dat net opnommen is yn dizze list wurdt beskôge as oanpast. Dêrom is it earste punt dat jo moatte betelje omtinken oan as jo wolle kieze in besteande OIDC provider is de mooglikheid fan handige oanpassing fan nije merken.
De groep skaaimerken wurdt kombinearre yn de folgjende subset - Scope. Tidens autorisaasje wurdt tagong frege net ta spesifike merken, mar ta berikken, sels as guon fan 'e merken út' e omfang net nedich binne.
2) De nedige subsydzjes útfierd
It folgjende diel fan OIDC-yntegraasje is de seleksje en ymplemintaasje fan autorisaasjetypen, de saneamde subsydzjes. It fierdere senario fan ynteraksje tusken de selektearre applikaasje en de autorisaasjetsjinner sil ôfhingje fan de selektearre subsydzje. In foarbyldskema foar it kiezen fan it juste subsydzje wurdt werjûn yn 'e figuer hjirûnder.
Foar ús earste oanfraach brûkten wy de meast foarkommende subsydzje, de autorisaasjekoade. It ferskil fan oaren is dat it is in trije-stap, d.w.s. ûndergiet ekstra testen. Earst makket de brûker in fersyk foar autorisaasje tastimming, krijt in token - Autorisaasjekoade, dan mei dizze token, as mei in kaartsje foar reis, freget in tagongstoken. Alle haadynteraksje fan dit autorisaasjeskript is basearre op trochferwizings tusken de applikaasje en de autorisaasjetsjinner. Jo kinne mear lêze oer dizze subsydzje .
OAuth hâldt him oan it konsept dat de tagongstekens krigen nei autorisaasje tydlik moatte wêze en yn trochsneed by foarkar elke 10 minuten feroarje. De subsydzje foar autorisaasjekoade is in ferifikaasje fan trije stappen troch trochferwizings, elke 10 minuten om sa'n stap te draaien, earlik sein, is net de noflikste taak foar de eagen. Om dit probleem op te lossen is d'r in oare subsydzje - Refresh Token, dy't wy ek yn ús lân brûkten. Alles is hjir makliker. Tidens ferifikaasje fan in oare subsydzje, neist it haad tagongstoken, wurdt in oare útjûn - Refresh Token, dy't mar ien kear kin wurde brûkt en syn libben is normaal folle langer. Mei dizze Refresh Token, as de TTL (Tiid om te libjen) fan 'e wichtichste tagongstoken einiget, sil it fersyk foar in nij tagongstoken komme oan it einpunt fan in oare subsydzje. De brûkte Refresh Token wurdt fuortendaliks weromset nei nul. Dizze kontrôle is twa-stap en kin wurde útfierd op 'e eftergrûn, ûnmerkber foar de brûker.
3) Stel oanpaste gegevensútfierformaten yn
Nei't de selekteare subsydzjes binne ymplementearre, wurket autorisaasje, it is it neamen wurdich om gegevens oer de einbrûker te krijen. OIDC hat in apart einpunt foar dit, dêr't jo kinne oanfreegje brûkersgegevens mei jo hjoeddeistige tagong token en as it is aktueel. En as de gegevens fan 'e brûker net sa faak feroarje, en jo moatte de aktuele in protte kearen folgje, kinne jo komme ta sa'n oplossing as JWT-tokens. Dizze tokens wurde ek stipe troch de standert. It JWT-token sels bestiet út trije dielen: koptekst (ynformaasje oer it token), payload (elke nedige gegevens) en hantekening (hântekening, it token wurdt tekene troch de tsjinner en jo kinne letter de boarne fan syn hantekening kontrolearje).
Yn 'e OIDC-ymplemintaasje wurdt it JWT-token id_token neamd. It kin wurde oanfrege tegearre mei in normaal tagongstoken en alles wat oerbliuwt is de hantekening te ferifiearjen. De autorisaasjetsjinner hat dêrfoar in apart einpunt mei in boskje iepenbiere kaaien yn it formaat . En it is it wurdich om te neamen dat d'r in oar einpunt is, dat basearre is op 'e standert wjerspegelet de hjoeddeistige konfiguraasje fan 'e OIDC-tsjinner. It befettet alle einpuntadressen (ynklusyf it adres fan 'e iepenbiere kaairing dy't brûkt wurdt foar ûndertekening), stipe merken en berik, brûkte fersiferingsalgoritmen, stipe subsydzjes, ensfh.
Bygelyks op 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"
]
}Sa kinne jo, mei help fan id_token, alle nedige skaaimerken oerdrage oan 'e lading fan' e token en net elke kear kontakt opnimme mei de autorisaasjetsjinner om brûkersgegevens oan te freegjen. It neidiel fan dizze oanpak is dat de feroaring yn brûkersgegevens fan 'e tsjinner net direkt komt, mar tegearre mei in nije tagongstoken.
Implementaasje resultaten
Dat, nei it ymplementearjen fan ús eigen OIDC-tsjinner en it konfigurearjen fan ferbiningen dêrmei oan 'e applikaasjekant, hawwe wy it probleem oplost fan it oerdragen fan ynformaasje oer brûkers.
Om't OIDC in iepen standert is, hawwe wy de opsje om in besteande provider as tsjinner ymplemintaasje te kiezen. Wy besochten Keycloak, dy't tige handich die bliken te konfigurearjen, nei it ynstellen en feroarjen fan ferbiningskonfiguraasjes oan 'e applikaasjekant, is it klear om te gean. Oan 'e kant fan' e applikaasje bliuwt alles oer de ferbiningskonfiguraasjes te feroarjen.
Prate oer besteande oplossingen
Binnen ús organisaasje, as de earste OIDC-tsjinner, hawwe wy ús eigen ymplemintaasje gearstald, dy't as nedich waard oanfolle. Nei in detaillearre resinsje fan oare klearmakke oplossingen, kinne wy sizze dat dit is in moot punt. Yn it foardiel fan it beslút om har eigen server út te fieren, wiene d'r soargen fan 'e kant fan providers by it ûntbrekken fan' e nedige funksjonaliteit, lykas de oanwêzigens fan in âld systeem wêryn d'r ferskate oanpaste autorisaasjes wiene foar guon tsjinsten en in protte fan gegevens oer meiwurkers wie al opslein. Yn klearmakke ymplemintaasjes binne d'r lykwols gemak foar yntegraasje. Bygelyks, Keycloak hat in eigen brûkersbehearsysteem en gegevens wurde direkt yn it opslein, en it sil net dreech wêze om jo brûkers dêr yn te nimmen. Om dit te dwaan, hat Keycloak in API wêrmei jo alle nedige oerdrachtaksjes folslein kinne útfiere.
In oar foarbyld fan in sertifisearre, nijsgjirrige, nei myn miening, ymplemintaasje is Ory Hydra. It is nijsgjirrich om't it bestiet út ferskate komponinten. Om te yntegrearjen, moatte jo jo tsjinst foar brûkersbehear keppelje oan har autorisaasjetsjinst en útwreidzje as nedich.
Keycloak en Ory Hydra binne net de ienige oplossingen út 'e planke. It is it bêste om in ymplemintaasje te kiezen sertifisearre troch de OpenID Foundation. Dizze oplossingen hawwe normaal in OpenID-sertifikaasjebadge.
Ferjit ek besteande betelle providers net as jo jo OIDC-tsjinner net wolle hâlde. Hjoed binne d'r in protte goede opsjes.
Wat is hjirnei
Yn de heine takomst sille wy it ferkear op in oare manier slute foar ynterne tsjinsten. Wy binne fan plan om ús hjoeddeistige SSO oer te bringen op 'e balancer mei OpenResty nei in proxy basearre op OAuth. D'r binne hjir al in protte klearebare oplossingen, bygelyks:
Oanfoljende materialen
- goede tsjinst foar it falidearjen fan JWT-tokens
- list fan sertifisearre OAIDC-ymplementaasjes
Boarne: www.habr.com