Miksi sinun pitäisi vanhentaa Resource Owner Password Credentials (ROPC) -hyväksyntätyyppi

Johdanto#

Resource Owner Password Credentials (ROPC) -hyväksyntätyyppi, eli salasana-hyväksyntätyyppi, on OAuth 2.0 -prosessi, joka sallii sovelluksen vaihtavan käyttäjän käyttäjänimen ja salasanan käyttöoikeustunnukseen. Se esiteltiin ensimmäisen kerran OAuth 2.0 -määrityksessä tukemaan vanhoja sovelluksia, kuten HTTP-perusautentikointia tai vanhoja natiivisovelluksia, jotka eivät voineet käyttää turvallisempia OAuth-tunnuspohjaisia prosesseja.

Kuitenkin ROPC-hyväksyntätyyppi aiheuttaa useita turvallisuusriskejä ja on merkitty EI SAA käyttää OAuth 2.0:n turvallisuusparhaita käytäntöjä.

Olemme äskettäin saaneet useita kysymyksiä asiakkailtamme, jotka pyytävät opastusta tai tukea ROPC-hyväksyntätyypin toteuttamiseen. Tässä artikkelissa selitämme, miksi sinun tulisi välttää ROPC-hyväksyntätyypin käyttöä erityisesti uusissa sovelluksissasi.

ROPC-hyväksyntätyyppi vs. valtuutuskoodiprosessi#

Miten ROPC-hyväksyntätyyppi toimii#

ROPC-hyväksyntätyyppi on yksinkertainen prosessi, joka vaihtaa käyttäjän tunnuksen ja salasanan käyttöoikeustunnukseen. Asiakassovellus kerää käyttäjän tunnistetiedot suoraan ja lähettää ne suoraan valtuutuspalvelimelle. Valtuutuspalvelin validoi sitten tunnistetiedot ja myöntää käyttöoikeustunnuksen asiakkaalle.

Miten valtuutuskoodiprosessi toimii#

Toisin sanoen valtuutuskoodiprosessi on suositeltu OAuth 2.0 -menetelmä web-sovelluksille. Se sisältää useita vaiheita ja uudelleenohjauksia asiakassovelluksen, valtuutuspalvelimen ja käyttäjän selaimen välillä. Valtuutuskoodiprosessi on turvallisempi, koska se ei altista käyttäjän tunnistetietoja asiakassovellukselle.

Pääasiallinen ero ROPC-hyväksyntätyypin ja valtuutuskoodiprosessin välillä on siinä, että ROPC altistaa käyttäjän tunnistetiedot asiakassovellukselle, kun taas valtuutuskoodiprosessi ei tee niin. Käyttäjän tunnistetiedot tulisi säilyttää luottamuksellisesti valtuutuspalvelimella. Aina kun asiakassovellus pyytää resurssia käyttäjän puolesta, sen pitäisi ohjata käyttäjä valtuutuspalvelimelle todentamaan ja valtuuttamaan asiakassovellus. Tämä pitää asiakassovelluksen puolella vain minimaalisen määrän valtuutustietoja.

ROPC-hyväksyntätyypin turvallisuusriskit#

1. Käyttäjän tunnistetietojen altistuminen#

Kuten mainitsimme aiemmin, ROPC-hyväksyntätyyppi altistaa käyttäjän tunnistetiedot asiakassovellukselle. Tämä on merkittävä turvallisuusriski, koska asiakassovellus voi tallentaa tai kirjata käyttäjän tunnistetiedot ja valtuuttaa uudelleen ilman käyttäjän tietämystä.

Erityisesti julkisten asiakassovellusten, kuten mobiilisovellusten tai yksisivuisen sovelluksen kohdalla, asiakassovellus voidaan helposti injektoida tai vastakehittää käyttäjän tunnistetietojen purkamiseksi. Kumpikaan mobiilisovellus eikä yksisivuinen sovellus, joka toimii käyttäjän selaimessa, ei voi säilyttää salaisuuksia luottamuksellisesti. Siksi he eivät voi todentaa käyttäjää paljastamatta käyttäjän tunnistetietoja.

Vaikka resurssin omistajalla olisi luottamuksellinen suhde asiakassovellukseen, asiakassovellus toimii koko todennusprosessin välittäjänä, ja se saattaa vaarantua toisen haitallisen toimijan toimesta. Haitallinen toimija voi varastaa käyttäjän tunnistetiedot ja esiintyä käyttäjänä päästäkseen käyttäjän resursseihin.

Käyttäjän tunnistetiedot voidaan varastaa useilla tavoilla asiakassovelluksen turvallisuustilanteesta riippuen, kuten näppäinloggereilla, tietojenkalasteluhyökkäyksillä tai haittaohjelmilla. Puhumattakaan siitä, että asiakastunnisteet lähetetään verkon kautta jokaisen valtuutuspyynnön yhteydessä, mikä edelleen lisää tunnistetietojen sieppaamisen riskiä.

Kuvittele, että sinulla on useita sovelluksia, jotka käyttävät ROPC-hyväksyntätyyppiä, riski tunnistetietojen altistumiselle kasvaa moninkertaiseksi.

2. ROPC ei tue käyttäjän suostumusta#

ROPC-hyväksyntätyyppi ei tue käyttäjän suostumusta. Kun asiakassovellus kerää käyttäjän tunnistetiedot suoraan, käyttäjä ei saa mahdollisuutta tarkistaa ja hyväksyä asiakassovelluksen pääsyä heidän resursseihinsa. Tämä rikkoo käyttäjän yksityisyyttä ja luottamusta.

Käyttäjillä pitäisi olla oikeus päättää, mitkä asiakassovellukset voivat käyttää heidän resurssejaan ja kuinka kauan. Erityisesti kolmannen osapuolen sovelluksille käyttäjän suostumusmekanismi on olennainen resurssin omistajan tietojen suojaamiseksi ja on välttämätöntä noudattaa tietosuojasäädöksiä, kuten GDPR.

3. ROPC ei tue monivaiheista todentamista#

Monivaiheinen todentaminen (MFA) on turvallisuusolosuhteet, joka vaatii käyttäjän antamaan kaksi tai useampia todentamisvaiheita päästäkseen resursseihinsa. Se lisää ylimääräisen turvakerroksen todennusprosessiin. ROPC-hyväksyntätyyppi ei tue MFA:ta. Sen sijaan se rajoittaa todennusprosessin yhteen vaiheeseen, ja tunnuspyyntö perustuu vain käyttäjän tunnistetietoihin. On mahdotonta toteuttaa haastepohjaisia todennusmekanismeja, kuten SMS OTP, sähköposti OTP tai WebAuthn ROPC-hyväksyntätyypillä.

ROPC ei ole yhteensopiva modernien sovellusten kanssa#

ROPC-hyväksyntätyyppi suunniteltiin tukemaan vanhoja sovelluksia, jotka eivät voi tukea moderneja IAM-järjestelmiä, kuten Single Sign-On (SSO) tai liitettyjä identiteettejä.

1. ROPC ei ole yhteensopiva SSO:n kanssa#

Single Sign-On (SSO) on moderni todennusarkkitehtuuri, joka sallii käyttäjien kirjautua kerran ja käyttää useita sovelluksia vaivattomasti.

Keskitetty IdP on keskeinen rooli SSO-arkkitehtuurissa. Se hallinnoi käyttäjän todennussessiota ja myöntää tunnuksia asiakassovelluksille. Asiakassovellusten ei tarvitse kerätä käyttäjän tunnistetietoja suoraan, ja käyttäjän tunnistetiedot säilytetään luottamuksellisesti IdP:ssä.

ROPC-hyväksyntätyyppi ei tue SSO:ta. Se edellyttää, että asiakassovellus kerää käyttäjän tunnistetiedot suoraan, mikä rikkoo SSO-arkkitehtuuria. Se ei ole yhteensopiva modernien SSO-järjestelmien, kuten OpenID Connect (OIDC) tai SAML kanssa.

2. ROPC ei ole yhteensopiva liitettyjen identiteettien kanssa#

Samoin kuin SSO-arkkitehtuuri, liitetyt identiteetit sallivat käyttäjien käyttää olemassa olevia identiteettejaan päästäkseen useisiin kolmannen osapuolen sovelluksiin. Käyttäjä voi yhdistää useita sosiaalisia tilejä, kuten Google, Facebook tai Twitter, keskitettyyn IdP:hen ja käyttää näitä sosiaalisia tilejä todennuttaakseen asiakassovelluksille. Kaikki liitetyt identiteetit hallinnoidaan IdP:ssä, ja asiakassovellukset eivät ole tietoisia käyttäjän todennustiedoista kulissien takana.

ROPC-hyväksyntätyyppi sen sijaan vaatii asiakassovelluksen keräämään käyttäjän tunnistetiedot suoraan. Se rajoittaa asiakassovelluksen kykyä tukea liitettyjä identiteettejä ja altistaa käyttäjän identiteettitiedot asiakassovellukselle.

Yhteenveto#

Resource Owner Password Credentials (ROPC) -hyväksyntätyyppi on vanha OAuth 2.0 -prosessi, joka aiheuttaa merkittäviä turvallisuusriskejä ja tulisi vanhentaa. Se altistaa käyttäjän tunnistetiedot asiakassovellukselle, ei tue moderneja turvallisuusmekanismeja kuten MFA tai SSO. Suosittelemme vahvasti välttämään ROPC-hyväksyntätyypin käyttöä sovelluksissasi. Jos sinulla on vanhoja todennusjärjestelmiä, jotka perustuvat ROPC-hyväksyntätyyppiin, harkitse siirtymistä turvallisempiin OAuth 2.0 -prosesseihin, kuten valtuutuskoodiprosessiin tai asiakasvaltuutushakemukseen.

Ota meihin yhteyttä, jos tarvitset apua turvallisen käyttäjän tunnistus- ja valtuutuspalvelun integroinnissa sovelluksiisi tai siirtymisessä vanhasta salasanaperusteisesta todennusjärjestelmästä turvallisempaan OAuth 2.0 -prosessiin. Olemme täällä auttamassa sinua rakentamaan turvallisia ja moderneja sovelluksia.