Găzduirea proprie a furnizorului de identitate: compromisuri între suveranitate și securitate (2026)

TL;DR

• Un furnizor de identitate găzduit propriu (self-hosted) îți oferă suveranitatea datelor, personalizare profundă și licențiere previzibilă — cu prețul de a-l rula, actualiza și securiza chiar tu.
• Keycloak este liderul consacrat din motive întemeiate: matur, certificat, ecosistem uriaș. Authentik este o opțiune self-host mai ușoară și mai modernă. Ambele sunt IdP-uri clasice excelente.
• Diferențiatorii reali în 2026 nu sunt numărul brut de funcționalități: sunt semnarea post-cuantică, atestarea hardware obligatorie și operarea în UE — exact zona în care este poziționat CAI-AUTH.
• Varianta administrată (SaaS) câștigă atunci când nu ai capacitatea operațională sau personalul de gardă 24/7 pentru a rula o rădăcină de încredere expusă pe internet. Fii onest cu privire la tabăra din care faci parte.

Ce este un furnizor de identitate găzduit propriu?

Un furnizor de identitate găzduit propriu este un server de autentificare și single sign-on pe care îl implementezi și îl operezi pe o infrastructură pe care o controlezi — propriile tale servere, propriul tău mediu de cloud sau un centru de date on-prem — în loc să-l consumi ca SaaS al unui furnizor. Deții baza de date, cheile de semnare, ritmul de actualizare și perimetrul de securitate. În schimbul acestui control și a suveranității datelor, îți asumi responsabilitatea operațională de a menține o rădăcină de încredere expusă pe internet actualizată, monitorizată și foarte disponibilă.

Acest compromis — control și suveranitate versus povară operațională — reprezintă întreaga decizie. Acest articol îl parcurge în mod echitabil, apoi pune trei furnizori OIDC găzduibili propriu unul lângă altul, pe o matrice neutră: Keycloak, Authentik și CAI-AUTH.

De ce să-ți găzduiești singur un IdP, până la urmă?

Trei motivații domină, iar toate sunt legitime:

• Suveranitate și rezidența datelor. Furnizorul tău de identitate este perimetrul tău. Fiecare autentificare, sesiune și decizie legată de token trece prin el. Menținerea acestuia sub propriul tău control legal și fizic contează atunci când ești supus GDPR, NIS2 sau DORA, sau pur și simplu atunci când nu vrei ca procesul legal al unei țări terțe să ajungă la datele tale de autentificare. Tratăm expunerea juridică în detaliu în Identitatea suverană a UE vs CLOUD Act-ul SUA.
• Predictibilitatea costurilor. Prețarea per utilizator activ lunar (MAU) la IdP-urile administrate crește odată cu succesul tău. Găzduirea proprie transformă acest lucru într-o linie de cost fixă, infrastructură-plus-personal. Pentru baze mari de utilizatori, calculul favorizează adesea găzduirea proprie; pentru cele mici, de obicei nu.
• Profunzimea personalizării și integrării. Găzduirea proprie îți permite să intervii asupra temelor vizuale, fluxurilor personalizate, particularităților de federalizare și cazurilor limită de protocol pe care nivelurile administrate le blochează în spatele planurilor enterprise sau pur și simplu nu le expun.

Dacă niciuna dintre aceste trei motivații nu ți se aplică puternic, găzduirea proprie este probabil opțiunea implicită greșită — și spunem asta clar în secțiunea „când varianta administrată bate găzduirea proprie”.

Costul operațional ascuns

Versiunea de broșură a găzduirii proprii este „descarcă, implementează, gata”. Realitatea este că un IdP este o rădăcină de încredere, iar a-l rula corect seamănă mai mult cu administrarea unui mic seif de bancă decât a unei aplicații web fără stare. Costurile ascunse:

• Disponibilitate 24/7. Dacă IdP-ul este căzut, tot ce este federalizat la el este căzut. Ai nevoie de redundanță, verificări de sănătate și o strategie de failover testată.
• Viteza de aplicare a patch-urilor. Serverele de autentificare sunt ținte de mare valoare. CVE-urile din IdP-ul tău, din mediul său de execuție și din dependențele sale au nevoie de cicluri rapide și testate de aplicare a patch-urilor.
• Gestiunea cheilor. Cheile de semnare trebuie generate, rotite, salvate și protejate — ideal într-un HSM sau într-un keystore susținut de hardware. O cheie de semnare scursă înseamnă o compromitere totală.
• Audit și jurnalizare. Regimurile de conformitate așteaptă piste de audit ale evenimentelor de autentificare rezistente la modificări și interogabile, nu doar jurnale de aplicație.
• Migrări la actualizare. Actualizările de versiune majoră ale unui IdP cu stare (migrări de realm/schemă) sunt proiecte reale, nu apt upgrade.

Cum se citește diagrama: Acest arbore de decizie separă întrebarea „ar trebui să găzduiesc propriu” de întrebarea „ce produs”, deoarece confundarea lor este cea mai frecventă greșeală pe care o fac echipele. Începe prin a testa dacă motivațiile tale (suveranitate, personalizare, cost) sunt reale, apoi condiționează găzduirea proprie de două capabilități operaționale dure: disponibilitate non-stop și gestiune disciplinată a cheilor plus aplicarea patch-urilor. Dacă nu poți îndeplini aceste condiții, răspunsul onest este să începi cu varianta administrată și să construiești maturitate operațională înainte de a prelua custodia unei rădăcini de încredere. Doar echipele care trec ambele praguri ajung la nodul final — alegerea unui produs găzduit propriu după criteriile care contează cu adevărat în 2026.

Matricea de comparație: Keycloak vs Authentik vs CAI-AUTH

Să fim corecți mai întâi cu liderii consacrați. Keycloak (un proiect Red Hat / adiacent CNCF) este IdP-ul self-hosted implicit dintr-un motiv: este matur, testat în practică, certificat OpenID, suportă o suprafață vastă de protocoale (OIDC, OAuth 2.x, SAML, federalizare LDAP/Kerberos), are un ecosistem profund de extensii și o comunitate enormă. Dacă cerința ta este „un IdP clasic dovedit, complet funcțional, pe care îl pot rula singur”, Keycloak este greu de întrecut — vezi documentația Keycloak. Authentik este un furnizor self-hosted mai nou, bazat pe Python, cu o experiență de administrare mai curată, un constructor de fluxuri flexibil și o amprentă mai redusă; este o alegere excelentă pentru echipele care găsesc Keycloak prea greoi — vezi documentația Authentik.

CAI-AUTH nu concurează pe numărul brut de funcționalități, iar nu vom pretinde altceva. Este un furnizor de identitate de sine stătător, scris în Rust pe framework-ul axum — nu un fork, plugin sau distribuție Keycloak. Diferențiatorii săi sunt înguști și specifici: semnarea post-cuantică, atestarea hardware obligatorie și operarea în UE. CAI Technology nu este o autoritate guvernamentală.

Cum se citește diagrama: Această matrice aliniază cei trei furnizori pe cele cinci criterii care determină o decizie de găzduire proprie în 2026, astfel încât să poți vedea exact unde conduce și unde rămâne în urmă fiecare. Keycloak și Authentik sunt ambele IdP-uri clasice puternice, licențiate permisiv sau deschis, pe care le poți rula pe orice infrastructură, inclusiv pe sol UE — lipsa lor este semnarea post-cuantică, pe care niciunul nu o livrează astăzi. CAI-AUTH rămâne în urmă pe amploare și pe maturitatea ecosistemului, dar conduce pe cele trei axe înguste pentru care a fost construit: token-uri semnate post-cuantic (composite CAI-PQ-HYBRID-87-Ed25519), atestare care este obligatorie în loc de opțională și operare în interiorul UE prin design. Scopul matricei nu este să declare un câștigător, ci să facă lizibil compromisul: alege amploarea funcționalităților și ecosistemul, sau alege criptografia orientată spre viitor și suveranitatea UE, în funcție de ce cer modelul tău de amenințare și reglementatorii.

Câteva clarificări oneste asupra acelei matrice:

• Semnare PQ. CAI-AUTH emite token-uri OIDC semnate cu o semnătură composite ML-DSA-87 + Ed25519 (id de algoritm CAI-PQ-HYBRID-87-Ed25519), urmând draft-ietf-lamps-pq-composite-sigs. Keycloak și Authentik sunt IdP-uri clasice excelente, dar nu livrează astăzi semnarea post-cuantică a token-urilor. Dacă „harvest now, forge later” se află în modelul tău de amenințare, această lipsă contează; dacă încă nu se află, nu contează.
• Atestare hardware. Authentik și Keycloak suportă WebAuthn/FIDO2, care este susținut de hardware, dar nu întotdeauna atestat. CAI-AUTH face atestarea hardware (Android StrongBox / TEE) obligatorie, respingând direct dispozitivele cu root sau emulate. Distincția dintre susținut-de-hardware și impus-prin-atestare este chiar esența MFA rezistentă la phishing — fără atestare, „passwordless” încă are încredere într-un dispozitiv posibil compromis.
• Certificare. Când evaluezi orice IdP, verifică dacă apare pe lista de certificare OpenID pentru profilurile de care ai nevoie. Certificarea este un semnal de încredere real și verificabil.

Considerații de securitate atunci când găzduiești propriu

Indiferent de produsul pe care îl alegi, găzduirea proprie mută aceste responsabilități asupra echipei tale. Raportează-ți implementarea la un standard de referință recunoscut — OWASP Application Security Verification Standard (ASVS) este etalonul potrivit — și acordă o atenție deosebită:

• Custodia cheilor de semnare. Stochează cheile într-un HSM sau într-un keystore susținut de hardware; niciodată în text clar pe sistemul de fișiere al aplicației. Definește procedurile de rotire și revocare înainte de a intra în producție.
• Audit rezistent la modificări. Jurnalele de aplicație nu sunt o pistă de audit. Caută jurnalizare a evenimentelor de tip append-only, înlănțuită criptografic (CAI-AUTH folosește un lanț Merkle BLAKE3), astfel încât o compromitere a gazdei să nu poată rescrie în liniște istoricul.
• Integritatea lanțului de aprovizionare. Verifică proveniența build-ului (atestări SLSA, lansări semnate), astfel încât binarul pe care îl rulezi să fie cel construit din sursa revizuită.
• Expunere în rețea. Un IdP ar trebui să expună suprafața minimă: endpoint-urile de discovery, token, JWKS și authorize — planurile de administrare și introspecție ar trebui să fie segregate.

Când varianta administrată bate găzduirea proprie

Găzduirea proprie nu este o virtute în sine. Alege un furnizor administrat când:

• Nu ai personal de gardă 24/7 și nu poți garanta un răspuns rapid la incidente pe o rădăcină de încredere expusă pe internet.
• Baza ta de utilizatori este suficient de mică încât prețarea per-MAU să fie mai ieftină decât costul integral al personalului plus infrastructura plus riscul.
• Nu ai competența internă pentru a face gestiune de chei la nivel HSM și migrări de actualizare testate.
• Trebuie să livrezi în acest trimestru și nu poți absorbi un proiect de implementare a IdP-ului care durează mai multe săptămâni.

Există o cale de mijloc rezonabilă: o ofertă administrată, operată în UE, a unui produs găzduibil propriu, care îți oferă suveranitate și o cale curată de migrare către găzduirea proprie ulterior, fără a-ți re-platformiza părțile care se bazează pe el (relying parties). Dacă o cântărești față de liderii consacrați din SUA, comparația de fază de decizie din Alternative la Okta și Auth0 pentru companiile din UE cartografiază terenul.

Poți inspecta suprafața OIDC live a CAI-AUTH la auth.caitech.ro sau poți prelua build-ul self-host de pe pagina de descărcare pentru a-l evalua pe propria ta infrastructură.

FAQ

Care este cel mai bun furnizor de identitate găzduit propriu?

Nu există un singur „cel mai bun” — depinde de prioritățile tale. Keycloak este alegerea cea mai matură și cea mai larg certificată pentru SSO clasic, complet funcțional. Authentik se potrivește echipelor care vor o alternativă mai ușoară și mai modernă. CAI-AUTH se potrivește echipelor ale căror priorități sunt semnarea post-cuantică, atestarea hardware obligatorie și operarea în UE, mai degrabă decât amploarea maximă a funcționalităților.

Este Keycloak singura opțiune?

Nu. Keycloak este liderul consacrat și o opțiune implicită excelentă, dar este unul dintre mai mulți furnizori de identitate găzduibili propriu. Authentik oferă o alternativă mai ușoară și mai modernă, iar CAI-AUTH oferă o opțiune post-cuantică, operată în UE. Alegerea corectă depinde de faptul dacă optimizezi pentru amploarea funcționalităților și ecosistem, sau pentru criptografia orientată spre viitor și suveranitate.

Poate fi post-cuantic un IdP găzduit propriu?

Da. Un furnizor găzduit propriu își poate semna token-urile OIDC cu algoritmi post-cuantici. CAI-AUTH face acest lucru astăzi folosind o semnătură composite ML-DSA-87 plus Ed25519, urmând draft-ul IETF de semnături composite, astfel încât token-urile să rămână verificabile față de primitivele clasice în timpul tranziției, câștigând în același timp protecție post-cuantică pentru rădăcina de încredere de semnare.

Îmbunătățește găzduirea proprie a unui IdP suveranitatea datelor?

Poate, dar locația de găzduire singură nu este suveranitate. Suveranitatea depinde de cine poate constrânge legal accesul la datele și operațiunile tale, nu doar de locul unde stau serverele. Găzduirea proprie pe o infrastructură pe care o controlezi, în interiorul propriei tale jurisdicții, cu un furnizor operat în UE, este combinația cea mai puternică — tratată în detaliu în analiza noastră despre CLOUD Act.

Pregătit să compari în propriii tăi termeni? Explorează documentul live de discovery OIDC post-cuantic la auth.caitech.ro sau descarcă build-ul self-host și rulează-l împotriva propriilor tale relying parties.

Entitate juridică: CAI TECHNOLOGY SRL, CUI 50512457.