Logto v1.42.0 tuo mukanaan mukautetut verkkotunnuksen vahvistustiedostot, sähköpostin sallittujen listat jokerimerkeillä, salasanan palautuksen taikalinkit, Grant.LimitExceeded -webhookin ja protokollatason päivityksen käyttäen node-oidc-provider v9:ää, Koa 3:a sekä SSRF-suojauksen oletusarvoisesti päälle.
Logto v1.42.0 on verkkotunnuksiin ja protokollaan keskittyvä julkaisu. Se antaa tiimeille tavan todistaa verkkotunnuksen omistus ilman erillisen palvelimen pystyttämistä, tarkemman hallinnan siitä, mitkä sähköpostit voivat liittyä vuokraajaan, sekä sujuvamman polun salasanan palauttamiseen loppukäyttäjille. Kulissien takana Logto siirtyy käyttämään node-oidc-provider v9:ää ja Koa 3:a, ja kytkee OIDC-ulospäin lähteville pyynnöille SSRF-suojauksen päälle oletuksena. Tässä uudet ominaisuudet.
Kolmannen osapuolen palvelut tarkistavat usein verkkotunnuksen omistuksen pyytämällä tarjoamaan pienen tiedoston kiinteässä polussa. Tähän asti tämä on tarkoittanut erillisen isännän ajamista Logto-mukautetun verkkotunnuksen rinnalla.
Nyt voit liittää vahvistustiedostoja aktiiviseen mukautettuun verkkotunnukseen Console > Tenant settings > Domains kautta. Jokaisella tiedostolla on:
Polku, joka on joko juuritason tiedostonimi tiedostopäätteellä (esim. /verify.txt) tai polku /.well-known/ alla.
Sisältötyyppi text/plain tai application/json. JSON-sisältö validoidaan tallennettaessa.
Sisältöä maksimissaan 16 KB.
Verkkotunnusta kohden voidaan määrittää enintään 10 tiedostoa ja polkujen on oltava yksilöllisiä. Logto palvelee tarkat GET- ja HEAD-osumat määritetyllä sisältötyypillä ja vahvistetulla vasteella. Olemassa olevat Logto-reitit menevät aina vahvistustiedoston edelle, joten väärin määritetty tiedosto ei koskaan peitä oikeaa päätepistettä. Konsoli on lokalisoitu kaikille tuetuille kielille.
Koska Logto ei käsittele tiedoston sisältöä, tämä toimii kaikille palveluiden vahvistuskäytännöille ilman, että Logto mallintaa palveluntarjoajakohtaista toimintaa.
Sähköpostin käyttöoikeussäännöt: sallitut listat ja jokerikuviot#
Sähköpostin estolistasääntö laajenee kattamaan monipuolisemmat sähköpostikäyttösäännöt, jotka määritellään Console > Security > Email blocklist kautta.
Mukautettu sähköpostin sallittu lista. Määrittele sallittujen sähköpostiosoitteiden, -verkkotunnusten tai jokerikuviot sisältävä lista. Kun sallittu lista on asetettu, vain osuvat sähköpostit hyväksytään uusille rekisteröinneille ja sähköpostin liittämisille—niin sähköposti-rekisteröinnissä kuin tilin sähköpostin muokkaamisessa.
Jokerikuviot. Sekä sallittu että estetty lista hyväksyvät sähköpostiosoitteiden ja -verkkotunnusten jokerikuviot, kuten foo*@example.com, *@example.com ja @*.example.com, sekä tismalleen osuvat osoitteet ([email protected]) ja verkkotunnukset (@example.com).
Ristiriitavaroitukset. Konsoli varoittaa, kun sallituissa on syötettä, joka täsmää myös estosääntöön, kun sallittu lista käyttää plussaa mutta sähköpostin ali-osoitteet on estetty, sekä jos yhdistetyt säännöt estäisivät kaikki uudet sähköpostit.
Täsmäytys- ja validointilogiikka on jaettu uudelleenkäytettäviin apuriin @logto/core-kit:ssä, joten samat säännöt pätevät kaikkialla missä sähköposti tuodaan vuokraajaan.
Experience-sovellus tukee nyt salasanan nollausprosesseja, joissa kertakäyttöiset taikalinkit varmennetaan suoraan salasanan palautuksen aloitussivulta, tarkistuskoodien ohella.
Kun OIDC-tunnuksia hylätään, koska sovellus ylittää tunnusten maksimimäärän, Logto lähettää nyt Grant.LimitExceeded -webhook-tapahtuman, joka on valittavissa Konsolin webhook-asetuksissa muiden tapahtumien tapaan.
Lähetyksen tietosisältö kertoo userId, applicationId, revokedGrantIds, maxAllowedGrants ja preRevocationActiveGrantCount. Tapahtuma lähetetään kertakäyttöisesti: epäonnistumiset kirjataan TriggerHook.Grant.LimitExceeded -auditlokiin eivätkä ne koskaan estä tunnistautumisvastetta.
Suurin muutos on tietoturvakorjaus tunnusten hylkäämiseen.
Opaakin käyttöoikeustunnuksen hylkääminen hylkää nyt kaikki saman grantin tunnukset, mukaan lukien päivitystunnukset. V8:ssa päivitystunnus säilyi käytettävissä vielä hylkäämisen jälkeen, ja sillä saattoi pyytää uusia käyttöoikeustunnuksia.
Muita protokollapäivityksiä v9:ssä:
Hylkäyspäätepiste hylkää nyt JWT-käyttöoikeustunnukset koodilla unsupported_token_type palauttamisen sijaan, kuten v8:ssa, missä mitään ei oikeasti hylätty.
RFC 8414 mukainen auktorisointipalvelimen metadata-päätepiste löytyy polusta /oidc/.well-known/oauth-authorization-server.
Turha at_hash-claim poistetaan ID-tunnuksista, jotka annetaan token-päätepisteestä.
ID-tunnukset eivät enää sisällä valinnaista typ: "JWT" -otsaketta. OpenID Connect määrittelee ID-tunnukset JWT:iksi eikä vaadi asiakkaan tarkistamaan tätä otsikkoa.
Toimenpide vaaditaan mukautetulle ID-tunnuksen vahvistukselle. Mikäli käytät virallista Logto SDK:ta, toimenpiteitä ei vaadita. Jos integraatiosi tekee mukautettua ID-tunnuksen vahvistusta, päivitä se sallimaan at_hash-claimin ja typ: "JWT" -otsikon puuttuminen.
Logto toimii nyt Koa 3:lla, aktiivisesti ylläpidetyllä versiolla, joka saa Koa:n turvallisuuspäivitykset ensimmäisenä. Käyttäytymisen ei odoteta muuttuvan: kaikki päätepisteet, OIDC-ohjaus ja API-vastaukset säilyvät entisellään.
Sisäisiä sovellussalaisuuksia ei enää paljasteta Management API:en kautta.
Sähköpostin estolistasääntö ei enää näy julkisissa kirjautumiskokemuksissa.
Tallennettujen kolmannen osapuolen palveluiden tunnuksien hakeminen Account API:sta vaatii nyt identities-käyttäjäskoopin, kuten muutkin SSO-tunnistepäätepisteet.
Account API:n vahvistuskoodeja ei enää lähetetä estetylle sähköpostille.
Sähköpostin ja sähköpostidomainin tarkistus täsmää nyt kokonaiseen arvoon ja käyttää tiukempaa domainin label-tarkastusta.
Jos sosiaalinen tai SSO-rekisteröintivirta hylätään sähköpostin käyttöoikeussääntöjen vuoksi, virheen kuittaus palauttaa käyttäjän Logto-kirjautumissivulle sen sijaan että ohjaisi takaisin ulkoiseen tunnistepalveluun.
MFA otetaan nyt käyttöön automaattisesti käyttäjän liitettyä tekijän Account API:en kautta.
Uuden sähköposti- tai SMS-liitännäisen luonti suorittaa lisäyksen ja vanhojen liitinten siivouksen yhdessä tietokantatransaktiossa. Aiemmin kaatuminen kahden lauseen välissä saattoi jättää kaksoiskappaleita.
Redis-klusterin tunnukset dekoodataan nyt prosenttimerkein, joten yhteydet onnistuvat myös, jos käyttäjänimi tai salasana sisältää URL-varattuja merkkejä.
TLS otetaan nyt käyttöön oikein Redis-klusterin yhteyksissä, jotka käyttävät rediss-protokollaa.
jose v6: Apple-, Google-, OAuth- ja OIDC-liitännäiset käyttävät nyt jose 6 -versiota, joka toimii Web Crypto API:n päällä eikä Node:n crypto-moduulin. Tunnuksen allekirjoitus ja ID-tunnuksen vahvistus toimii kuten aiemmin.
GitLab: Poistettu turha jose-riippuvuus, jolloin liitännäisen asennus ei enää vedä mukaansa tarpeetonta pakettia.
Aliyun SMS: Hongkongilaiset puhelinnumerot tunnistetaan nyt ulkomaanumeroiksi.
Aliyun SMS authentication service (MAS): Allekirjoitus syötetään nyt vapaana tekstinä valintaikkunan sijaan, joten se toimii jos Aliyun vaihtaa allekirjoituksia uudelleen.
Toimenpide vaaditaan — OIDC-tarjoajan SSRF-suojaus. Ulospäin lähtevien pyyntöjen turvallisuutta on vahvistettu ja SSRF-suojaus on oletusarvoisesti päällä. Omassa palvelinympäristössä, jonka täytyy päästä yksityisverkon luotetuille päätepisteille, aseta OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true ennen Logton käynnistystä; muulloin jätä muuttuja määrittämättä.
Tietokannan migraatio vaaditaan. Tässä päivityksessä on mukana skeeman muutoksia mukautettujen vahvistustiedostojen, sisäisten indeksointien ja taulujen osalta. Päivityksen jälkeen suorita tietokannan muutokset komennolla (npm run alteration deploy@logto/cli/core-kuvassa, tai logto db alteration deploy) ennen uuden version käynnistämistä. Katso päivitysohjeet yksityiskohtiin.
Mukautettu ID-tunnuksen vahvistus. Katso node-oidc-provider v9 -osio yllä koskien at_hash- ja typ-otsakemuutoksia.