Desktop- og mobilappene er innebygde nettlesere i appen for å hjelpe til med å fullføre hele OAuth 2.0-prosessen
Prosessen er vist i figuren
OAuth2.0 web
1) Returner autentiseringskoden til den spesifiserte Web redirectUri (denne URI-en konfigureres av apputvikleren)
2) For å endre tokenet må du sende clientId og clientSecret for å verifisere klientidentiteten (innhentet av applikasjonens backend-tjeneste)
Med henvisning til de to punktene ovenfor,
1) Fordi ikke webappens omdirigeringsURI-deteksjon er ugyldig
2) Fordi det ikke finnes noen backend-tjenesteklient, er ikke Secret sikker
Da kan angrepet vi kan møte er som vist i figuren under, det kan være en ondsinnet applikasjon som avlytter autentiseringskoden for å sende en melding til AuthorizationServer for å hente tokenet, slik at tokenet blir hentet uten kundens autorisasjon til applikasjonen, men til en annen offisiell applikasjonsautorisasjon, og dermed oppnås formålet med angrepet.
Løsning:
1. Klienten genererer en tilfeldig streng: kodeverifikator og lagrer denne tilfeldige strengen
code_challenge = transform(code_verifier, [Plain| S256])
Hvis transformasjonsmetoden er plain, er kodeutfordring ekvivalent med kodeverifikator
Hvis transformasjonsmetoden er S256, er kodeutfordringen lik Sha256-hashen til kodeverifikatoren
2. Ta med en kodeutfordring til autorisasjonskodeforespørselen og hvordan man genererer en kodeutfordring. Disse to er bundet til autorisasjonskoden utstedt av serveren
3. Etter å ha fått autorisasjonskoden, henter klienten den opprinnelig genererte kodeverifikatoren når autorisasjonskoden byttes ut med tilgangstokenet. Serveren beregner kodeverifikatoren i henhold til bound transform-metoden, sammenligner det beregnede resultatet med bound code-utfordringen, og utsteder en Access Token hvis den er konsistent. |
Publisert på 28.11.2020 20:51:48
|
|
|
|
