Mikä on PKCE: peruskäsitteistä syvälliseen ymmärrykseen

Tässä artikkelissa selitetään, kuinka PKCE (Proof Key for Code Exchange) suojaa OAuth 2.0 -valtuutuskoodivirtaa estämällä haitallisia sovelluksia sieppaamasta valtuutuskoodeja, vieden sinut peruskäsitteistä kattavaan ymmärrykseen.

Yijun

Developer

7/28/2023

Lopeta viikkojen tuhlaaminen käyttäjien tunnistautumiseen

Julkaise turvallisia sovelluksia nopeammin Logtolla. Integroi käyttäjien tunnistautuminen minuuteissa ja keskity ydintuotteeseesi.

Aloita

Proof Key for Code Exchange (PKCE) on laajennus valtuutuskoodivirralle, se suunniteltiin alun perin suojaamaan valtuutuskoodivirtaa mobiilisovelluksissa, ja nyt se suositellaan myös yksisivuisille sovelluksille. OAuth 2.1 -standardista lähtien, PKCE on pakollinen kaikille asiakastyypeille, mukaan lukien julkiset asiakkaat ja luottamukselliset (yksityiset) asiakkaat.

Tässä artikkelissa autamme sinua ymmärtämään, miksi PKCE luotiin ja miten se suojaa sovelluksiasi, antaen sinulle syvällisen ymmärryksen PKCE:stä.

Miksi PKCE on tarpeen?

OAuth 2.0 -valtuutuskoodivirrassa käyttäjät pyytävät kirjautumista sovelluksen kautta. Autentikointipalvelin ohjaa käyttäjät autentikointisivulle. Käyttäjän todennuksen jälkeen palvelin palauttaa valtuutuskoodin sovellukselle, joka sitten käyttää tätä koodia pyytääkseen käyttölupatunnuksen autentikointipalvelimelta.

Tässä virrassa on merkittävä tietoturvariski: valtuutuskoodi voidaan siepata haittaohjelmien toimesta. Tämä on erityisen huolestuttavaa mobiililaitteissa, joissa muut sovellukset voivat rekisteröidä saman uudelleenohjaus URI:n ja siepata valtuutuskoodin.

Sieppausprosessi on esitetty alla olevassa kaaviossa:

Vaihe (1): Sovellus suorittaa valtuuspyynnön turvallisen API:n kautta, jota ei voida siepata. Tässä vaiheessa pyytäjä antaa myös uudelleenohjaus URI:n.

Vaihe (2): Pyyntö välitetään OAuth 2.0 -valtuutuspalvelimelle. Koska OAuth vaatii TLS:n käyttöä, tämä viestintä on suojattu TLS:llä eikä sitä voida siepata.

Vaihe (3): Valtuutuspalvelin palauttaa valtuutuskoodin.

Vaihe (4.a): valtuutuskoodi palautetaan pyytäjälle vaiheessa (1) annetun uudelleenohjaus URI:n kautta. Tässä vaiheessa, jos haitallinen sovellus on rekisteröinyt itsensä uudelleenohjaus URI:lle käsittelijäksi, se voi siepata valtuutuskoodin. Valtuutuskoodilla hyökkääjä voi pyytää ja saada käyttölupatunnuksen vaiheissa (5.a) ja (6.a).

Kuten yllä on esitetty, OAuth 2.0 -valtuutuskoodivirrassa, jos valtuutuskoodi siepataan, hyökkääjät voivat käyttää sitä saadakseen käyttölupatunnuksia. Siksi tarvitsemme mekanismin estämään valtuutuskoodin sieppauksen, mikä johti PKCE:n luomiseen.

Kuinka PKCE toimii?

Kuten edellä mainittiin, jos haluamme estää hyökkäyksiä, meidän on varmistettava, että vain pyyntön tehnyt sovellus voi pyytää ja saada käyttölupatunnuksen. Tässä PKCE astuu peliin.

PKCE ratkaisee tämän ongelman tuomalla "todistusavain"-konseptin.

Kun valtuutuskoodia pyydetään, sovellus luo ensin satunnaisen "koodin varmistajan" ja tallentaa sen paikallisesti. Se muuntaa tämän varmistajan koodikahdeksi tiettyjen algoritmien avulla. Sovellus lähettää sekä koodikahden että koodihaasteen menetelmän autentikointipalvelimelle valtuutuskoodipyyntöä tehdessään.

Koodin varmistaja on satunnaisesti luotu merkkijono, ja koodikahde saadaan varmistajasta muunnon kautta. Kaksi muunnosmenetelmää tuetaan:

plain: Käyttää koodin varmistajaa suoraan koodikahteena

S256: Soveltaa SHA-256 -tiivistämistä koodin varmistajaan, jota seuraa Base64URL-koodaus. Koska tiivisteen tulosta ei voida palauttaa koodin varmistajaksi, ja koska plain-menetelmä voi olla haavoittuva man-in-the-middle -hyökkäyksille lähetyksen aikana, S256:n käyttö on vahvasti suositeltavaa turvallisuussyistä.

Käyttäjän tunnistautumisen jälkeen autentikointipalvelin palauttaa valtuutuskoodin sovellukselle. Kun pyydetään käyttölupatunnusta, sovellus lähettää sekä valtuutuskoodin että koodin varmistajan autentikointipalvelimelle. Palvelin muuntaa "koodin varmistajan" käyttämällä aiemmin saatua "koodihaasteen menetelmää" ja vertaa tulosta aiemmin saatuun "koodikahteen" vahvistaakseen asiakkaan hallussa olevan "koodin varmistajan".

Vaihe (1-3): Sovellus luo ja tallentaa salaisuuden nimeltä "koodin varmistaja" ja johdetun version "koodikahde", joka lähetetään OAuth 2.0 -valtuutuspöynnön mukana muunnosmenetelmän "koodihaasteen menetelmä" kanssa.

Vaihe (3-6): Autentikointipalvelin vastaa tavallisesti, mutta tallentaa "koodikahteen" ja "koodihaasteen menetelmän".

Vaihe (7.a): Sovellus lähettää sitten valtuutuskoodin tokenpäätepisteeseen tavallisesti, mutta sisältää "koodin varmistaja" -salaisuuden, joka luotiin vaiheessa (1).

Vaihe (8.a-9.a): Valtuutuspalvelin muuttaa "koodin varmistajan" "koodikahdeksi" ja vertaa sitä "koodikahteeseen" vaiheesta (1-3). Pääsy evätään, jos ne eivät ole yhtäsuuret.

Tässä tapauksessa, vaikka haitallinen sovellus on siepannut valtuutuskoodin vaiheessa (6.b), se ei pysty vaihtamaan sitä käyttölupatunnukseen, koska sillä ei ole hallussaan "koodin varmistaja" -salaisuutta, ja koska "koodin varmistaja" lähetetään TLS:n kautta, sitä ei voi siepata.

Yhteenveto

Tässä artikkelissa selitetään, kuinka PKCE toimii ja miksi se on välttämätön valtuutuskoodivirran suojaamiseksi. Lisäämällä todistusavainmekanismin, PKCE estää haitallisia sovelluksia sieppaamasta ja väärinkäyttämästä valtuutuskoodeja. Toivottavasti tämä selitys auttaa sinua ymmärtämään PKCE:tä syvällisesti.

Kokeile Logtoa tänään

Miksi PKCE on tarpeen?#

Kuinka PKCE toimii?#

Yhteenveto#

Miksi PKCE on tarpeen?#

Kuinka PKCE toimii?#

Yhteenveto#

Miksi PKCE on tarpeen?

Kuinka PKCE toimii?

Yhteenveto

Miksi PKCE on tarpeen?

Kuinka PKCE toimii?

Yhteenveto