Onko OAuth sama kuin todennus?

Ei. OAuth on valtuutus – se antaa asiakkaalle luvan käyttää resursseja. OAuthiin rakennettu OpenID Connect lisää todennuksen. "Kirjaudu sisään Googlella" on OIDC; "Yhdistä Google-kalenteri" voi olla joko sen mukaan, tarvitseeko sovelluksen tietää kuka olet vai tarvitseeko vain pääsyn tietoihisi.

Pitäisikö minun käyttää OAuthia vai tallentaa salasanoja?

Käytä OAuthia aina kun mahdollista. Käyttäjien salasanojen tallentaminen tarkoittaa kaiken vastuun perimistä hajautus-, suola-, tietomurtovastauksista, salasanan palautuksesta ja 2FA:sta. Delegointi Googlelle/Applelle/Microsoftille/GitHubille OAuthin kautta purkaa kaiken. Kompromissi on, että käyttäjäsi tarvitsevat tilit kyseisiltä palveluntarjoajilta.

Miksi OAuth-tunnukset voidaan peruuttaa, mutta salasanat ei?

Tokenit viittaavat merkintään valtuutuspalvelimen tietokannassa. Merkinnän peruuttaminen mitätöi tunnuksen välittömästi. Salasanat ovat tietoa – voit kiertää salasanaa ja pakottaa uudelleentodennuksen, mutta vanha salasana pysyy voimassa, kunnes teet sen.

Mitä eroa on OAuth 2.0:lla ja OAuth 1.0:lla?

OAuth 1.0 (2007) käytti kryptografisia allekirjoituksia jokaisessa pyynnössä. OAuth 2.0 (2012) luottaa TLS:ään liikenteen turvallisuuteen ja käyttää siirtotietunnuksia. OAuth 2.0 on yksinkertaisempi toteuttaa, ja se toimitetaan lähes kaikissa nykyaikaisissa API:ssa. OAuth 1.0 on käytännössä vanhentunut.

Ovatko OAuth-tunnukset vaarallisia, jos ne vuotavat?

Kyllä – kenellä tahansa, jolla on tunnus, on myönnetty käyttöoikeus, kunnes se vanhenee tai se peruutetaan. Lievennykset: lyhyt käyttöoikeustunnus (1 tunti tyypillisesti), päivitystunnukset on tallennettu turvallisemmin, laajuuden minimointi, tarkastusloki. Käsittele käyttöoikeuksia yhtä huolellisesti kuin salasanoja niiden voimassaoloaikana.

OAuth 2.0:n selitys: Kuinka "Kirjaudu sisään Googlella" todellisuudessa toimii

Jokainen "Kirjaudu sisään Googlella" -painike, jokainen "Yhdistä Twitter-tili" -linkki, jokainen modernien palveluiden välinen API-integraatio kulkee OAuthissa. Protokolla korvaa salasanojen jakamisen tunnuksien ja suostumusnäyttöjen joukolla, ja liikkuvien osien ymmärtäminen tekee selväksi joukon hyökkäyksiä ja mukavuuksia.

Artikkelin koko runko on englanniksi alla.

OAuth 2.0 on valtuutuskehys, jonka avulla yksi sovellus voi saada rajoitetun pääsyn toisen sovelluksen resursseihin käyttäjän puolesta – näkemättä koskaan käyttäjän salasanaa. Perinteinen käyttötapaus: kalenterisovelluksen, jonka on luettava Google-kalenterisi, ei pitäisi vaatia sinua antamaan sille Google-salasanasi. OAuthin avulla voit myöntää sovellukselle sen sijaan suojatun, peruutettavan tunnuksen.

Näyttelijät

Neljä roolia OAuth-kulussa:

Resurssin omistaja — sinä, käyttäjä, jolla on tietoja jossain sovellus, joka haluaa pääsyn (esim. kolmannen osapuolen kalenterin katseluohjelma)
Valtuutuspalvelin – palvelu, joka todentaa sinut ja antaa tunnuksia (esim. Googlen OAuth-päätepiste)
fi, Google API, Google-sovellusliittymä, jossa on datapalvelinXPLZg. API)

Valtuutuskoodin kulku

Tavallinen palvelinpuolen kulku, yksinkertaistettu:

Napsautat "Yhdistä Google-kalenteri" asiakassovelluksessa.
Asiakasohjelma uudelleenohjaa valtuutuspalvelimesi Googlen palvelimen tunnuksella. (calendar.read), tila (CSRF-tunnus).
Todennat Googlelle, jos et ole jo kirjautunut sisään.
Google näyttää sinulle suostumusnäytön: "CalendarViewer haluaa lukea kalenteriasi. Sallitaanko?"
Napsautat Salli. Google ohjaa selaimesi takaisin asiakkaan redirect_uriin kertaluonteisella valtuutuskoodilla.
Asiakkaan palvelinpuolen koodi vaihtaa valtuutuskoodin (sekä sen asiakassalaisuuden) käyttötunnukseksi soittamalla suoraan Googlen tunnuksen päätepisteeseen.
Asiakas käyttää käyttöoikeustunnusta4WhZPLX-sovellusliittymää soittaakseen Googlen puolesta4XXPLX4XX. käyttöoikeustunnus vanhenee (yleensä tunti), asiakas käyttää päivitystunnusta saadakseen uuden ilman, että se häiritsee sinua.

Tärkein suojausominaisuus: salasanasi ei koskaan koske asiakassovellusta. Asiakas saa suojatun tunnuksen, jonka voit peruuttaa Google-tilin hallintapaneelissa milloin tahansa.

OAuth 2.0 vs OAuth 2.1 vs OIDC

OAuth 2.0XOAuth 2.0 6 4 on 9 6 -standardi. Useita RFC-laajennuksia ja parhaiden käytäntöjen asiakirjoja on lisätty sen jälkeen.
OAuth 2.1 (luonnoksessa vuodesta 2026 lähtien) yhdistää nykyiset parhaat käytännöt yhdeksi spesifikaatioksi – pakollinen PKCE, poistettu Implicit Flow jne.XPLZ61OpenxIDZ Connect2ZX (OIDC) on OAuth 2.0:n päällä oleva identiteettikerros. Pelkästään OAuth antaa läpinäkymättömän käyttötunnuksen; OIDC lisää ID-tunnuksen (JWT), joka todentaa käyttäjän. Useimmat "Kirjaudu sisään..." -painikkeet käyttävät OIDC:tä, ei tavallista OAuth-koodia.

Avustustyypit

OAuth 2.0 määrittelee useita kuluja eri skenaarioita varten:

A yllä kuvattu virtaus3-palvelinkoodi. PKCE-laajennuksella, jota käyttävät myös mobiili- ja SPA-sovellukset.
IImplicit Flow (vanhentunut) – myönnetty käyttöoikeustunnukset suoraan URL-osoitteiden kautta. Alttiina merkkivuodolle; korvataan valtuutuskoodilla + PKCE.
Resource Owner Password Credentials (harvoin käytetty) – asiakas kerää käyttäjän salasanan ja vaihtaa sen tunnukseksi. Tulee käyttää vain vanhoissa siirtoskenaarioissa.
Client Credentials — koneelta koneelle, jossa ei ole käyttäjää. Asiakas tunnistaa itsensä ja saa tunnuksen omille resursseilleen.
Device Code — laitteille, joissa ei ole selainta (televisiot, IoT). Laite näyttää koodin; käyttäjä valtuuttaa puhelimesta tai kannettavasta tietokoneesta.
Refresh Token — vaihtaa pitkäikäisen virkistystunnuksen uuteen käyttöoikeustunnukseen ilman käyttäjän toimenpiteitä.

PKCE: pakollinen laajennus

XPLZPLZ9 Pron avain Code Exchange, lausutaan "pixie") estää valtuutuskoodin sieppaushyökkäykset. Asiakas luo satunnaisen salaisuuden, tiivistää sen ja lähettää tiivisteen valtuutuspyynnössä. Koodia vaihdettaessa se lähettää alkuperäisen salaisuuden. Valtuutuspalvelin tarkistaa hajautusarvot. Hyökkääjä, joka sieppaa koodin, ei voi vaihtaa sitä ilman alkuperäistä salaisuutta.
PKCE pidetään nyt pakollisena kaikille OAuth-asiakkaille – sekä julkisille (selain, mobiili) että luottamuksellisille (palvelinpuolella).
Scopes
Tokeneille myönnetään tietyt laajuudet – toiminnot, jotka ne saavat suorittaa. Googlen tyypilliset kaukoputket näyttävät tältä https://www.googleapis.com/auth/calendar.readonly. Asiakas pyytää laajuuksia; käyttäjä näkee ne suostumusnäytöllä ja hyväksyy tai hylkää. Vähimmäisoikeuksien periaate: pyydä vain niitä laajuuksia, joita todella tarvitset.
Yleiset OAuth-hyökkäykset
Avaa uudelleenohjaus. Väärin määritetty redirect_uri-parametri antaa hyökkääjän uudelleenohjata valtuutuskoodin omalle palvelimelleen.XPLZ2SXXtaZ parametri1 omission. Ilman käyttäjäistuntoon sidottua tila-arvoa OAuth-virrat ovat haavoittuvia CSRF:lle – hyökkääjä huijaa uhrin suorittamaan OAuth-kulkua, joka linkittää hyökkääjän tilin uhrin istuntoon.
Token-päävuoto selaimen historiassa PLZlicitlowX heikkous).
Tunnustevarkaus XSS:n kautta. Jos asiakassovellus tallentaa tunnuksia LocalStorageen ja siinä on XSS-haavoittuvuus, hyökkääjät voivat varastaa ne.
Suostumusnäytön tietojenkalastelu. Asiakkaan haitalliset pyynnöt. käyttäjä, joka on ehdolla napsauttamaan "Salli" suostumusnäytöissä, myöntää pääsyn ilman valvontaa.
Mitä käyttäjänä tehdä
Tarkista yhdistetyt sovellukset säännöllisesti Google/Apple/Microsoft/Facebook/GitHub-tilin asetuksista. Peruuta sellaiset, joita et käytä.
Lue suostumusnäytön laajuudet ennen käyttöoikeuden myöntämistä. "Hallinnoi kalenteria" on eri asia kuin "Kalenterin tarkasteleminen".
Suhtaudu skeptisesti tuntemattomien sovellusten OAuth-pyyntöihin, vaikka ne ilmestyisivätkin tutun työnkulun aikana.

Usein kysytyt kysymykset

Onko OAuth sama kuin todennus?: Ei. OAuth on valtuutus – se antaa asiakkaalle luvan käyttää resursseja. OAuthiin rakennettu OpenID Connect lisää todennuksen. "Kirjaudu sisään Googlella" on OIDC; "Yhdistä Google-kalenteri" voi olla joko sen mukaan, tarvitseeko sovelluksen tietää kuka olet vai tarvitseeko vain pääsyn tietoihisi.
Pitäisikö minun käyttää OAuthia vai tallentaa salasanoja?: Käytä OAuthia aina kun mahdollista. Käyttäjien salasanojen tallentaminen tarkoittaa kaiken vastuun perimistä hajautus-, suola-, tietomurtovastauksista, salasanan palautuksesta ja 2FA:sta. Delegointi Googlelle/Applelle/Microsoftille/GitHubille OAuthin kautta purkaa kaiken. Kompromissi on, että käyttäjäsi tarvitsevat tilit kyseisiltä palveluntarjoajilta.
Miksi OAuth-tunnukset voidaan peruuttaa, mutta salasanat ei?: Tokenit viittaavat merkintään valtuutuspalvelimen tietokannassa. Merkinnän peruuttaminen mitätöi tunnuksen välittömästi. Salasanat ovat tietoa – voit kiertää salasanaa ja pakottaa uudelleentodennuksen, mutta vanha salasana pysyy voimassa, kunnes teet sen.
Mitä eroa on OAuth 2.0:lla ja OAuth 1.0:lla?: OAuth 1.0 (2007) käytti kryptografisia allekirjoituksia jokaisessa pyynnössä. OAuth 2.0 (2012) luottaa TLS:ään liikenteen turvallisuuteen ja käyttää siirtotietunnuksia. OAuth 2.0 on yksinkertaisempi toteuttaa, ja se toimitetaan lähes kaikissa nykyaikaisissa API:ssa. OAuth 1.0 on käytännössä vanhentunut.
Ovatko OAuth-tunnukset vaarallisia, jos ne vuotavat?: Kyllä – kenellä tahansa, jolla on tunnus, on myönnetty käyttöoikeus, kunnes se vanhenee tai se peruutetaan. Lievennykset: lyhyt käyttöoikeustunnus (1 tunti tyypillisesti), päivitystunnukset on tallennettu turvallisemmin, laajuuden minimointi, tarkastusloki. Käsittele käyttöoikeuksia yhtä huolellisesti kuin salasanoja niiden voimassaoloaikana.