Çfarë është OAuth? „Hyr me Google” dhe qasja e delegueme shpjeguar

OAuth është një standard i hapur që lejon një përdorues t’i japë një aplikacioni qasje të kufizuar në llogarinë e tij në një shërbim tjetër, pa i dorëzuar fjalëkalimin. Kur klikon „Connect Google Calendar” dhe sheh një ekran që pyet „Të lejohet ky aplikacion të shohë ngjarjet e tua?”, ky është OAuth. Aplikacioni merr një token vetëm për atë që aprovove, dhe ti mund ta revokosh në çdo kohë. I njëjti mekanizëm, me një shtresë shtesë të quajtur OpenID Connect, fuqizon „Hyr me Google” dhe butona të ngjashëm.

Pse ka rëndësi OAuth kur ndërton me AI

OAuth paraqitet në dy situata të zakonshme kur ndërton një aplikacion:

1. Hyrja sociale. Dëshiron që përdoruesit të tu të „Hyjnë me Google” (ose Apple, Microsoft, GitHub) në vend që të krijojnë një fjalëkalim tjetër. Shiko si të shtosh hyrjen në aplikacionin tënd.
2. Lidhja me llogaritë e përdoruesve në shërbime të tjera. Aplikacioni yt ka nevojë të lexojë kalendarin e përdoruesit, të postojë në llogarinë e tij sociale, të tërheqë skedarë nga disku i tij në cloud ose të sinkronizojë të dhënat e kontabilitetit.

Në të dyja rastet ndërtuesi yt me AI mund të shkruajë kodin, por disa hapa mund t’i bësh vetëm ti: krijon një aplikacion zhvilluesi me ofruesin, merr një client ID dhe një client secret, regjistron URL-të e kthimit dhe, për disa leje, kalon shqyrtimin e ofruesit. Njohja e mënyrës si funksionon OAuth i bën këto hapa — dhe gabimet që prodhojnë — shumë më pak misterioze. Për pamjen më të gjerë të identifikimit, shiko çfarë është autentikimi.

Një analogji e përditshme

Mendo për një kartë çelësi hoteli. Në check-in, recepsioni konfirmon kush je, pastaj të jep një kartë që hap dhomën tënde dhe palestrën — jo dhoma të tjera, jo zonat e stafit — dhe pushon së funksionuari në checkout. Karta nuk përmban pasaportën tënde. Nëse e humbet, recepsioni e anulon dhe të jep një tjetër.

• Recepsioni është serveri i autorizimit (faqja e identifikimit të Google).
• Kontrolli i identitetit është kur ti hyn në Google.
• Karta e çelësit është access token.
• „Vetëm dhoma dhe palestra” janë scopes që aprovove.
• Checkout-i është kur tokeni skadon, ose kur ti revokon qasjen.

Aplikacioni që po përdor nuk sheh kurrë fjalëkalimin tënd të Google, vetëm kartën e çelësit.

Si funksionon OAuth, hap pas hapi

Rrjedha më e zakonshme për aplikacionet web është rrjedha e kodit të autorizimit (authorization code flow). Ja çfarë ndodh kur një përdorues e lidh Google Calendar-in me një aplikacion planifikimi:

1. Klik. Përdoruesi klikon „Connect Google Calendar.”
2. Ridrejtim te ofruesi. Aplikacioni e dërgon shfletuesin te Google me client ID-në e vet, scopes që kërkon (lexim i ngjarjeve të kalendarit) dhe redirect URI-n ku Google duhet ta kthejë përdoruesin.
3. Hyrje dhe pëlqim. Përdoruesi hyn në Google (nëse nuk ka hyrë tashmë) dhe sheh një ekran pëlqimi me listën e asaj që kërkon aplikacioni. Klikon Lejo.
4. Kthehu me një kod. Google e ridrejton shfletuesin te redirect URI-ja e aplikacionit me një authorization code të jetëgjatësisë së shkurtër dhe një përdorimi.
5. Shkëmbimi në server. Serveri i aplikacionit e dërgon atë kod, bashkë me client secret-in, direkt te Google dhe merr një access token (dhe shpesh një refresh token).
6. Përdor API-n. Serveri thërret API-n e Google Calendar me access token-in dhe merr ngjarjet e përdoruesit.

Callback-u në hapin 4 duket diçka si kjo:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

Dhe përgjigja e tokenit në hapin 5 është JSON si kjo:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Pika e rëndësishme e dizajnit: shkëmbimi i tokenit ndodh server-me-server, kështu që client secret-i dhe tokenat nuk kanë nevojë kurrë të kalojnë nëpër shfletues.

OAuth vs OpenID Connect vs hyrja jote e vetë

Shumë aplikacione i kombinojnë: hyrje me email dhe fjalëkalim, plus „Hyr me Google” përmes OIDC, plus lidhje të veçanta OAuth me shërbime të tjera.

Termat kryesorë

Keqkuptimet e zakonshme

• „OAuth është një sistem identifikimi.” OAuth i thjeshtë jep qasje; OpenID Connect merret me identitetin. Përdorimi i një access token-i të thjeshtë si provë se kush është dikush ka shkaktuar gabime të vërteta sigurie.
• „Aplikacioni merr fjalëkalimin tim.” Kurrë. Pikërisht ky është qëllimi.
• „Kërkimi i më shumë scopes është i padëmshëm.” Përdoruesit janë më të kujdesshëm me kërkesat e gjera, dhe ofrues si Google mund të kërkojnë shqyrtim të aplikacionit për scopes të ndjeshme ose të kufizuara. Kërko vetëm atë që të nevojitet.
• „Client secret-i mund të vendoset në frontend.” Çdo gjë në kodin e shfletuesit është publike. Mbaje në sekretet e anës së serverit.
• „Funksionon në testim, pra do funksionojë në prodhim.” Ofruesit shpesh kufizojnë aplikacionet e paverifikuara — për shembull, te përdoruesit e listuar si testues — dhe redirect URI për domenin tënd live duhet të regjistrohet veçmas.
• „Tokenat zgjasin përgjithmonë.” Access token-et skadojnë shpejt, dhe përdoruesit mund të revokojnë qasjen. Aplikacioni yt duhet t’i trajtojë të dyja me kujdes.

Çfarë t’i kërkosh ndërtuesit tënd me AI

• „Shto „Hyr me Google” duke përdorur OpenID Connect me një bibliotekë autentikimi të mirëmbajtur — mos e ndërto vetë rrjedhën e OAuth.”
• „Përdor rrjedhën e kodit të autorizimit me PKCE dhe kontrollo parametrin state.”
• „Lexo client ID-në dhe client secret-in nga variablat e mjedisit në server.”
• „Kërko vetëm scopes që na nevojiten: qasje vetëm për lexim në kalendar.”
• „Më trego çdo URL ridrejtimi që duhet të regjistroj në konsolën e ofruesit, për pamjen paraprake, URL-në e publikuar dhe domenin tim të personalizuar.”
• „Ruaj refresh token-et e enkriptuara në bazën e të dhënave, dhe për token-et e skaduara ose të revokuara kërko nga përdoruesi të rilidhet.”
• „Lejo përdoruesit ta shkëpusin integrimin nga faqja e cilësimeve të tyre.”

OAuth dhe Mythex

Mythex nuk ka hyrje të integruar për përdoruesit fundorë të aplikacioneve që ndërton; dokumentacioni i tij përshkruan një qasje „sill-your-own” — zgjedh një bibliotekë autentikimi ose një ofrues të hostuar, ruan çelësat e tij si sekrete të projektit, dhe agjenti shkruan kodin. Recetë e shtimit të autentikimit ka një kërkesë fillestare për këtë. Do të takosh OAuth edhe brenda vetë Mythex: mund të regjistrohesh me Google, lidhja me GitHub për sinkronizimin e repo-s përdor OAuth të GitHub, dhe klientët AI që lidhen me Mythex përmes MCP kalojnë nëpër një faqe pëlqimi OAuth. Për më shumë, shiko çfarë është autentikimi dhe çfarë është autentikimi me dy faktorë.

Pyetje