OAuth 2.1 on täällä: Mitä sinun täytyy tietää

Johdanto#

Koska OAuth 2.0 (RFC 6749) julkaistiin vuonna 2012, verkko- ja mobiilisovellusten maailma on muuttunut paljon. Ihmiset siirtyvät pöytätietokoneilta mobiililaitteisiin, ja Single Page Applications (SPA) ovat nyt trendikkäitä. Olemme myös nähneet kasapäin uusia kehyksiä ja web-teknologioita nousemassa esiin. Kaikkien näiden muutosten myötä tietoturvahaasteet ovat lisääntyneet. Pysyäksemme uusimpien verkkoteknologioiden mukana on julkaistu jatkuvasti uusia RFC:itä, kuten Proof Key for Code Exchange (PKCE), parantamaan OAuth 2.0:aa. On käynyt tärkeäksi koota kaikki parhaat käytännöt tämän päivän tietoturvavaatimuksiin, ja siksi OAuth 2.1 on tulossa.

Tulevassa OAuth 2.1:ssä OAuth-työryhmä pyrkii kokoamaan kaikki parhaat käytännöt ja tietoturvasuositukset yhteen asiakirjaan. Logtossa pysyttelemme ajan tasalla uusimmista OAuth-standardeista ja parhaista käytännöistä. Tässä artikkelissa tutkimme tärkeimmät erot OAuth 2.0:n ja OAuth 2.1:n välillä ja miten ne on otettu käyttöön Logtossa.

PKCE vaaditaan nyt kaikille OAuth-asiakkaille, jotka käyttävät Authorization Code -virtaa#

Yksi merkittävimmistä muutoksista OAuth 2.1:ssä on se, että Proof Key for Code Exchange (PKCE) vaaditaan nyt kaikille OAuth-asiakkaille, jotka käyttävät Authorization Code -virtaa. PKCE on tietoturvalaajennus, joka estää valtuutuskoodin sieppausiskut. Se on erityisesti hyödyllinen mobiili- ja yksisivuisissa sovelluksissa (SPA), joissa asiakkaan salaisuutta ei voi tallentaa turvallisesti.

OAuth-asiakkaat voidaan luokitella kahteen eri tyyppiin perustuen niiden kykyyn säilyttää salaisuudet turvallisesti:

1. Luottamukselliset asiakkaat: Nämä asiakkaat voivat säilyttää salaisuudet turvallisesti, kuten palvelinpohjaiset verkkosovellukset ja verkkopalvelimet. Kaikki valtuutukseen liittyvät pyynnöt tehdään palvelimen puolella, ja asiakkaan salaisuuden paljastumisriski on pieni.

2. Julkiset asiakkaat: Nämä asiakkaat eivät voi säilyttää salaisuuksia turvallisesti, kuten mobiilisovellukset ja SPA:t. Asiakkaan salaisuus voidaan helposti purkaa asiakaspään koodista, ja on vaikea suojata sitä hyökkääjiltä.

Julkisille asiakkaille PKCE on välttämätön tietoturvatoimenpide. Se varmistaa, että valtuutuskoodia voi vaihtaa vain asiakkaan kanssa, joka käynnisti valtuutuspyynnön.

PKCE toimii generoimalla satunnaisen koodin tarkastajan ja koodin haasteen, joka perustuu koodin tarkastajaan. Koodin tarkastaja lähetetään valtuutuspalvelimelle, ja koodin haastetta käytetään tarkastajan tarkistamiseen, kun valtuutuskoodia vaihdetaan käyttöoikeustunnukseen.

OAuth 2.1:ssä PKCE:stä tulee pakollinen kaikille OAuth-asiakkaille, jotka käyttävät Authorization Code -virtaa, riippumatta niiden luottamuksellisuustilasta - olipa kyseessä luottamuksellinen tai julkinen asiakas. Tämä keskeinen muutos varmistaa yleisen suojan mahdollisilta valtuutuskoodin sieppausiskuilta.

Logtossa PKCE-tarkastusvirta aktivoidaan automaattisesti sekä julkisille että luottamuksellisille asiakkaille.

SPA:ille ja mobiilisovelluksille PKCE on välttämätön tietoturvatoimenpide suojelemaan valtuutuskoodivirtaa Logtossa. Kaikki valtuutuspyynnöt ilman koodin haastetta Logton valtuutuspalvelin hylkää välittömästi.

Luottamuksellisten asiakkaiden (perinteiset verkkosovellukset) osalta, paremman yhteensopivuuden varmistamiseksi, Logto sallii edelleen koodin haasteen poisjättämisen valtuutuspyynnössä. Suosittelemme kuitenkin voimakkaasti luottamuksellisille asiakkaille PKCE:n käyttöönottoa lisäämällä koodin haasteen valtuutuspyyntöön, julkisten asiakkaiden käytäntöjen mukaisesti.

Uudelleenohjaus-URI:iden tarkka täsmäys#

Uudelleenohjaus-URI (Uniform Resource Identifier) on tietty päätepiste tai URL, johon valtuutuspalvelin ohjaa käyttäjän takaisin todennus- ja valtuutusprosessin jälkeen.

OAuth-virran aikana asiakassovellus sisältää uudelleenohjaus-URI:n osana alkuperäistä valtuutuspyyntöä. Kun käyttäjä suorittaa todennusprosessin, valtuutuspalvelin luo vastauksen, joka sisältää valtuutuskoodin, ja ohjaa käyttäjän takaisin määritettyyn uudelleenohjaus-URI:seen. Kaikki poikkeamat alkuperäisestä uudelleenohjaus-URI:stä johtavat koodin tai tunnuksen vuotoon.

Uudelleenohjaus-URI:iden tarkan merkkijonon täsmäytyksen esiteltiin ensimmäisen kerran OAuth 2.0 Security Best Current Practices osiossa 4.1. Tämä käytäntö varmistaa, että uudelleenohjaus-URI:n on vastattava täsmälleen sitä, mikä on rekisteröity valtuutuspalvelimen kanssa. Kaikki poikkeamat rekisteröidystä uudelleenohjaus-URI:stä aiheuttavat virhevastausta.

Olemme saaneet lukuisia yhteisön pyyntöjä koskien jokerimerkkiyhteensopivuuden toteuttamista uudelleenohjaus-URI:ille. Vaikka jokerimerkkiyhteensopivuus voi tarjota kätevyyttä kehittäjille, jotka hallitsevat useita alitoimialueita tai polkuja, erityisesti suuren määrän satunnaisten alitoimialueiden kanssa, se myös tuo mukanaan tietoturvariskejä, kuten avoimia uudelleenohjaushyökkäyksiä. Käytännön havainnollistuksen vaaroista, joita aiheutuu puuttuvasta uudelleenohjaus-URI:n validoinnista, tutustu blogikirjoitukseemme Lyhyt OAuth-tietoturvayhteenveto.

OAuth 2.1:n tarkkojen tietoturvastandardien mukaisesti Logto käyttää uudelleenohjaus-URI:iden tarkkaa merkkijonotäsmäyttä. Tämä päätös priorisoi OAuth-virran tietoturvaa. Sen sijaan, että käytettäisiin jokerimerkkiyhteensopivuutta, kannustamme kehittäjiä rekisteröimään kaikki mahdolliset uudelleenohjaus-URI:t Logton valtuutuspalvelimen kanssa. Tämä varmistaa uudelleenohjaus-URI:iden perusteellisen tarkistamisen ja auttaa vähentämään mahdollisia tietoturvahaavoittuvuuksia.

Epäsuora virta on poistettu#

OAuth 2.0:ssa epäsuoravirtamalli suunniteltiin SPA:ille, joissa käyttöoikeustunnus palautetaan suoraan URL-fragmentissa käyttäjän todentamisen jälkeen. Tämä menetelmä oli kätevä, koska se vältti ylimääräisen tunnusvaihdon, jolloin asiakas sai tunnuksen suoraan.

Tällä kätevyydellä on kuitenkin haittoja. Käyttöoikeustunnus voi paljastua luvattomille osapuolille selaimen historiassa, viitetunnisteissa tai muilla keinoilla, mikä helpottaa tietoturvaloukkausten ilmenemistä - erityisesti, kun käyttöoikeustunnukset pysyvät voimassa pitkään. Esimerkiksi, jos valtuutuspyyntö siepataan haitallisen toimijan toimesta, he voivat helposti purkaa käyttöoikeustunnuksen URL-fragmentista ja esiintyä käyttäjänä.

OAuth 2.0 Security Best Current Practices-asiakirjassa todetaan selvästi, että:

Asiakkaiden EI TULE käyttää epäsuoraa valtuutusta (vastetyyppi "token") tai muita vastetyyppejä, jotka myöntävät käyttöoikeustunnuksia valtuutusvastauksessa.

Näin ollen epäsuoravirta on virallisesti poistettu OAuth 2.1 -määrityksestä.

Logtossa valtuutuskoodivirta PKCE:n kanssa on ainoa tuettu virtaus SPA:ille ja mobiilisovelluksille. Valtuutuskoodivirta tarjoaa turvallisemman tavan saada käyttöoikeustunnuksia vaihtamalla valtuutuskoodin.

Resurssin omistajan salasanavaltuutus (ROPC) on poistettu#

Resurssin omistajan salasanavaltuutus (ROPC) antaa asiakkaalle mahdollisuuden vaihtaa käyttäjän käyttäjätunnuksen ja salasanan käyttöoikeustunnukseen. Se esiteltiin ensin OAuth 2.0 -määrityksessä tukemaan vanhoja sovelluksia, kuten HTTP-perustodennusta tai vanhoja natiiveja sovelluksia, jotka eivät voineet käyttää turvallisempia OAuth-virtoja.

ROPC-tyyppi on merkitty ei-suositelluksi OAuth 2.0 -määrityksessä tietoturvariskien vuoksi. Käyttäjän tunnisteet paljastuvat asiakassovellukselle, mikä voi johtaa mahdollisiin tietoturvaloukkauksiin. Asiakassovellus voi tallentaa käyttäjän tunnisteet, ja jos asiakas altistuu haitalliselle toimijalle, käyttäjän tunnisteet voivat paljastua hyökkääjille.

Myöhemmin, OAuth 2.0 Security Best Current Practices -osassa 2.4, ROPC-tyypin käytön kieltäminen korostettiin edelleen niin, että SUURIN EI TULE käyttää sitä. Tämän seurauksena ROPC-tyyppi on poistettu OAuth 2.1 -määrityksestä.

Korkeat tietoturvariskit huomioon ottaen Logto ei ole koskaan tukenut sitä. Jos käytät edelleen suorien käyttäjäkredentiaalien virtaa vanhoissa sovelluksissasi, suosittelemme voimakkaasti siirtymään turvallisempaan menetelmään, kuten valtuutuskoodivirtaan tai asiakaskredentiaalien valtuutukseen. Logto tarjoaa erilaisia SDK:ita ja oppaita auttaakseen sinua integroimaan nämä turvalliset OAuth-virtaukset sovelluksiisi vaivattomasti.

Ymmärrämme, että kehittäjät voivat haluta suunnitella tai isännöidä itse omaa käyttäjän kirjautumisrajapintaansa parhaan tuotekokemuksen saavuttamiseksi. Logtossa tarjoamme laajan valikoiman sisäänkirjautumiskokemuksen (SIE) muokkausvaihtoehtoja, mukaan lukien brändäysasetukset ja mukautettu CSS. Lisäksi meillä on useita käynnissä olevia projekteja, kuten oma käyttöliittymä ja suora sisäänkirjautuminen, tarjotaksemme enemmän joustavuutta kehittäjille tuoda oma sisäänkirjautumisrajapintansa säilyttäen OAuth-virran tietoturvan.

Yhteenveto#

OAuth 2.1 on uusin päivitys OAuth-protokollaan, ja se on suunnattu vastaamaan tämän päivän tietoturvahaasteisiin samalla, kun se katsoo nykyisten verkko- ja mobiilisovellusten tarpeisiin. OAuth-työryhmä päivittää ja tarkentaa aktiivisesti OAuth 2.1:tä varmistaakseen, että se täyttää viimeisimmät tietoturvastandardit ja parhaat käytännöt. Viimeisin luonnos, OAuth 2.1 11, julkaistiin toukokuussa 2024, mikä merkitsee merkittävää edistymistä kohti sen viimeistelyä. Laajan käyttöönoton ollessa näköpiirissä suosittelemme kaikille noudattamaan OAuth 2.1:ssä esitettyjä parhaita käytäntöjä tietoturvan parantamiseksi ja käyttäjäkokemuksen parantamiseksi.