Private Key JWT: Vahvempi vaihtoehto asiakasautentikointiin

Jos tunnet OAuth 2.0:n ja OpenID Connectin, tiedät, että asiakassovellusten on todennettava itsensä valtuutuspalvelimelle osana turvallista koodin ja tunnisteen vaihtoa. Tämä on tarpeen, jotta asiakkaan henkilöllisyys voidaan todentaa ja varmistaa, että vain lailliset sovellukset voivat vastaanottaa tunnuksia valtuutuspalvelimelta.

Asiakkaan todennus voidaan tehdä useilla eri tavoilla, jotka on määritelty Open ID Connect Core Client Authentication-asiakirjassa. Yleisin lähestymistapa asiakkaan todennukseen perinteisissä palvelinpohjaisissa sovelluksissa on client_secret: jaettu salasanan kaltainen merkkijono.

Vankempi vaihtoehtoinen menetelmä on Private Key JWT. Private_key_jwt:n avulla asiakassovellukset todistavat henkilöllisyytensä allekirjoittamalla JSON-verkkotunnisteen (JWT ) epäsymmetrisen avainparin yksityisellä avaimella. Tämä allekirjoitettu JWT(client_assertion) lähetetään sitten valtuutuspalvelimelle todentamista varten. Palvelin vahvistaa allekirjoituksen käyttämällä asiakkaan julkista avainta, johon pääsee käsiksi aiemmin luodun rekisteröinti- tai havaintomekanismin kautta.

Yksityisen avaimen JWT-asiakkaan todennus on nyt edellytys integroitumiselle Suomen luottamusverkostoon (FTN). Tämä menetelmä on kuitenkin täysin tuettu ja suositeltava myös muissa eID-integraatioissa , jos sovelluksesi on luottamuksellinen asiakas.

FTN Security Requirements: What You Need to Know

The Finnish government is introducing new requirements to tighten authentication security of the Finnish Trust Network (FTN). The requirements are described in Recommendation 213/2023 S Finnish Trust Network OpenID Connect Profile and include:

  • Private Key JWT client authentication
  • Authentication request signing
  • Encrypted token and userinfo responses

We've just implemented these changes at Criipto and are sharing the details with you in this article series. The goal is to explain the main concepts and demonstrate how these requirements enhance the overall security of authentication flows.

If you're integrating with FTN, you have to understand and implement these changes. Even if FTN is not among the eIDs you currently use, we encourage you to familiarize yourself with these concepts: similar security measures might be adopted by other eIDs in the future, or you might simply gain a better understanding of modern authentication security.

Private Key JWT -todennuksen edut

Private Key JWT -todennus tarjoaa useita etuja perinteisiin asiakassalaisuuksiin verrattuna.

1. Parannettu suojaus henkilöitymistä vastaan

Perinteinen client_secret-todennus perustuu jaettuun salaisuuteen ja symmetriseen salaukseen. Jos salaisuus vuotaa, siepataan tai varastetaan, kuka tahansa voi esiintyä sovelluksesi henkilöllisyydeksi, mikä vaarantaa sen turvallisuuden. Kaiken kukkuraksi asiakassalaisuudet ovat yleensä pitkäikäisiä ja ne lähetetään selväkielisinä langan välityksellä. Jos ne siis sattuvat vuotamaan esimerkiksi jaettujen HAR-jälkien kautta, hyökkääjä pystyy hyvin todennäköisesti käyttämään niitä.

Private Key JWT vähentää huomattavasti hyökkäyspintaa valtakirjojen varastamiseen. Siinä käytetään epäsymmetristä salausta: Sovelluksesi pitää yksityisen avaimen itsellään ja jakaa valtuutuspalvelimen kanssa vain vastaavan julkisen avaimen.

Todentamisen yhteydessä sovelluksesi allekirjoittaa JWT:n yksityisellä avaimellaan. Valtuutuspalvelin tarkistaa allekirjoituksen rekisteröidyn julkisen avaimesi avulla. Yksityinen avain ei siis koskaan poistu sovelluksestasi, eikä julkista avainta voida käyttää allekirjoituksen väärentämiseen ja sovelluksesi esittämiseen.

Private Key JWT käyttää myös erityisiä JWT-väitteitä (kuten jti yksilöllisille tunnuksille ja exp voimassaolon päättymiselle) estääkseen toistohyökkäykset ja varmistaakseen, että jokainen todennusyritys on voimassa vain kerran. Toinen turvallisuusetu on client_assertionlyhyempi käyttöikä - yleensäenintään tunti.

2. Vahvempi todiste alkuperästä ja kiistämättömyydestä.

Kun todennuksessa käytetään client_secret-tunnistetta, on haastavaa todistaa, että tietty asiakassovellus on lähettänyt tietyn pyynnön. Teoriassa kuka tahansa, jolla on salaisuus, olisi voinut lähettää sen.

private_key_jwt-todennus sen sijaan tarjoaa paljon vahvemman todisteen siitä, että tietty asiakas on käynnistänyt pyynnön. Tässä tapauksessa asiakassovelluksen yksityistä avainta ei koskaan jaeta ulkopuolisille, joten sen turvallisuus riippuu vain siitä, että avain pysyy luottamuksellisena. Tämä poistaa tietoturvaongelmat, jotka liittyvät valtuutuspalvelimen valtakirjojen säilytykseen tai kanaviin, joiden kautta client_secret voitaisiin lähettää.

Siksi client_assertioniin upotettu digitaalinen allekirjoitus tarjoaa vahvan kiistämättömyyden. Valtuutuspalvelin voi kryptografisesti tarkistaa tämän allekirjoituksen käyttämällä vastaavaa julkista avainta ja vahvistaa, että vain kyseinen asiakas on voinut allekirjoittaa väitteen. Tämä kryptografinen varmuus tarkoittaa, että kun toiminto kirjataan, tiedät lähes varmasti , mikä asiakas sen suoritti, mikä luo vahvemman ja luotettavamman kirjausketjun.

3. Yksinkertaistettu valtakirjojen hallinta

Jaettujen salaisuuksien koko elinkaaren - turvallisen jakelun, säilytyksen ja kiertämisen - hallinta voi olla toiminnallinen ja tietoturvallinen taakka.

Private Key JWT:n avulla client_secretiä ei tarvitse jakaa tai kiertää. Sovelluksesi vain luo epäsymmetrisen avainparin ja rekisteröi julkisen avaimensa kerran valtuutuspalvelimelle. Salaisuuksia ei tarvitse välittää rekisteröinnin aikana eikä auktorisointipalvelimella todennettaessa. Ja jos päätät vaihtaa avaimia, sovelluksesi yksinkertaisesti luo asymmetrisen avainparin uudelleen, korvaa yksityisen avaimensa ja päivittää valtuutuspalvelimelle rekisteröidyn julkisen avaimen. Tämä prosessi on luonnostaan turvallisempi kuin symmetrisen asiakassalaisuuden vaihtaminen, koska salaisuuksia ei vaihdeta.

Yhteenvetona

Private Key JWT on vahvempi standardi asiakkaan todennuksen suojaamiseen arkaluonteisissa ympäristöissä. Sen viime vuosina lisääntynyt käyttöönotto johtuu kehittyvistä turvallisuusstandardeista (kuten FAPI-työryhmän (Financial-grade API) standardeista), lisääntyneestä tietoisuudesta valtakirjojen vaarantamisriskeistä ja erilaisista sääntelyponnisteluista, kuten eIDAS:sta.

Voit aloittaa Private Key JWT -asiakastodennuksen käytön Criipton kanssa noudattamalla tätä opasta. Jos sinulla on kysyttävää, lähetä sähköpostia osoitteeseen support@criipto.com tai ota yhteyttä Slackissa.

 

Author

Latest blog posts

5 Reasons Verifiable Credentials Are Not Yet Widely Adopted

Verifiable credentials are shaping up to become the identity standard of the future. Not only do they have many possible use cases, but they can...

10 Use Cases for Verifiable Credentials

If you’ve recently started looking into verifiable credentials and their benefits, the concept might sound a bit abstract. After all, VCs are not...

6 Business Benefits of Verifiable Credentials

Today’s businesses must work extra hard to earn their customers’ trust. As more interactions take place online, companies have to juggle the...

Sign up for our newsletter

Stay up to date on industry news and insights