Opi, mitä bearer-tunnisteet ovat, miten ne toimivat OAuth 2.0:ssa ja JWT:ssä, miten ne eroavat access token -tunnisteista sekä parhaat käytännöt niiden käyttämiseen.
Lähes jokaisen modernin sovelluskirjautumisen tai API-pyynnön taustalla toimii hiljainen työhevonen: bearer-tunniste. Et ehkä huomaa sitä, mutta se on olemassa joka kerta, kun yhdistät palveluita, kirjaudut sisään tai haet tietoa pilvestä.
Tämä opas käy läpi, mitä bearer-tunnisteet tekevät, miksi ne ovat tärkeitä ja miten niitä käsitellään turvallisesti.
Bearer-tunniste on tietoa, yleensä merkkijono, joka todistaa, että haltija saa käyttää tiettyä resurssia. Tärkeintä on, että kuka tahansa, joka kantaa tunnistetta, voi käyttää sitä ilman lisätodistusta.
Ajattele lentolippua. Kun sinulla on se kädessä, voit kulkea turvatarkastuksen läpi ja nousta koneeseen. Kukaan ei pyydä sinua näyttämään henkilöllisyystodistusta uudelleen, jos lippu on voimassa. Samalla tavalla bearer-tunniste antaa sovelluksellesi mahdollisuuden "nousta APIin" ilman, että henkilöllisyyttäsi tarkistetaan joka kerta uudelleen.
Esimerkiksi kun olet kirjautunut Spotifyyn puhelimellasi, sinun ei tarvitse syöttää salasanaa joka kerta kun soitat kappaleen. Sovellus tallentaa bearer-tunnisteen, joka kertoo Spotifyn palvelimille: "tämä pyyntö tulee valtuutetulta käyttäjältä".
Bearer-tunnisteiden kulku voidaan jakaa muutamaan vaiheeseen:
Käyttäjä kirjautuu sisään
Oletetaan, että kirjaudut pankkisovellukseen käyttäjätunnuksella ja salasanalla.
Tunnistuspalvelin luo tunnisteen
Kun tiedot on tarkistettu, autentikointipalvelin lähettää takaisin bearer-tunnisteen. Se voi näyttää vaikka tältä:
Client käyttää tunnistetta
Joka kerta kun painat "Tarkista saldo" tai "Siirrä rahaa", sovellus lisää tunnisteen HTTP-pyyntöön:
API tarkistaa tunnisteen
Palvelin tarkistaa, onko tunniste yhä voimassa, onko se vanhentunut ja sisältääkö se oikeat käyttöoikeudet (kuten read:balance tai write:transfer).
Pääsy sallitaan
Jos kaikki tarkistukset menevät läpi, palvelin vastaa pyydetyillä tiedoilla.
Tätä mallia käytetään laajalti esimerkiksi GitHubin API-rajapinnoissa, joissa kehittäjät tunnistautuvat bearer-tunnisteella sen sijaan, että syöttäisivät kirjautumistietonsa toistuvasti.
Bearer-tunnisteet nousivat suosioon, koska ne ratkaisivat yleisiä verkkoturvallisuuden ongelmia. Toisin kuin palvelinpohjaiset istunnot, ne eivät vaadi erillistä tietovarastoa jokaiselle sisäänkirjautuneelle käyttäjälle. Sen sijaan tunniste itsessään sisältää tarpeeksi tietoa, jotta palvelin voi hyväksyä pyynnön.
Esimerkiksi mikroservice-arkkitehtuurissa, jossa kymmenet eri palvelut keskustelevat keskenään, keskitetyn istuntotallennuksen ylläpito olisi monimutkaista ja tehotonta. Bearer-tunnisteilla jokainen palvelu voi itsenäisesti tarkistaa pyynnöt, mikä pitää järjestelmän kevyenä ja skaalautuvana.
Konkreettinen esimerkki: Slackin API:t perustuvat vahvasti bearer-tunnisteisiin. Kun rakennat Slack-botin, saat tunnisteen, jolla bottisi voi kutsua Slackin päätepisteitä ylläpitämättä erillistä istuntoa jokaiselle käyttäjälle.
Monet bearer-tunnisteet toteutetaan JWT:nä (JSON Web Token). Nämä tunnisteet ovat koodattuja merkkijonoja, jotka sisältävät tietoa käyttäjästä ja hänen oikeuksistaan.
Puretaanpa esimerkinomainen JWT:
Tämä tarkoittaa:
sub: Subjekti, eli käyttäjän yksilöllinen ID.name: Käyttäjän nimi.iat: Luomisaikaleima.exp: Vanhentumisaika (milloin tunniste lakkaa toimimasta).scope: Oikeudet — tässä sovellus saa sekä lukea että kirjoittaa viestejä.Käytännössä, jos Janen tunnisteessa olisi vain scope read:messages, sovellus voisi hakea hänen viestinsä muttei lähettää niitä hänen puolestaan.
Bearer-tunnisteet ja access tokenit menevät helposti sekaisin, koska niitä käytetään usein rinnakkain. Ne liittyvät toisiinsa, mutta eivät ole sama asia.
Access token on tunniste, joka edustaa käyttäjän oikeutta päästä tiettyyn resurssiin. Se kuljettaa tietoa kuten:
Ajattele tätä kuin lupalappu, jonka rehtori on allekirjoittanut. Se kertoo opettajalle (API:lle), että saat osallistua retkelle (käyttää resurssia).
Esimerkiksi kun kirjaudut pilvitallennuspalveluun, järjestelmä luo access tokenin, jossa on scope read:files. Tämä tunniste kertoo tallennus-API:lle: "Tämä käyttäjä voi lukea tiedostoja, muttei poistaa niitä."
Bearer-tunniste on yksi access tokenin tyyppi. Sanaa bearer käytetään kuvaamaan tunnisteen käyttöä: kuka tahansa, joka esittää tunnisteen, saa käyttää resurssia ilman lisävarmistusta henkilöllisyydestä.
Toisin sanoen:
On olemassa myös muita tunnistetyyppejä, kuten holder-of-key tokens, joissa clientin pitää lisäksi todistaa salaisen avaimen hallinta. Bearer-tunnisteet ohittavat tämän lisävaiheen, mikä tekee niistä helpompia, mutta myös riskialttiimpia jos ne varastetaan.
<token> -otsikossa.Tämä tarkoittaa, että kun näet OAuth-tutoriaaleissa sanan "access token", kyseessä on lähes aina bearer-tunniste, ellei toisin mainita.
Selkeyden vuoksi vertaillaan bearer-tunnisteita muihin yleisimpiin tunnisteisiin:
Bearer-tunnisteet ja access tokenit eivät ole vastakkaisia käsitteitä — ne suhtautuvat toisiinsa näin:
Bearer-tunnisteen validointi on este luvattomalle käytölle API:n kautta. Jos tunnisteesi ovat JWT-muodossa, validoiminen tapahtuu nopeasti ja paikallisesti. API voi tarkistaa tunnisteen ilman, että sen tarvitsee soittaa aina palveluntarjoajalle.
Käytä tätä ohjeena, kun kytket API gatewayn tai middleware-kerroksen.
Allekirjoitus
Varmista allekirjoitus headerissa mainitulla algoritmilla (esim. RS256). Nouda palveluntarjoajan JWKS-päätepiste, valitse kid-arvoa vastaava avain ja välimuistita se.
Issuer (iss)
Tarkista, että tokenin iss vastaa luotettua palveluntarjoajan URL:ia täsmällisesti ja oikealla skeemalla.
Audience (aud)
Varmista, että tunniste on tarkoitettu API:llesi. Vertaile esimerkiksi API-tunnisteeseen kuten https://api.example.com tai loogiseen audience-merkkijonoon.
Expiration (exp) ja Not-Before (nbf)
Hylkää vanhentuneet tunnisteet. Kunnioita nbf-arvoa, ettei tokenia voi käyttää ennen aloitusaikaa. Hyväksy pieni kelloheitto, tavallisesti 30–60 sekuntia.
Issued-At (iat)
Hyödyllinen virheenkorjauksessa ja vanhojen tokenien hylkäämisessä tiukoissa ympäristöissä.
Token-tyyppi
Varmista, että kyseessä on access token. Jotkut palvelut lisäävät typ: "at+jwt" tms. Älä hyväksy ID-tunnisteita API-käyttöön.
Scopet / oikeudet
Tarkista scope tai palvelukohtaiset ominaisuudet (esim. permissions, roles). Käytä vähimmäisoikeutta jokaisessa päätepisteessä.
Subject (sub)
Pysyvä käyttäjä- tai client-ID. Liitä resursseihin ja käytä auditointiin.
Toistohyökkäys ja estolistat (valinnainen, mutta suositeltava)
Herkillä päätepisteillä tarkista lyhytaikainen kieltolista jti-arvoista tai aktiivinen istunto. Tämä auttaa käyttäjän kirjautuessa ulos tai epäiltyjen väärinkäytösten jälkeen.
Koska bearer-tunnisteet toimivat siten, että "kuka pitää tunnistetta, saa käyttää sitä", niitä on käsiteltävä kuin kotisi avaimia. Jos joku varastaa avaimen, hän voi avata oven, kunnes vaihdat lukon.
Yleisiä riskejä ovat mm.:
Käytännön tietomurtoja on tapahtunut, kun kehittäjät ovat vahingossa tallentaneet bearer-tunnisteita julkisiin GitHub-repositoryihin. Hyökkääjät voivat skannata näitä tunnisteita ja käyttää niitä välittömästi luvattomaan pääsyyn.
Bearer-tunnisteiden turvallinen käyttö vaatii hyvien käytäntöjen noudattamista. Käydäänpä ne läpi esimerkein:
Käytä aina HTTPS:ää
Kuvittele lähettäväsi tunnisteen salaamattomassa HTTP:ssä julkisessa kahvilan Wi-Fi-verkossa. Kuka tahansa verkkoa salakuunteleva voisi kopioida tunnisteen ja kirjautua sisään puolestasi.
Käytä lyhytikäisiä access tokeneita
Useimmat alustat luovat tunnisteita, jotka vanhenevat tunnissa. Esimerkiksi Googlen OAuth-tunnisteet ovat tyypillisesti voimassa yhden tunnin ennen uudistamista.
Käsittele refresh tokeneita huolella
Refresh tokenilla voi pyytää uusia access tokeneita ilman uudelleenkirjautumista. Ne tulee kuitenkin säilyttää turvallisesti, esim. salatulla palvelinpäässä, ei clientissä.
Rajaa tunnisteet minimiturvallisuuksiin
Jos sovelluksesi tarvitsee vain lukea käyttäjän kalenterin, älä pyydä write:calendar -oikeutta. Tämä rajoittaa vahinkoa, jos tunniste joutuu vääriin käsiin.
Peru tunnisteet tarvittaessa
Monissa SaaS-sovelluksissa käyttäjä voi nähdä aktiiviset istunnot ja perua ne. Esimerkiksi GitHubissa voit poistaa henkilökohtaisia access tokeneita milloin tahansa.
Seuraa käyttöä
Tunnisteiden käytön lokitus voi paljastaa outoja tapahtumia. Jos sama tunniste käytetään yllättäen Lontoossa ja New Yorkissa minuuttien sisällä, kyseessä voi olla tietoturvauhka.
Kannattaa vertailla bearer-tunnisteita muihin suosittuihin lähestymistapoihin:
Evästeet & istunnot
Perinteiset verkkosivustot perustuvat palvelimelle tallennettuihin istuntoihin, jotka tunnistetaan evästeen perusteella. Tämä toimii hyvin selainpohjaisissa sovelluksissa, mutta on tehottomampaa API- ja mobiilikäytössä. Esimerkiksi Facebookin työpöytäversio käyttää pääasiassa evästeitä, kun taas mobiili-API:ssa käytetään tokeneita.
API-avaimet
API-avain on pysyvä merkkijono, joka tunnistaa sovelluksen, mutta ei käyttäjää. Sääsovellus voi hakea tietoja API-avaimella, mutta palvelin ei tiedä kuka käyttäjä kysyy tietoa. Bearer-tunnisteet voivat sisältää käyttäjäkohtaisia tietoja ja ovat siksi monipuolisempia.
Mutual TLS (mTLS)
Joissakin korkean turvatason järjestelmissä käytetään molemminpuolisia varmenteita sekä clientilla että palvelimella. Tämä on turvallisempaa, mutta vaikeampaa ottaa käyttöön laajasti. Useimmissa SaaS-alustoissa bearer-tunnisteet osuvat käytettävyyden ja turvallisuuden kannalta sopivaan kompromissiin.