Implicit piešķīruma veids OAuth 2.0

Implicit piešķīruma veids, pazīstams arī kā "token" metode, galvenokārt bija izstrādāts klienta puses lietotnēm, kur klients nevar droši glabāt klienta noslēpumu. Šādas lietotnes ietver vienas lapas lietotnes (SPA) vai citas pārlūkprogrammā bāzētas lietotnes. Tā vietā, lai saņemtu autorizācijas kodu, kas jāapmaina pret piekļuves marķieri, lietotne iegūst piekļuves marķieri tieši.

Kā darbojas Implicit piešķīruma veids?

1. Novirzīšana:

• Klienta lietotne novirza lietotāju uz OAuth 2.0 autorizācijas servera autorizācijas galapunktu. Šī novirzīšana parasti ietver vaicājuma parametrus, piemēram, client_id, response_type (iestatīts uz "token" Implicit piešķīrumam), redirect_uri (kur autorizācijas serveris novirzīs pēc piekļuves piešķiršanas/noraidīšanas) un scope (norādot pieprasīto piekļuves līmeni).

2. Lietotāja autentifikācija:

• Lietotājs piesakās autorizācijas serverī (ja vēl nav pieteicies) un pārskata klienta lietotnes piekļuves pieprasījumu.

3. Piekļuves marķiera izsniegšana:

• Ja lietotājs piešķir piekļuvi, autorizācijas serveris novirza viņu atpakaļ uz klienta lietotni, izmantojot norādīto redirect_uri. Novirzīšanas URI ietver piekļuves marķieri (un tā derīguma termiņu) tieši URL fragmenta daļā.

4. Piekļuve aizsargātajam resursam:

• Klienta lietotne iegūst piekļuves marķieri no URL fragmenta un to saglabā (piemēram, lokālajā krātuvē vai sesijā). Pēc tam tā izmanto šo marķieri, lai veiktu pieprasījumus resursu serverim (API) lietotāja vārdā.

Kā konfigurēt Implicit piešķīruma veidu?

1. Reģistrējiet savu lietotni:

• Sāciet, reģistrējot savu lietotni pie OAuth 2.0 pakalpojumu sniedzēja. Pēc veiksmīgas reģistrācijas jūs parasti saņemsiet client_id.

2. Novirzīšanas URI iestatīšana:

• Norādiet redirect_uri reģistrācijas laikā. Autorizācijas serveris novirzīs lietotājus uz šo URI pēc tam, kad tie izlems par piekļuves piešķiršanu vai noraidīšanu. Pārliecinieties, ka šis URI ir drošs (parasti izmantojot HTTPS) un var apstrādāt marķiera iegūšanu no URL fragmenta.

3. OAuth plūsmas uzsākšana:

• Novirziet lietotājus uz autorizācijas servera autorizācijas galapunktu ar nepieciešamajiem parametriem. Izmantojiet bibliotēkas vai SDK, kas piemērotas jūsu lietotnes valodai vai ietvaram.

4. Marķiera iegūšana un glabāšana:

• Pēc novirzīšanas atpakaļ iegūstiet piekļuves marķieri no URL fragmenta. Glabājiet marķieri droši, apsverot klienta puses glabāšanas iespējas, piemēram, Web Storage (localStorage vai sessionStorage) vai sīkdatnes. Nodrošiniet, ka tas ir aizsargāts pret starpvietņu skriptēšanas (XSS) uzbrukumiem.

5. Marķiera izmantošana:

• Pievienojiet piekļuves marķieri API pieprasījumiem, kas tiek veikti resursu serverim.

6. Marķiera derīguma termiņa apstrāde:

• Tā kā Implicit piešķīrums parasti nenodrošina atsvaidzināšanas marķierus, kad piekļuves marķieris beidzas, jums var būt nepieciešams atkārtoti uzsākt OAuth plūsmu, lai iegūtu jaunu.

Apsvērumi:

• Drošība: Implicit piešķīruma veids tiek uzskatīts par mazāk drošu nekā Authorization Code piešķīruma veids, jo īpaši tāpēc, ka piekļuves marķieris ir atklāts URL. Tas var būt risks vidēs, kur URL var tikt žurnalēti vai pieejami trešajām pusēm.

• Nav atsvaidzināšanas marķiera: Parasti Implicit piešķīrums nenodrošina atsvaidzināšanas marķierus. Tāpēc, kad piekļuves marķieris beidzas, visa plūsma var būt jāatkārto.

• Novecošana: Iekšējo drošības problēmu dēļ OAuth 2.0 drošības labākās prakses dokuments iesaka izvairīties no Implicit piešķīruma par labu Authorization Code ar PKCE (Proof Key for Code Exchange) publiskiem klientiem, piemēram, SPA.

Secinājums:

Lai arī Implicit piešķīruma veids piedāvā vienkāršāku plūsmu klienta puses lietotnēm, tā drošības problēmas ir novedušas pie ieteikumiem neizmantot to modernās lietotnēs. Ja veidojat jaunas lietotnes, īpaši SPA, apsveriet Authorization Code piešķīruma ar PKCE izmantošanu drošākai pieejai.