Kas ir OAuth? „Pierakstīties ar Google” un deleģēta piekļuve izskaidrota

OAuth ir atvērts standarts, kas ļauj lietotājam piešķirt vienai lietotnei ierobežotu piekļuvi savam kontam citā pakalpojumā, nenododot paroli. Kad noklikšķini „Savienot Google kalendāru” un redzi ekrānu, kas jautā „Vai atļaut šai lietotnei redzēt maniem notikumiem?”, tas ir OAuth. Lietotne saņem marķieri tieši tam, ko apstiprināji, un to vari atsaukt jebkurā brīdī. Tā pati mehānika ar papildu slāni, ko sauc par OpenID Connect, nodrošina „Pierakstīties ar Google” un līdzīgas pogas.

Kāpēc OAuth ir svarīgs, veidojot ar MI

OAuth parādās divās bieži sastopamās situācijās, veidojot lietotni:

1. Sociālā pieteikšanās. Vēlies, lai lietotāji „Pierakstītos ar Google” (vai Apple, Microsoft, GitHub), nevis izveidotu citu paroli. Skat. kā pievienot pieteikšanos savai lietotnei.
2. Savienošanās ar lietotāju kontiem citos pakalpojumos. Tavai lietotnei vajag nolasīt lietotāja kalendāru, publicēt viņa sociālajā kontā, izgūt failus no mākoņa diska vai sinhronizēt grāmatvedības datus.

Abos gadījumos tavs MI veidotājs var uzrakstīt kodu, bet dažus soļus var izdarīt tikai tu: izveidot izstrādātāja lietotni pie nodrošinātāja, iegūt klienta ID un klienta noslēpumu, reģistrēt atzvanīšanas URL un dažām atļaujām iziet nodrošinātāja pārskatīšanu. Zinot, kā darbojas OAuth, šie soļi — un kļūdas, ko tie rada — kļūst daudz mazāk noslēpumaini. Plašākam pieteikšanās skatam skat. kas ir autentifikācija.

Ikdienas analoģija

Domā par viesnīcas atslēgas karti. Reģistrācijas brīdī pieņemšanas darbinieks pārbauda, kas tu esi, tad iedod karti, kas atver tavu istabu un trenažieru zāli — ne citas istabas, ne darbinieku zonas — un pārstāj darboties izrakstīšanās brīdī. Karte nesatur tavu pasi. Ja to pazaudē, dienests to anulē un izsniedz jaunu.

• Pieņemšanas galds ir autorizācijas serveris (Google pieteikšanās lapa).
• Tava identitātes pārbaude ir tavs pieteikums Google.
• Atslēgas karte ir piekļuves marķieris.
• „Tikai istaba un trenažieru zāle” ir tvērumi, ko apstiprināji.
• Izrakstīšanās ir marķiera beigas vai tavs piekļuves atsaukums.

Lietotne, ko izmanto, nekad neredz tavu Google paroli, tikai atslēgas karti.

Kā darbojas OAuth soli pa solim

Visbiežākā plūsma tīmekļa lietotnēm ir autorizācijas koda plūsma. Te ir, kas notiek, kad lietotājs savieno savu Google kalendāru ar plānošanas lietotni:

1. Klikšķis. Lietotājs noklikšķina „Savienot Google kalendāru”.

2. Pāradresācija uz nodrošinātāju. Lietotne nosūta pārlūkprogrammu uz Google ar savu klienta ID, vēlamajiem tvērumiem (lasīt kalendāra notikumus) un pāradresācijas URI, kur Google jāatgriež lietotājs.

3. Pieteikšanās un piekrišana. Lietotājs pierakstās Google (ja vēl nav) un redz piekrišanas ekrānu ar sarakstu, ko lietotne prasa. Noklikšķina Allow.

4. Atpakaļ ar kodu. Google pāradresē pārlūkprogrammu uz lietotnes pāradresācijas URI ar īslaicīgu vienreizēju autorizācijas kodu.

5. Apmaiņa serverī. Lietotnes serveris nosūta šo kodu kopā ar klienta noslēpumu tieši Google un saņem piekļuves marķieri (un bieži atjaunošanas marķieri).

6. Izmantot API. Serveris izsauc Google Calendar API ar piekļuves marķieri un iegūst lietotāja notikumus.

7. soļa atzvanīšana izskatās apmēram šādi:

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

Un 5. soļa marķiera atbilde ir JSON šādā formā:

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

Svarīgs dizaina punkts: marķieru apmaiņa notiek serveris-serverim, tāpēc klienta noslēpumam un marķieriem nekad nav jāiet cauri pārlūkprogrammai.

OAuth pret OpenID Connect pret tavu pašu pieteikšanos

Daudzas lietotnes apvieno tos: e-pasta un paroles pieteikšanos, plus „Pierakstīties ar Google” caur OIDC, plus atsevišķus OAuth savienojumus ar citiem pakalpojumiem.

Galvenie termini

Biežākie maldīgi priekšstati

• „OAuth ir pieteikšanās sistēma.” Vienkāršs OAuth piešķir piekļuvi; OpenID Connect apstrādā identitāti. Izmantot kailu piekļuves marķieri kā pierādījumu, kas kāds ir, ir radījis reālas drošības kļūdas.
• „Lietotne saņem manu paroli.” Tā nekad nesaņem. Tieši tāds ir mērķis.
• „Vairāku tvērumu pieprasīšana ir nekaitīga.” Lietotāji ir piesardzīgāki pret plašiem pieprasījumiem, un nodrošinātāji, piemēram, Google, var prasīt lietotnes pārskatīšanu sensitīviem vai ierobežotiem tvērumiem. Pieprasi tikai to, kas vajadzīgs.
• „Klienta noslēpumu var ielikt frontend.” Viss pārlūkprogrammas kodā ir publisks. Glabā to servera puses noslēpumos.
• „Tas strādā testēšanā, tātad strādās produkcijā.” Nodrošinātāji bieži ierobežo neverificētas lietotnes — piemēram, uz uzskaitītiem testa lietotājiem —, un pāradresācijas URL tavam dzīvajam domēnam jāreģistrē atsevišķi.
• „Marķieri ilgst mūžīgi.” Piekļuves marķieri ātri beidzas, un lietotāji var atsaukt piekļuvi. Tavai lietotnei ar abiem jātiek galā labi.

Ko lūgt savam MI veidotājam

• „Pievieno „Pierakstīties ar Google”, izmantojot OpenID Connect ar labi uzturētu autentifikācijas bibliotēku — nerakstīt OAuth plūsmu pašam.”
• „Izmanto autorizācijas koda plūsmu ar PKCE un pārbaudi state parametru.”
• „Nolasi klienta ID un klienta noslēpumu no vides mainīgajiem serverī.”
• „Pieprasi tikai vajadzīgos tvērumus: tikai lasāmu kalendāra piekļuvi.”
• „Pastāsti man katru pāradresācijas URL, kas jāreģistrē nodrošinātāja konsolē — priekšskatījumam, publicētajam URL un manam pielāgotajam domēnam.”
• „Glabā atjaunošanas marķierus datubāzē šifrētus un apstrādā beigušos vai atsauktos marķierus, lūdzot lietotājam atkal savienoties.”
• „Ļauj lietotājiem atvienot integrāciju no sava iestatījumu lapas.”

OAuth un Mythex

Mythex nav iebūvētas galalietotāju pieteikšanās lietotnēm, ko veido; tā dokumentācija apraksta pašu atnestu pieeju — izvēlies autentifikācijas bibliotēku vai hostētu nodrošinātāju, glabā tā atslēgas kā projekta noslēpumus, un aģents raksta kodu. Pievienot autentifikāciju receptē ir sākuma uzvedne šim nolūkam. OAuth sastapsies arī pašā Mythex: vari pierakstīties ar Google, GitHub savienošana repozitorija sinhronizācijai izmanto GitHub OAuth, un MI klienti, kas savienojas ar Mythex caur MCP, iet caur OAuth piekrišanas lapu. Plašāk skat. kas ir autentifikācija un kas ir divfaktoru autentifikācija.

Jautājumi