Virun e puer Méint hunn ech en OpenID Connect Server implementéiert fir Zougang fir Honnerte vun eisen internen Uwendungen ze verwalten. Vun eisen eegenen Entwécklungen, bequem op enger méi klenger Skala, si mir op en allgemeng akzeptéierte Standard geplënnert. Zougang duerch den zentrale Service vereinfacht immens monoton Operatiounen, reduzéiert d'Käschte vun der Ëmsetzung vun Autorisatiounen, erlaabt Iech vill fäerdeg Léisungen ze fannen an net Äert Gehir z'entwéckelen wann Dir nei entwéckelt. An dësem Artikel wäert ech iwwer dësen Iwwergang schwätzen an d'Bumpen déi mir et fäerdeg bruecht hunn ze fëllen.
Viru laanger Zäit ... Wéi et alles ugefaang huet
Virun e puer Joer, wéi et ze vill intern Uwendunge fir manuell Kontroll waren, hu mir eng Applikatioun geschriwwen fir den Zougang bannent der Firma ze kontrolléieren. Et war eng einfach Rails Applikatioun déi mat enger Datebank mat Informatioun iwwer Mataarbechter verbonnen ass, wou Zougang zu verschidde Funktionalitéit konfiguréiert gouf. Zur selwechter Zäit hu mir den éischten SSO erhéicht, deen op der Verifizéierung vun Tokens vun der Säit vum Client an dem Autorisatiounsserver baséiert, de Token gouf a verschlësselte Form mat verschiddene Parameteren iwwerdroen an op den Autorisatiounsserver verifizéiert. Dëst war net déi bequemste Optioun, well all intern Applikatioun huet eng bedeitend Schicht vu Logik ze beschreiwen, an d'Employé Datenbanken komplett mat der Autorisatioun Server synchroniséiert.
No enger Zäit hu mir decidéiert d'Aufgab vun der zentraliséierter Autorisatioun ze vereinfachen. SSO gouf un de Balancer transferéiert. Mat der Hëllef vun OpenResty gouf eng Schabloun op Lua bäigefüügt, déi Tokens gepréift huet, wousst op wéi eng Applikatioun d'Ufro géif goen, a konnt iwwerpréiwen ob et Zougang do ass. Dës Approche vereinfacht immens d'Aufgab fir den Zougang zu internen Uwendungen ze kontrolléieren - am Code vun all Applikatioun war et net méi néideg fir zousätzlech Logik ze beschreiwen. Als Resultat hu mir de Verkéier extern zougemaach, an d'Applikatioun selwer wousst näischt iwwer Autorisatioun.
Ee Problem blouf awer ongeléist. Wat iwwer Uwendungen déi Informatioun iwwer Mataarbechter brauchen? Et war méiglech eng API fir den Autorisatiounsservice ze schreiwen, awer da musst Dir zousätzlech Logik fir all esou Applikatioun addéieren. Zousätzlech wollte mir d'Ofhängegkeet vun enger vun eise selbstgeschriwwenen Applikatiounen, déi spéider an OpenSource iwwersat ginn, op eisem internen Autorisatiounsserver lass ginn. Mir wäerten eng aner Kéier doriwwer schwätzen. D'Léisung fir béid Problemer war OAuth.
zu gemeinsame Standarden
OAuth ass e verständlechen, allgemeng akzeptéierten Autorisatiounsstandard, awer well nëmmen seng Funktionalitéit net genuch ass, hunn se direkt ugefaang OpenID Connect (OIDC) ze berücksichtegen. OIDC selwer ass déi drëtt Implementatioun vum oppenen Authentifikatiounsstandard, deen an en Add-on iwwer den OAuth 2.0 Protokoll (en oppene Autorisatiounsprotokoll) gefloss ass. Dës Léisung mécht de Problem vum Mangel un Daten iwwer den Endbenotzer zou, a mécht et och méiglech den Autorisatiounsprovider z'änneren.
Wéi och ëmmer, mir hunn net e spezifesche Provider gewielt an hunn decidéiert Integratioun mat OIDC fir eisen existente Autorisatiounsserver ze addéieren. Zugonschte vun dëser Entscheedung war d'Tatsaach datt OIDC ganz flexibel ass wat d'Endbenotzer Autorisatioun ugeet. Sou war et méiglech OIDC Support op Ärem aktuellen Autorisatiounsserver ëmzesetzen.
Eise Wee fir eisen eegenen OIDC Server ëmzesetzen
1) D'Donnéeën op déi gewënscht Form bruecht
Fir OIDC z'integréieren, ass et néideg déi aktuell Benotzerdaten an eng Form ze bréngen, déi vum Standard verständlech ass. Am OIDC gëtt dëst Claims genannt. Fuerderunge si wesentlech endgülteg Felder an der Benotzerdatenbank (Numm, E-Mail, Telefon, etc.). Et gëtt , an alles wat net an dëser Lëscht abegraff ass gëtt als Custom ugesinn. Dofir ass den éischte Punkt, op deen Dir oppassen musst wann Dir en existente OIDC-Provider wëllt wielen, ass d'Méiglechkeet vu praktescher Personnalisatioun vun neie Marken.
D'Grupp vun Markenzeechen ass an de folgenden Ënnerdeel kombinéiert - Ëmfang. Wärend der Autorisatioun gëtt Zougang net zu spezifesche Marken ugefrot, mee zu Scope, och wann e puer vun de Marken aus dem Ëmfang net gebraucht ginn.
2) Déi néideg Subventiounen ëmgesat
Den nächsten Deel vun der OIDC Integratioun ass d'Auswiel an d'Ëmsetzung vun Autorisatiounstypen, déi sougenannte Subventiounen. De weideren Szenario vun der Interaktioun tëscht der gewielter Applikatioun an dem Autorisatiounsserver hänkt vun der gewielter Subventioun of. En exemplaresche Schema fir de richtege Subventioun ze wielen ass an der Figur hei ënnen gewisen.
Fir eis éischt Demande hu mir déi meescht üblech Subventioun benotzt, den Autorisatiounscode. Säin Ënnerscheed vun aneren ass datt et en Dräi-Schrëtt ass, d.h. ass amgaang zousätzlech Tester. Éischt, mécht de Benotzer eng Ufro fir Autorisatioun Erlaabnis, kritt en Token - Autorisatioun Code, dann mat dësem Token, wéi wann mat engem Ticket fir Rees, freet en Zougang Token. All d'Haaptinteraktioun vun dësem Autorisatiounsskript baséiert op Viruleedungen tëscht der Applikatioun an dem Autorisatiounsserver. Dir kënnt méi iwwer dëse Subventioun liesen .
OAuth hält sech un d'Konzept datt Zougangstoken, déi no der Autorisatioun kritt goufen, temporär solle sinn a sollten am Duerchschnëtt all 10 Minutten änneren. Den Autorisatiounscode Subventioun ass eng dräi-Schrëtt Verifizéierung duerch Viruleedungen, all 10 Minutten fir sou e Schrëtt ze maachen, éierlech gesot, ass net déi agreabelst Aufgab fir d'Aen. Fir dëse Problem ze léisen, gëtt et eng aner Subventioun - Refresh Token, déi mir och an eisem Land benotzt hunn. Hei ass alles méi einfach. Wärend der Verifizéierung vun enger anerer Subventioun, nieft dem Haaptzougangstoken, gëtt en aneren ausgestallt - Refresh Token, deen nëmmen eemol benotzt ka ginn a seng Liewensdauer normalerweis vill méi laang ass. Mat dësem Refresh Token, wann den TTL (Time to Live) vum Haaptzougang Token endet, kënnt d'Ufro fir en neien Zougang Token un den Endpunkt vun engem anere Subventioun. De benotzte Refresh Token gëtt direkt op Null zréckgesat. Dëse Scheck ass zwee-Schrëtt a kann am Hannergrond duerchgefouert ginn, onmerkbar fir de Benotzer.
3) Setzt personaliséiert Datenausgangsformater op
Nodeems déi gewielte Subventiounen ëmgesat sinn, funktionnéiert d'Autorisatioun, et ass derwäert ze ernimmen datt d'Donnéeën iwwer den Endbenotzer kréien. OIDC huet e separaten Endpunkt fir dëst, wou Dir Benotzerdaten mat Ärem aktuellen Zougangstoken ufroe kënnt a wann et aktuell ass. A wann d'Donnéeën vum Benotzer net sou dacks änneren, an Dir musst déi aktuell oft verfollegen, kënnt Dir zu enger Léisung wéi JWT Tokens kommen. Dës Tokens ginn och vum Standard ënnerstëtzt. De JWT Token selwer besteet aus dräi Deeler: Header (Informatioun iwwer den Token), Notzlaascht (all néideg Donnéeën) an Ënnerschrëft (Ënnerschrëft, den Token gëtt vum Server ënnerschriwwen an Dir kënnt spéider d'Quell vu senger Ënnerschrëft kontrolléieren).
An der OIDC Implementatioun gëtt de JWT Token id_token genannt. Et kann zesumme mat engem normalen Zougangstoken ugefrot ginn an alles wat lénks ass ass d'Ënnerschrëft z'iwwerpréiwen. Den Autorisatiounsserver huet e separaten Endpunkt fir dëst mat enger Rëtsch ëffentleche Schlësselen am Format . A schwätzt vun dësem, ass et derwäert ze ernimmen datt et en aneren Endpunkt ass, deen, baséiert op dem Standard reflektéiert déi aktuell Konfiguratioun vum OIDC Server. Et enthält all Endpunktadressen (inklusiv d'Adress vum ëffentleche Schlësselring benotzt fir d'Ënnerschreiwe), ënnerstëtzt Marken an Ëmfang, benotzt Verschlësselungsalgorithmen, ënnerstëtzt Subventiounen, etc.
Zum Beispill 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"
]
}Also, mat id_token, kënnt Dir all déi néideg Marken op d'Notzlaascht vum Token transferéieren an net all Kéier den Autorisatiounsserver kontaktéieren fir Benotzerdaten ze froen. Den Nodeel vun dëser Approche ass datt d'Ännerung vun de Benotzerdaten vum Server net direkt kënnt, awer zesumme mat engem neien Zougangstoken.
Ëmsetzung Resultater
Also, nodeems mir eisen eegenen OIDC Server implementéiert hunn an d'Verbindungen dozou op der Applikatioun Säit konfiguréieren, hu mir de Problem vun der Iwwerdroung vun Informatioun iwwer Benotzer geléist.
Zënter OIDC en oppene Standard ass, hu mir d'Méiglechkeet en existente Provider oder Serverimplementatioun ze wielen. Mir hu probéiert Keycloak, wat sech als ganz bequem ze konfiguréieren erausgestallt huet, nodeems Dir d'Verbindungskonfiguratioun op der Applikatiounssäit opgeriicht an geännert huet, ass et prett ze goen. Op der Applikatioun Säit ass alles wat bleift ass d'Verbindungskonfiguratiounen z'änneren.
Schwätzen iwwer bestehend Léisungen
Bannent eiser Organisatioun, als éischten OIDC Server, hu mir eis eegen Implementatioun zesummegesat, déi wéi néideg ergänzt gouf. No enger detailléierter Iwwerpréiwung vun anere fäerdege Léisungen, kënne mir soen datt dëst e Moot Punkt ass. Zugonschte vun der Entscheedung hiren eegene Server ëmzesetzen, goufen et Bedenken op der Säit vun de Fournisseuren an der Verontreiung vun der néideger Funktionalitéit, wéi och d'Präsenz vun engem ale System, an deem verschidde personaliséiert Autorisatioune fir e puer Servicer waren a ganz vill vun Donnéeën iwwer Mataarbechter scho gespäichert. Wéi och ëmmer, a fäerdege Implementatiounen ginn et Komfort fir Integratioun. Zum Beispill, Keycloak huet säin eegene Benotzerverwaltungssystem an d'Donnéeën ginn direkt dran gespäichert, an et wäert net schwéier sinn Är Benotzer do z'iwwerhuelen. Fir dëst ze maachen, huet Keycloak eng API déi Iech erlaabt all déi néideg Transferaktiounen voll auszeféieren.
En anert Beispill vun enger zertifizéierter, interessanter, menger Meenung no, Ëmsetzung ass Ory Hydra. Et ass interessant well et aus verschiddene Komponente besteet. Fir z'integréieren, musst Dir Äre Benotzerverwaltungsservice un hiren Autorisatiounsservice verbannen a verlängeren wéi néideg.
Keycloak an Ory Hydra sinn net déi eenzeg off-the-shelf Léisungen. Et ass am beschten eng Implementatioun ze wielen déi vun der OpenID Foundation zertifizéiert ass. Dës Léisungen hunn normalerweis en OpenID Certification Badge.
Vergiesst och net iwwer existent bezuelte Provider wann Dir Ären OIDC Server net wëllt halen. Haut ginn et vill gutt Optiounen.
Wat ass Next
An nächster Zukunft wäerte mir den Traffic fir intern Servicer op eng aner Manéier zoumaachen. Mir plangen eisen aktuellen SSO op de Balancer mat OpenResty op e Proxy ze transferéieren baséiert op OAuth. Et gi scho vill fäerdeg Léisungen hei, zum Beispill:
Zousätzlecht Material
- gudde Service fir JWT Tokens ze validéieren
- Lëscht vun zertifizéierten OIDC Implementatiounen
Source: will.com