Conectează un provider OpenID Connect

Folosește acest ghid când furnizorul tău de identitate vorbește OpenID Connect, nu SAML. Orice emitent certificat OIDC funcționează — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace și altele asemenea urmează aceiași pași; diferă doar locul în care furnizorul tău afișează valorile.

Cerințe preliminare

• un furnizor OIDC la care poți crea un client — notează client id-ul și URL issuer (baza sub care se află documentul .well-known/openid-configuration), plus client secret-ul când clientul este de tip confidențial (clienții publici PKCE nu au niciunul),
• un server Control Center pe care îl administrezi (proprietarul serverului).

Pași

1. Deschide Setări → Server → Autentificare unică și comută pe OpenID Connect.
2. Completează URL issuer, Client ID și Client secret (opțional) atunci când furnizorul a emis unul. Control Center descoperă endpoint-urile din documentul de discovery standard al emitentului — nicio configurare per furnizor.
3. La furnizor, înregistrează redirectul https://<your-server>/oidc/callback pe acel client.
4. Dacă grupurile tale se află sub altă revendicare decât groups, setează numele din Claim grupuri; mapează grupurile la roluri dacă vrei (SSO nu poate acorda niciodată rolul de proprietar).
5. Alege politica de apartenență (adăugare automată în fiecare spațiu de lucru sau invitare obligatorie per spațiu de lucru), activează Folosește OpenID Connect pentru autentificare și apasă Salvează conexiunea.
6. Apasă Testează conexiunea — serverul preia documentul de discovery al emitentului și îi confirmă endpoint-urile, așa că un toast verde înseamnă că totul, mai puțin ciclul dus-întors din browser, funcționează. Ca să verifici și înregistrarea clientului, folosește verificatorul de mai jos.
7. Fă o autentificare: ecranul de conectare web afișează Autentifică-te cu OpenID Connect sau deschide direct https://<your-server>/oidc/login.

Revendicările (email, nume, grupuri) sunt citite de serverul tău de la endpoint-ul de token al emitentului prin TLS — browserul nu le furnizează niciodată, așa că nu este implicată nicio verificare locală a semnăturii JWT. Clientului trebuie să i se permită să ceară scopul openid profile email, exact ceea ce cere Control Center.

Deoarece acel canal TLS este singurul lucru care autentifică revendicările, URL-ul issuer trebuie să fie https — un emitent în text simplu i-ar permite oricărui atacator de pe traseu să falsifice identități în masă. http este acceptat doar pentru emitenți pe loopback (localhost, 127.0.0.1, ::1), pentru dezvoltare locală.

Client public sau client confidențial?

Forma implicită — și recomandată — este un client public care folosește fluxul de cod de autorizare cu PKCE (RFC 7636): verificatorul de cod de unică folosință pe care îl deține serverul înlocuiește secretul, iar schimbul de tokenuri este legat de cererea de autorizare care l-a pornit. Nu există niciun secret care să se scurgă, iar un cod de autorizare furat este inutil fără verificator. Unii furnizori numesc acest tip de client „SPA” sau „native” atunci când îl creezi.

Dacă furnizorul tău a emis în schimb un client confidențial, fie marchează clientul ca public la furnizor (PKCE rămâne activat în ambele cazuri), fie lipește client secret-ul în câmpul Client secret (opțional) al conexiunii. Secretul este stocat în fișierul de secrete 0600 al serverului (niciodată în baza de date), trimis la endpoint-ul de token ca client_secret_post și nu este returnat niciodată prin RPC; lăsarea câmpului gol la salvare păstrează secretul stocat. Când o autentificare eșuează la schimbul de tokenuri, jurnalul serverului numește eroarea proprie a furnizorului (invalid_client înseamnă aproape întotdeauna că secretul lipsește sau este greșit).

Accesibilitate

Autentificarea în sine este mediată de browser: emitentul doar redirecționează browserul utilizatorului înapoi la /oidc/callback, iar serverul tău face un apel HTTPS de ieșire către endpoint-ul de token — nu este nevoie de nicio conexiune de intrare de la emitent, așa că un server aflat în spatele NAT funcționează atâta timp cât browserele utilizatorilor îl pot atinge (LAN, VPN, Tailscale sau un tunel). Provisionarea SCIM este excepția: IdP-ul apelează direct serverul tău, ceea ce necesită un tunel sau un URL public — vezi Provisionă utilizatori cu SCIM.

Verifică-ți configurația din această pagină

Verificatorul de mai jos rulează în browserul tău. Preia direct documentul de discovery al emitentului tău, așa că acest site nu îl vede niciodată, și aplică regulile serverului: un emitent https care corespunde documentului, endpoint-uri pe propria origine a emitentului, PKCE S256 și metoda de autentificare la token de care are nevoie tipul clientului tău. Cu un client ID și o adresă de server, poate deschide o autentificare de test care arată dacă clientul și URI-ul lui de redirect sunt înregistrate. Nu cere niciodată client secret-ul.

Runs in your browserYour browser fetches the discovery document straight from your issuer. Add a server address and it also asks that server which sign-in methods it offers. This site never receives what you type.

Issuer URL

Client ID (optional)

Needed for the test sign-in.

Groups claim (optional)

Client type

Public, PKCE only Confidential, has a client secret

Never paste the secret here. The check only needs to know whether one exists.

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

Paste the discovery document instead

Discovery document JSON

For providers that block other sites from reading it.

Check issuer