Työpöytä- ja mobiilisovellukset ovat upotettuja selaimia, jotka auttavat koko OAuth 2.0 -prosessin suorittamisessa
Prosessi on esitetty kuvassa
OAuth2.0 web
1) Palauta authCode määritettyyn Web redirectUriin (tämän URI:n määrittää sovelluskehittäjä)
2) Tokenin vaihtamiseksi sinun täytyy välittää clientId ja clientSecret varmistaaksesi asiakashenkilöllisyyden (jonka sovelluksen taustapalvelu on saanut)
Huomioiden yllä olevat kaksi kohtaa,
1) Koska web-sovelluksen uudelleenohjausUri-tunnistus ei ole virheellinen
2) Koska backend-palvelua ei ole, asiakas ei ole turvallinen
Sitten kohtaamme hyökkäyksen, kuten alla olevassa kuvassa näkyy, saattaa olla haitallinen sovellus, joka sieppaa authCodea lähettääkseen viestin AuthorizationServerille tokenin saamiseksi, jolloin token saadaan ilman asiakkaan lupaa sovellukseen mutta toiseen viralliseen sovelluksen valtuutukseen, jolloin hyökkäyksen tarkoitus saavutetaan.
Ratkaisu:
1. Asiakas generoi satunnaisen merkkijonon: code verifierin ja tallentaa tämän satunnaisen merkkijonon
code_challenge = transform(code_verifier, [Plain| S256])
Jos muunnosmenetelmä on yksinkertainen, koodihaaste on ekvivalentti koodin varmentajan kanssa
Jos muunnosmenetelmä on S256, niin koodihaaste on yhtä suuri kuin koodin varmentajan Sha256-tiiviste
2. Tuo koodihaaste valtuutuskoodipyyntöön ja siihen, miten koodihaaste luodaan. Nämä kaksi ovat sidottuja palvelimen myöntämään valtuutuskoodiin
3. Valtuutuskoodin saatuaan asiakas tuo alun perin luodun koodin tarkistajan vaihtaessaan valtuutuskoodin Access Tokeniin. Palvelin laskee koodin varmentajan sidotun muunnosmenetelmän mukaan, vertaa laskettua tulosta sidotun koodin haasteeseen ja myöntää Access Tokenin, jos se on johdonmukainen. |
Julkaistu 28.11.2020 20.51.48
|
|
|
|
