Salutare, ma chinui de ceva vreme sa inteleg OAuth, iar resursele de pe net nu par a fi de ajutor.
Am inteles ideea cu OAuth, este folosit cand ai nevoie sa accesezi un serviciu in numele utilizatorului, in loc sa dai credentialele tale (username & pwd) serviciului x (api-ul meu), se foloseste acest flow.
Apesi pe login, esti redirectionat la IdP page, esti redirectionat inapoi cu un access token pe care dupa il vei putea da API-ului tau. (aici mai intra si implementarile cu authorization code / PKCE, dar irelevant).
Problema este ca nu inteleg cum poate API-ul tau sa verifice tokenul generat de Azure, Google (Y)… Din ce am gasit pana acum, va trebuie ca API-ului tau sa faca un request cu tokenul la serviciul Y. Pt azure ar fi asta: .AddMicrosoftIdentityWebApi(configuration); ca sa il valideze.
Totusi, nu vazusem peste tot asta in tutoriale? Dar intrebarea este, asa se procedeaza cu orice token din Oauth?
Iar urmatoare intrebare ar fi, daca eu vreau sa am si Oauth si basic auth-ul implementat de mine. Cum va stii API-ului meu cand primeste un token, ce strategie sa foloseasca sa verifice tokenul? Pot adauga mai multe strategii de validare a tokenului la api, dar cum le diferentiaza? Le incearca pe fiecare?
Multumesc, si daca intrebarile mele sunt prea basic, apreciez si niste link-uri in care sa gasesc raspunsurile
Da, asta inteleg. Problema se pune mai departe, cand foloseste acel token generat de Google, Azure,…spre api. Cum il valideaza API-ului tau, avand in vedere ca e generat de altcineva?
Validat in sensul de, a te lasa sa accesezi endpointuri care au nevoie de autentificare*
Pe endpoint-ul de auth primești mai multe informații: un token, un client id etc.
Tu folosești token-ul ăla să faci un request extra spre serverul de auth (în backend) să verifici dacă e valid.
Uită-te la github, mi se pare că este explicat mai bine decât la Google. Procesul este asemănător la toți providerii de oAuth (deși nu sunt sigur că obiectul primit este același peste tot).
Acel [Authorize] attribute, din .NET verifica JWT-ul pe care i-l dai sa vada daca userul are autorizatie sau nu. Intrebarea este, daca token-ul acesta vine de la GitHub, de unde stie API-ul meu sa ii verifice signature-ul?
Pai e o mica smecherie la mijloc, o data un certificat eliberat si validat, tu il accepti ca de facto valid cu JWT, nu il mai validezi. L-ai validat cand l-ai setat pe domeniul tau pe FE.
Daca ai un link, cu cel mai mare drag ma uit. Dar din ce am inteles eu, poti pune orice payload in JWT. Nu poti crede nimic, pana nu verifici signature-ul. Care, cred ca am inteles mai sus, se va face prin alt api call la serviciu Azure/Google, doar apoi iei de buna ce e in payload.
Nu chiar, API-ul tau va face cam un request pe zi sa ia lista de chei/certificate care pot valida o semnatura. Serverele astea rotesc cheile la ceva timp din motive de securitate. Dar pastreaza cheile vechi (pentru o perioada de timp) pentru a valida token-urile “in flight”.
Idea e ca un JWT cand e emis, are:
header (ce contine tipul token-ului, ce algoritm e folosit la semnare, etc.)
un body (ce contine tot felul de claim-uri, acel json)
o semnatura
Tu poti sa verifici un JWT ca e valid, verificand semnatura. Semnatura e calculata aplicand niste algoritmi criptografici + o cheie asimetrica peste header si body.
Pe scurt:
tu nu poti genera un token valid decat daca ai cheia privata (si nu o ai, pentru ca serverele expun doar cheia publica)
tu nu poti modifica un token si sa ramana valid pentru ca semnatura token-ului este strans legata de continutul tokenului. Daca modifici un singur caracter, tokenul devine invalid. (din nou punctul de mai sus, nu ai cheia privata sa generezi o semnatura valida).
Nu e ineficient, pentru ca se intampla local… E destul de rapid sa verifici o semnatura in memorie.
De obicei lumea foloseste providere de autentificare locale. Practic cand dai login with google, iti creezi un user local pe care il marchezi ca a venit din userul cu {id: x, provider: google}. Dar se face asta de obicei ca sa nu depinzi de 3rd parties. De exemplu daca vrei sa renunti la google din varii motive, poti sa lasi userul sa-si creeze o parola. In cazul asta tu folosesti doar o schema de autentificare. Provider-ul extern e folosit doar pentru auto-provisioning + login cu schema ta.
Am vazut ca tot mai multi scot “Login with Facebook”
Apropo, e opensource codul. Mi-am batut capul de multe ori cu el la lucru. Si noi folosim DuendeIdentityServer si avem ca external login provider AAD.
Ok, banuiesc ca prin lista de chei te referi la secretkey (n are cum sa fie secretkey ca ar fi exploited atunci), poate un caching ceva la jwt-urile verificate, sa faci criptarea la JWT header si payload sa verifici semnatura. Daca e asa, intr-adevar nu se pune problema de eficienta.
De acord si cu restul punctelor. Mersi mult, am inteles
Atentie, cheile/certificatele expuse de OpenId nu sunt aceleasi folosite de TLS. Desi chain of trust este prin SSL/TLS, deoarece le obtii printr-un GET.
Adica accepti cheile de verificare semnaturi JWT, pentru ca le obtii de pe un domeniu cunoscut, printro conexiune securizata de un certificat emis pentru acel domeniu.
@andrei-tatar gata, cu ce ai zis tu am inteles. confuzia era in symmetric vs asymmetric encryption. eu implementasem pana acum doar symmetric encryption, si nu avea sens acum are.
