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

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.