Vuosi oli 2012, ja päivitetty OAuth 2 -tietoturvaprotokolla pyyhkäisi verkkoa, jolloin käyttäjät voivat kirjautua helposti verkkosivustoille turvatarjoajien avulla. Monet kertakirjautumisjärjestelmät, AWS: n Cognitosta Oktaan, toteuttavat OAuthin. OAuth antaa sinun "todentaa Googlen tai muiden palveluntarjoajien kanssa täysin eri verkkosivustolle tai sovellukselle.
Se toimii kuin olutfestivaali. Menet pöydälle ja todistat henkilöllisyystodistuksellasi (ja rahalla), ja he antavat sinulle rahakkeita. Sieltä menet jokaiseen oluttelttaan ja vaihdat tunnuksen olueksi. Yksittäisen panimon ei tarvitse tarkistaa henkilötodistustasi tai kysyä, maksoitko. He vain ottavat merkin ja antavat sinulle oluen. OAuth toimii samalla tavalla, mutta verkkosivustojen kanssa oluiden sijaan.
Valitettavasti OAuth on vuoden 2020 paras olutfestivaali.
Puhuin Dan Mooren kanssa FusionAuthista OAuthista ja ehdotetusta korvauksesta nimeltä GNAP - joka lausutaan ilman G: tä todennäköisesti "nap". Ääntäminen tukee ajatusta siitä, että turvallisuus on todella jännittävä ala. GNAP käsittelee joitain OAuth-rajoituksia ja lisää siihen uusia ominaisuuksia.
Miksi korvata OAuth tai pikemminkin lisätä sitä? OAuth suunniteltiin selainten ympärille. Siinä oletetaan, että pyynnön lähettäjä voi käsitellä HTTP-uudelleenohjausta. Tämä verkkoselaimen painopiste on kompastuskivi mobiilisovelluksille tai mille tahansa "esineille" esineiden Internetissä. Lisäksi OAuth-osapuolet pitävät vuodesta 2007 ja edellyttävät, että lähetät lomakeparametrit JSON: n sijaan.
OAuth-spesifikaatio oli epäselvä joissakin paikoissa, ja maailma muuttui vuodesta 2012. Siellä on joukko RFC: itä ja BCP: itä, lähinnä lisäominaisuuksia, jotka sinun on toteutettava, jotta saat enemmän ominaisuuksia, parempaa tietoturvaa ja yleistä yhteensopivuutta. Erillinen OAuth 2.1 -niminen pyrkii romahtamaan osan näistä lisäyksistä yhtenäisemmäksi yksittäiseksi spesifikaatioksi. Joidenkin OAuth 2.1: n motivaatioiden osalta katso Lee McGovern Okta-julkaisusta "Kuinka monta RFC: tä tarvitaan lampun vaihtamiseen". Toisin kuin GNAP, OAuth 2.1 on vain inkrementaalijulkaisu, jossa ei ole uusia merkittäviä muutoksia sen lisäksi, että teknisten ominaisuuksien pino yhdistetään yhteen spesifikaatioon.
GNAP-määrittely on vielä alkuvaiheessa. GNAP: n kirjoittajat aikovat mennä pidemmälle kuin OAuth 2.1 ja muuttaa itse protokollan luonnetta. HTTP-parametrien käyttämisen sijaan voit käyttää JSON-tiedostoa. Sovelluksen päätepisteet ovat löydettävissä. Sinun ei tarvitse tukea uudelleenohjauksia (tai sen ympärillä olevia eri hakkereita). Moore viittaa näihin muutoksiin ihastuttavalla termillä "kehittäjien ergonomia".
GNAP: n päätavoitteena on erottaa kuka pyytää resursseja (RQ) ja kuka omistaa resurssit (RO).
IETF GNAP ehdottaa myös uusien turvallisuusominaisuuksien tukemista, kuten:
- Asynkroninen ja sovelluksen URL-käynnistys. Nämä ovat erilaisia todennuspolkuja, joiden avulla asiakas voi todentaa ilman uudelleenohjausta. GNAP mahdollistaa myös sovellusten todentamisen kolmannen osapuolen resursseille, joihin resurssipalvelimella ja valtuutuspalvelimella ei ole suoraa pääsyä.
- Pyydä jatkoa. Niiden avulla asiakkaat voivat neuvotella asioista, kuten uudelleenohjauksista tai muista todennustiedoista todennusprosessin aikana. Ne antavat asiakkaalle myös mahdollisuuden neuvotella lisäoikeuksista tai käyttöoikeustunnuksista.
- Monipääsykoodit. Näiden avulla asiakkaat voivat todentaa useita resursseja kerralla, esimerkiksi sekä käyttäjänä että järjestelmänvalvojana.
- Lähettäjän rajoitusmerkit. Vaikka OAuth 2: lla on lisäosia tälle toiminnolle, nimeltään DPOP ja MTLS, GNAP rakentaa tämän suoraan protokollaan. Palaa oluttelttamme esimerkkiin. Entä jos joudumme myös kuiskata salasanan myyjän korvaan luovuttaessamme heille tunnusta? Jos tunnuksemme pudotetaan (tai siepataan), sillä ei ole merkitystä, koska haltijalla ei ole salasanaa.
- Ja GNAP saa Kerberoksen haamun huutamaan.
Kuulostaa hyvältä? Voitteko aloittaa GNAP: n käytön tänään? Jos olet kiinnostunut yhteistyöstä, voit haastaa yhden prototyypeistä, jotka sisältyivät nykyiseen GitHub-ehdotukseen.
Mooreen mukaan kirjoittajat pyrkivät julkaisemaan GNAP: n vuonna 2022. Koska jokainen päivä vuonna 2020 on kuin viikko tyypillisessä vuodessa, GNAP on kaukana. GNAP-työryhmä etsii kuitenkin yhteistyökumppaneita, ja voit liittyä postituslistalle ja tarjota palautetta ja asiantuntemusta. Luulen, että et voi korjata kaikkea maailmassa, mutta voit ainakin auttaa korjaamaan OAuthin.
