Uni pochi mesi fa stava implementendu un servitore OpenID Connect per gestisce l'accessu per centinaie di e nostre applicazioni interne. Da i nostri propri sviluppi, cunvene à una scala più chjuca, avemu passatu à un standard generalmente accettatu. L'accessu à traversu un serviziu cintrali simplifica significativamente l'operazioni monotoni, riduce u costu di l'implementazione di l'autorizazioni, vi permette di truvà parechje soluzioni pronte è micca rack u cervellu quandu si sviluppanu novi. In questu articulu parleraghju di sta transizione è di i bumps chì avemu riesciutu à chjappà.
Tempi fà... Induve tuttu principia
Parechji anni fà, quandu l'applicazioni internu sò diventate troppu per gestisce manualmente, avemu scrittu una applicazione per cuntrullà l'accessu in a cumpagnia. Era una semplice applicazione Rails chì hà cunnessu à una basa di dati cù infurmazioni nantu à l'impiegati, induve l'accessu à e diverse funziunalità hè stata cunfigurata. À u listessu tempu, avemu lanciatu u primu SSO, chì era basatu annantu à a verificazione di tokens da parte di u cliente è u servitore d'autorizazione; u token hè statu trasmessu in forma criptata cù parechji paràmetri è verificatu nantu à u servitore d'autorizazione. Questa ùn era micca l'opzione più còmuda, postu chì ogni applicazione interna duverebbe descriverà una strata considerable di logica, è e basa di dati di l'impiegati eranu cumpletamente sincronizati cù u servitore d'autorizazione.
Dopu qualchì tempu, avemu decisu di simplificà u compitu di l'autorizazione centralizata. SSO hè statu trasferitu à u equilibratore. Cù l'aiutu di OpenResty, un mudellu hè statu aghjuntu à Lua chì verificava i tokens, sapia à quale applicazione andava a dumanda, è puderia verificà s'ellu ci era accessu. Stu approcciu hà simplificatu assai u compitu di cuntrullà l'accessu à l'applicazioni internu - ùn ci era più bisognu di discrìviri logica supplementu in u codice di ogni applicazione. In u risultatu, avemu chjusu u trafficu esternamente, ma l'applicazione stessu ùn sapia nunda di l'autorizazione.
Tuttavia, un prublema restava senza risolve. Chì ci hè di l'applicazioni chì necessitanu infurmazione di l'impiegati? Hè statu pussibule di scrive una API per u serviziu di l'autorizazione, ma dopu avete bisognu di aghjunghje una logica supplementaria per ogni applicazione. In più, vulemu caccià a dipendenza da una di e nostre applicazioni auto-scritte, chì hè più focu annantu à a traduzzione in OpenSource, in u nostru servitore d'autorizazione internu. Vi cuntaremu un altru tempu. A suluzione à i dui prublemi era OAuth.
Versu standardi generalmente accettati
OAuth hè un standard d'autorizazione chjaru, generalmente accettatu, ma postu chì a so funziunalità solu ùn hè micca abbastanza, OpenID Connect (OIDC) hè statu immediatamente cunsideratu. L'OIDC stessu hè a terza implementazione di u standard di autentificazione aperta, chì hà evolutu in un superset di u protocolu OAuth 2.0 (Protokollu d'Autorizazione Apertu). Sta suluzione risolve u prublema di mancanza di dati nantu à l'utilizatori finali, è permette ancu di cambià u fornitore d'autorizazione.
Tuttavia, ùn avemu micca sceltu un fornitore specificu è decisu di aghjunghje integrazione cù OIDC per u nostru servitore d'autorizazione esistenti. Sta decisione hè stata sustinuta da u fattu chì l'OIDC hè assai flexible in quantu à l'autorizazione di l'utilizatori finali. Cusì, era pussibule implementà u supportu OIDC in u vostru servitore d'autorizazione attuale.
A nostra strada per implementà u nostru servitore OIDC
1) Purtate i dati in a forma necessaria
Per integrà l'OIDC, hè necessariu di portà i dati di l'utilizatori attuali in una forma chì hè cumprinsibile à u standard. In OIDC questu hè chjamatu Claims. I marchi sò essenzialmente i campi finali in a basa di dati di l'utilizatori (nome, email, telefunu, etc.). Esiste , è tuttu ciò chì ùn hè micca inclusu in questa lista hè cunsideratu cum'è custom. Per quessa, u primu puntu chì avete bisognu di attentu se vulete sceglie un fornitore OIDC esistente hè a capacità di persunalizà convenientemente novi stampi.
U gruppu di marchi hè cumminatu in u subset - Scope. Durante l'autorizazione, l'accessu hè dumandatu micca à i marchi specifichi, ma à i scopi, ancu s'ellu ùn hè micca necessariu alcuni di i marchi da u scopu.
2) Implementatu i cuncessioni necessarii
A prossima parte di l'integrazione OIDC hè a selezzione è l'implementazione di tipi d'autorizazione, chjamati cuncessioni. L'ulteriore scenariu di interazzione trà l'applicazione scelta è u servitore d'autorizazione dipenderà da a cuncessione scelta. Un schema approssimativu per selezziunà a cuncessione ghjusta hè presentata in a figura sottu.
Per a nostra prima applicazione, avemu usatu a cuncessione più cumuna - Codice d'Autorizazione. A so sfarenza da l'altri hè chì hè in trè tappe, i.e. subisce teste supplementari. Prima, l'utilizatore fa una dumanda di permessu d'autorizazione, riceve un token di u Codice d'Autorizazione, dopu cù questu token, cum'è s'ellu era cun un bigliettu di viaghju, dumanda un token d'accessu. Tutta l'interazzione principale di stu scenariu d'autorizazione hè basatu annantu à redirezzione trà l'applicazione è u servitore d'autorizazione. Pudete leghje più nantu à sta cuncessione .
OAuth aderisce à u cuncettu chì i tokens d'accessu ricivuti dopu l'autorizazione deve esse tempurane è preferibile cambià in media ogni 10 minuti. A cuncessione di u Codice d'Autorizazione hè una verificazione in trè tappe per mezu di redirect; per fà un tali passu ogni 10 minuti, francamente, ùn hè micca u compitu più piacevule per l'ochju. Per risolve stu prublema, ci hè un altru grant - Refresh Token, chì avemu ancu usatu. Tuttu hè più simplice quì. Durante a verificazione da un altru cuncessione, in più di u token d'accessu principale, un altru hè emessu - Refresh Token, chì pò esse usatu solu una volta è a so vita, in regula, hè significativamente più longa. Cù questu Refresh Token, quandu u TTL (Time to Live) di u token d'accessu principale finisce, una dumanda per un novu token d'accessu ghjunghjerà à u puntu finale di un'altra cuncessione. U Refresh Token utilizatu hè immediatamente resettatu à zero. Questa verificazione hè in dui passi è pò esse realizatu in fondo, senza nutà da l'utilizatore.
3) furmati di pruduzzioni di dati utilizatori cunfigurati
Una volta chì i sussidi selezziunati sò implementati, l'autorizazione funziona, vale a pena menzionate a ricezione di dati di l'utilizatori finali. OIDC hà un puntu finale separatu per questu, induve pudete dumandà dati d'utilizatori cù u vostru token d'accessu attuale è s'ellu hè aghjurnatu. È se i dati di l'utilizatori ùn cambianu tantu spessu, ma avete bisognu à andà per i currenti parechje volte, pudete vene à una suluzione cum'è tokens JWT. Questi tokens sò ancu supportati da u standard. U token JWT stessu hè custituitu di trè parte: header (infurmazione nantu à u token), payload (qualsiasi dati necessariu) è firma (firma, u token hè firmatu da u servitore è in u futuru pudete verificà a fonte di a so firma).
In l'implementazione OIDC, u token JWT hè chjamatu id_token. Pò esse dumandatu cù un token d'accessu regulare è tuttu ciò chì resta hè di verificà a firma. Per questu scopu, u servitore d'autorizazione hà un puntu finale separatu cù una mansa di chjavi publichi in u formatu . E parlendu di questu, vale a pena nutà chì ci hè un altru puntu finale, chì hè basatu annantu à u standard riflette a cunfigurazione attuale di u servitore OIDC. Contene tutti l'indirizzi endpoint (cumpresu l'indirizzu di l'anellu di chjave publicu utilizatu per a firma), stampi è scopi supportati, algoritmi di criptografia utilizati, cuncessioni supportati, etc.
Per esempiu in 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"
]
}Cusì, usendu id_token pudete trasfiriri tutti i marchi necessarii à u token payload è ùn cuntattate micca u servitore d'autorizazione ogni volta per dumandà dati di l'utilizatori. U svantaghju di questu approcciu hè chì i cambiamenti in i dati di l'utilizatori da u servitore ùn venenu micca immediatamente, ma cù un novu token d'accessu.
I risultati di implementazione
Allora, dopu avè implementatu u nostru servitore OIDC è a stallazione di cunnessione à questu in u latu di l'applicazione, avemu risoltu u prublema di trasmissione di l'infurmazioni d'utilizatori.
Siccomu OIDC hè un standard apertu, avemu avà l'opzione di sceglie un fornitore esistente o implementazione di u servitore. Avemu pruvatu Keycloak, chì hè statu assai faciule da cunfigurà; dopu avè stabilitu è cambiatu e cunfigurazioni di cunnessione da u latu di l'applicazione, hè pronta per andà. Da u latu di l'applicazione, tuttu ciò chì resta hè di cambià a cunfigurazione di cunnessione.
Parlà di suluzione esistenti
In a nostra urganizazione, cum'è u primu servitore OIDC, avemu assemblatu a nostra propria implementazione, chì hè stata supplementata quantu necessariu. Dopu un esame detallatu di altre suluzioni pronti, pudemu dì chì questu hè un puntu cuntruversu. A decisione di implementà u nostru servitore hè stata guidata da preoccupazioni da parte di i fornituri in quantu à a mancanza di funziunalità necessaria, è ancu a prisenza di un vechju sistema chì cuntene diverse autorizazioni persunalizati per certi servizii è digià almacenatu assai dati nantu à l'impiegati. . Tuttavia, in implementazioni pronti, ci sò cunvenzioni per l'integrazione. Per esempiu, Keycloak hà u so propiu sistema di gestione di l'utilizatori è i dati sò almacenati direttamente in questu, è movendu i vostri utilizatori ùn serà micca difficiule. Per questu scopu, Keycloak hà una API chì vi permetterà di realizà cumplettamente tutte l'azzioni di trasferimentu necessarii.
Un altru esempiu di implementazione certificata, interessante, in my opinion, hè Ory Hydra. Hè interessante perchè hè custituitu da diverse cumpunenti. Per integrà, avete bisognu di ligà u vostru serviziu di gestione di l'utilizatori à u so serviziu d'autorizazione è espansione quantu necessariu.
Keycloak è Ory Hydra ùn sò micca solu suluzioni pronti. Hè megliu selezziunà una implementazione certificata da OpenID Foundation. Queste soluzioni sò tipicamente avè un badge di Certificazione OpenID.
Ùn vi scurdate ancu di i fornituri pagati esistenti se ùn vulete micca mantene u vostru servitore OIDC. Oghje ci sò parechje scelte boni.
Chì vene
In un futuru vicinu, andemu à chjude u trafficu à i servizii internu in una manera diversa. Avemu pianificatu di migrà u nostru SSO attuale nantu à u equilibratore utilizendu OpenResty à un proxy basatu in OAuth. Ci sò ancu parechje soluzioni pronti quì, per esempiu:
Materiali supplementari
- un bonu serviziu per verificà i tokens JWT
- lista di implementazioni certificati OIDC
Source: www.habr.com