Suomi

OAuth
asiakas
julkinen
luottamuksellinen
PKCE

Mitä eroja on julkisten ja luottamuksellisten asiakkaiden välillä?

Tässä artikkelissa paljastetaan erot julkisten ja luottamuksellisten asiakkaiden välillä OAuthissa, Logto-sovelluksia esimerkkinä käyttäen.

Darcy Ye

Developer

2/21/2024

Lopeta viikkojen tuhlaaminen käyttäjien tunnistautumiseen

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

Aloita

Kun käytät Logtoa sovelluksen luomiseen, huomaat, että valittavana on useita erilaisia sovellustyyppejä, kuten yksi sivuinen sovellus (SPA), alkuperäinen sovellus ja perinteinen verkkosovellus. Intuitiivisesti nimestä on selvää, että alkuperäinen sovellus toimii käyttöjärjestel missä, joita yleisesti löytyy laitteista kuten puhelimista. Mutta mitä tarkalleen ottaen ovat SPA ja perinteinen verkkosovellus? Miksi meidän on erotettava nämä erilaiset sovellustyypit? Tässä artikkelissa paljastetaan vastaukset näihin kysymyksiin.

Ennen kuin aloitamme, meidän on annettava lyhyt johdanto muutamalle käsitteelle.

Mikä on OAuth?

OAuth on avoin standardi käyttöoikeuksien delegoimiseksi, jota käytetään tyypillisesti tapana intern etsivusten myöntää verkkosivustoille tai sovelluksille pääsy heidän tietoihinsa muilla verkkosivustoilla antamatta salasanojaan.

Viime vuosikymmenen aikana siitä on vähitellen tullut standardi valtuutusprosessi, jonka useimmat yritykset, kuten Google, Meta, Microsoft ja niin edelleen, ovat laajasti hyväksyneet. Nykyisin käytetty versio on OAuth 2.0.

OAuth-kontekstissa aiemmin mainittu sovellus tunnetaan nimellä Asiakas. He voivat tehdä pyyntöjä suojatuille resursseille, kunhan he ovat saaneet resurssin omistajan (yleensä loppukäyttäjien) valtuutuksen.

Julkiset asiakkaat ja luottamukselliset asiakkaat

OAuth määrittelee kaksi asiakastyyppiä, perustuen niiden kykyyn ylläpitää asiakastunnusten luottamuksellisuus.

Luottamuksellinen asiakas

Asiakas, joka pystyy ylläpitämään tunnustensa luottamuksellisuuden (esimerkiksi asiakas, joka on toteutettu turvallisella palvelimella rajoitetulla pääsyllä asiakastunnuksiin) tai joka pystyy turvaamaan asiakasautentikoinnin muilla keinoilla.

Julkinen asiakas

Asiakas, joka ei pysty ylläpitämään tunnustensa luottamuksellisuutta (esimerkiksi asiakas, joka toimii resurssin omistajan laitteessa, kuten alkuperäinen sovellus tai verkkopohjainen sovellus) eikä myöskään pysty tunnistautumaan turvallisesti asiakkaana muilla keinoilla.

SPA, alkuperäinen sovellus ja perinteinen verkkosovellus

Edellä mainitun taustatiedon perusteella tarkastellaan, mitä SPA, alkuperäinen sovellus ja perinteinen verkkosovellus tarkoittavat Logton kontekstissa sekä ovatko ne julkisia asiakkaita vai luottamuksellisia asiakkaita.

SPA

SPA:n asiakaspuolen koodi ladataan web-palvelimelta ja suoritetaan resurssin omistajan laitteessa käyttäjän agentissa (kuten verkkoselaimessa). Protokollatiedot ja tunnukset ovat helposti saatavilla (ja usein näkyviä) resurssin omistajalle.

Alkuperäinen sovellus

Alkuperäinen sovellus asennetaan ja suoritetaan resurssin omistajan laitteessa. Protokollatiedot ja tunnukset ovat saatavilla resurssin omistajalle. Yleisesti oletetaan, että kaikki sovelluksessa olevat asiakastunnukset voidaan purkaa.

Perinteinen verkkosovellus

Perinteinen verkkosovellus on asiakas, joka toimii web-palvelimella. Resurssin omistaja käyttää asiakasta HTML-käyttöliittymän kautta, joka esitetään käyttäjän agentissa heidän laitteellaan. Asiakastunnukset ja mahdolliset asiakkaalle myönnetyt käyttöoikeudutokentat tallennetaan web-palvelimelle eivätkä ole paljastettuja tai resurssin omistajan saatavilla.

Joten voimme selvästi nähdä, että SPA ja alkuperäinen sovellus ovat julkisia asiakkaita, kun taas perinteinen verkkosovellus on luottamuksellinen asiakas.

Huomaat, että kun luodaan SPA tai alkuperäinen sovellus Logtossa, ei ole sovellussalaisuutta, kun taas perinteisellä verkkosovelluksella on sekä sovellustunnus että sovellussalaisuus. Tämä johtuu siitä, että julkisen asiakkaan salaisuutta ei voida taata turvalliseksi.

Miten asiakas toimii OAuth-valtuutusprosessissa?

Kun kehität OAuth-sovelluksia, ensimmäinen askel on rekisteröidä asiakas OAuth-palveluntarjoajan kanssa. Asiakasrekisteröinti sisältää tietojen antamisen sovelluksesta, kuten sen nimestä ja uudelleenohjaus-URL:stä. Sitten OAuth-palveluntarjoaja luo asiakastunnuksen ja asiakassalaisuuden, joita pidetään sovelluksen tunnuksina.

Asiakastunnusta pidetään julkisena tietona ja se jaetaan käyttäjän kanssa OAuth-prosessin aikana. Se sisällytetään tyypillisesti valtuutus URL:ään ja on näkyvissä loppukäyttäjille.

Toisaalta asiakassalaisuus toimii sovelluksen salasanana ja se on pidettävä salassa. Sitä käytetään OAuth-prosessissa vaihtamaan valtuutuskoodi (edellyttäen, että kyseessä on valtuutuskoodivirta) käyttöoikeustunnuksen saamiseksi. Asiakassalaisuuksien olemassaolo varmistaa, että vain rekisteröidyt sovellukset voivat suorittaa käyttöoikeustunnusten vaihdon.

Proof Key for Code Exchange (PKCE) -esittely

Kuten aiemmin mainittiin, julkisten asiakkaiden asiakassalaisuuksia ei voida taata turvallisiksi, ja hyökkääjät voivat saada asiakastunnukset ja esiintyä asiakkaina päästäkseen suojattuihin resursseihin, mikä ei ole hyväksyttävää missään tilanteessa.

PKCE (Proof Key for Code Exchange) ratkaisee tämän ongelman luomalla tilapäisesti kooditarkistimen jokaisen valtuutusprosessin alussa, joka tallennetaan paikallisesti ja hash-käsitellään koodikokeen luomiseksi, joka lähetetään valtuutuspalvelimelle. Kooditarkistin lähetetään uudelleen valtuutuspalvelimelle käyttöoikeustunnusta vaihdettaessa. Valtuutuspalvelin tarkistaa, että kooditarkistin ja koodikoe vastaavat toisiaan, mikä varmistaa, ettei julkista asiakasta ole esitetty luvattomasti.

PKCE:n kooditarkistimen toiminta on itse asiassa kuin dynaaminen asiakassalaisuus. Sen turvallisuus varmistetaan hash-algoritmin peruuttamattomuudella.

Yhteenveto

Tässä artikkelissa käsittelimme käsitteitä luottamuksellisista ja julkisista asiakkaista OAuthissa. Opimme, että luottamuksellisilla asiakkailla on kyky säilyttää salaisuudet ja tallentaa arkaluonteista tietoa turvallisesti, kun taas julkisilta asiakkailta puuttuu tämä kyky. Tutkimme esimerkkejä näistä kahdesta asiakastyypistä, mukaan lukien perinteiset verkkosovellukset, SPA:t ja alkuperäiset sovellukset, Logton sovellus käytäntöjä kontekstissa.

Käsittelimme myös asiakastietojen rekisteröintiprosessia OAuthissa ja asiakastunnuksen sekä asiakassalaisuuden rooleja.

Lisäksi havaitsimme, että julkisilla asiakkailla on rajoituksia asiakassalaisuuksien turvallisessa säilyttämisessä. Tämän rajoituksen voittamiseksi esittelimme PKCE:n (Proof Key for Code Exchange), OAuth-laajennuksen, joka mahdollistaa julkisten asiakkaiden turvallisen valtuutuskoodien vaihdon ilman asiakassalaisuutta.

Tuotteemme, Logto, on kattava CIAM-ratkaisu, joka noudattaa OAuth- ja OIDC-protokollien parhaita käytäntöjä varmistaen turvallisuuden jokaisessa vaiheessa, mukaan lukien PKCE:n käyttöönotto julkisten asiakkaiden turvallisuuden suojaamiseksi.

Kokeile Logtoa ilmaiseksi

Mikä on OAuth?#

Julkiset asiakkaat ja luottamukselliset asiakkaat#

Luottamuksellinen asiakas#

Julkinen asiakas#

SPA, alkuperäinen sovellus ja perinteinen verkkosovellus#

SPA#

Alkuperäinen sovellus#

Perinteinen verkkosovellus#

Miten asiakas toimii OAuth-valtuutusprosessissa?#

Proof Key for Code Exchange (PKCE) -esittely#

Yhteenveto#

Mikä on OAuth?#

Julkiset asiakkaat ja luottamukselliset asiakkaat#

Luottamuksellinen asiakas#

Julkinen asiakas#

SPA, alkuperäinen sovellus ja perinteinen verkkosovellus#

SPA#

Alkuperäinen sovellus#

Perinteinen verkkosovellus#

Miten asiakas toimii OAuth-valtuutusprosessissa?#

Proof Key for Code Exchange (PKCE) -esittely#

Yhteenveto#

Mikä on OAuth?

Julkiset asiakkaat ja luottamukselliset asiakkaat

Luottamuksellinen asiakas

Julkinen asiakas

SPA, alkuperäinen sovellus ja perinteinen verkkosovellus

SPA

Alkuperäinen sovellus

Perinteinen verkkosovellus

Miten asiakas toimii OAuth-valtuutusprosessissa?

Proof Key for Code Exchange (PKCE) -esittely

Yhteenveto

Mikä on OAuth?

Julkiset asiakkaat ja luottamukselliset asiakkaat

Luottamuksellinen asiakas

Julkinen asiakas

SPA, alkuperäinen sovellus ja perinteinen verkkosovellus

SPA

Alkuperäinen sovellus

Perinteinen verkkosovellus

Miten asiakas toimii OAuth-valtuutusprosessissa?

Proof Key for Code Exchange (PKCE) -esittely

Yhteenveto