Pe scurt despre conectarea openid

Când citiți specificația pentru OpenID Connect. Puteți simți sentimente destul de neplăcute, de la frică ușoară până la dezamăgire totală. Toate acestea se întâmplă deoarece sunt scrise în limbajul specificației "uscate" și, în cea mai mare parte, descriu cazurile limită, excepțiile etc. Cu toate acestea, atunci când le traduceți într-o limbă umană normală și treceți la cazuri specifice, totul devine destul de evident. Deci, hai să începem! (Remarochka: cea mai mare parte a textului coincide cu propoziția originală scrisă de David Rekordonom Practic, modificările mele afectat doar câteva dintre numele parametrilor și a altor obiecte mici.)

Creați o cerere de conectare OpenID

Pentru ca un client să facă o solicitare OpenID Connect, trebuie să aibă următoarele informații despre server:

Clientul construiește cererea OAuth 2.0 pentru a obține un jeton.

În ciuda faptului că înregistrarea preliminară a clientului dvs. pe server poate să nu fie obligatorie, este posibil ca serverul să aibă restricții și cerințe diferite față de clienți pentru solicitările de informații despre utilizator.

Obținerea răspunsului OpenID Connect

Prima parte este Base64url. codat în notație JSON și descriind algoritmul și tipul de jeton:

A doua parte este Base64url codată în notație JSON:

A treia parte a serverului a urmărit imaginea:

Accesul la informațiile despre utilizator (opțional)

Serverul poate adăuga opțional date suplimentare acestui răspuns (de exemplu, cum ar fi contactele portabile) până când modifică cheile rezervate de OpenID Connect. (Notă: există chei mai clar definite, dar pentru scurtcircuit, am omite descrierea lor.)

Deschidere (opțional)

Răspunsul este un obiect JSON care include un punct final și alte informații.
De exemplu:

Clienții neînregistrați și înregistrarea dinamică (opțional)

Înainte de a răspunde la solicitări, serverul trebuie să verifice dacă URL-ul apelului este înregistrat în afara acestui flux OpenID. Dacă da, serverul va trimite informațiile cu răspunsul la eroare. Politicile de server trebuie să fie dezvoltate să se ocupe de astfel de cazuri, atunci când sunt transmise redirect_uri dezvoltator de client înregistrat anterior în cadrul cererilor de înregistrare dinamice. Acest comportament poate însemna, de exemplu, că noile cereri înregistrează în mod dinamic aceste redirect_uri va duce la eroare, dar interogări folosind înregistrările dinamice deja implementate vor continua să funcționeze până când expiră.
Pentru a asigura asocierea dinamică, serverul include următorii parametri de răspuns JSON:

• client_id este ID-ul clientului. Această valoare se poate schimba cu fiecare răspuns la solicitare către server.
• client_secret este cheia clientului. Se va schimba neapărat cu fiecare răspuns.
• expires_at - numărul de secunde de la 1970-01-01T0: 0: 0Z conformitate cu UTC, și totuși nu client_secret CLIENT_ID depășite sau 0 în cazul în care nu au o limită de timp.
• registration_client_uri - uri pentru gestionarea acestor acreditări.
• registration_access_token - un token care va fi folosit pentru a accesa registration_client_uri.

Clientul trebuie să stocheze datele dinamice de înregistrare pentru a lucra cu jetoanele serverului. Pentru fiecare înregistrare dinamică, clientul va trebui să stocheze ID-ul clientului, cheia clientului, timpul de expirare, adresa URL personalizată, firele acceptate și API-ul cu informații despre utilizator. Termenul ar trebui să fie păstrat ca o dată absolută sau ca un semn că înregistrarea va dura pentru totdeauna.
După cum puteți vedea, principalele procese ale clientului web OpenID Connect sunt destul de simple și la fel de simple ca și cele inițial propuse. În același timp, pot fi utilizate funcții suplimentare, de exemplu, interogarea seturilor de date specifice, mai degrabă decât setul implicit. Aceste caracteristici suplimentare sunt disponibile atunci când sunt necesare și nu transformă interacțiunile simple în probleme majore pentru clienți, cu un număr mare de furnizori OpenID.

Trimiteți-le prietenilor: