Logto v1.43.0 tuo mukanaan dynaamiset sovellukset OAuth Client ID Metadata -dokumenteilla, allekirjoitetut SAML-todennuspyynnöt, rajatun Custom JWT- ja Actions-ajoympäristön, vahvemman token-vaihdon validoinnin sekä laajennetun SSRF-suojauksen webhookeille ja yrityksen SSO:lle.
Logto v1.43.0 laajentaa tapoja, joilla sovellukset ja yrityksen identiteetin tarjoajat yhdistyvät, samalla vahvistaen tokenien ja ulosmenevien pyyntöjen turvallisuusrajoja. Julkaisu tuo dynaamiset sovellukset OAuth Client ID Metadata -dokumenteilla, allekirjoitetut SAML-todennuspyynnöt sekä yhtenäisen ajoympäristön Custom JWT:lle ja Actionseille. Julkaisu koventaa myös tokenien vaihtoa, webhookeja ja yritys-SSO:ta, lisäksi Account Centerin parannukset, tuki espanjalle (Meksiko) ja luotettavuuskohennukset. Tässä uutta.
Kirjautumiskokemus tukee nyt es-MX (espanja, Meksiko).
Käyttäjille, joiden kieli on espanja (Meksiko), puhelinnumeron maa-asetuksena on oletuksena Meksiko (+52). Tämä julkaisu korjaa myös listamuotoilijan paikkamerkit ja jäljellä olevan kääntämättömän MFA-viestin espanjalaisissa lokaatioissa.
Lähtevät pyynnöt, jotka on määritetty Management API:n kautta, estetään nyt, kun ne kohdistuvat loopback-, yksityis-, link-local-, pilvimeta- tai muihin erikoisosoitteisiin.
Suojaus kattaa nyt:
Webhookin toimituksen, mukaan lukien POST /api/hooks/:id/test.
OIDC-yritys-SSO:n discovery-, token-, ja userinfo-pyynnöt.
SAML identity-provider -metadatan lataamisen.
Jokaisen näiden pyyntöjen uudelleenohjauksen.
DNS-nimet tarkistetaan yhteyden muodostusvaiheessa, joten isäntä, joka palauttaa suojatun osoitteen, estetään kuten annettu IP-osoite.
Ensimmäisen osapuolen subject-tokenien vaatimisen lisäksi Logto varmistaa nyt, että JWT, jota esitetään subjectina access_token:na, on todella access token.
JWT:n täytyy sisältää:
RFC 9068 at+jwt -tyyppiheaderin.
client_id -väitteen.
OIDC ID -tokenit ja muut vuokraajan allekirjoittamat JWT:t eivät enää kelpaa access tokeniksi. Virheelliset subject-tokenit torjutaan invalid_grant-vastauksella.
Kolmannen osapuolen sovellukset eivät voi enää muokata käyttäjätietoja Account API:n tai Verification API:n kautta. Tällaiset pyynnöt palauttavat nyt:
Ensimmäisen osapuolen sovellukset, mukaan lukien Account Center ja Console, eivät kuitenkaan rajoitu.
Tarkistus epäonnistuu suljetusti ratkaisemattomille client-tunnisteille. Tämä koskee myös poistettuja sovelluksia, joiden access tokenit ovat yhä voimassa, ja CIMD-asiakkaita, joiden tunnisteena on metadatan URL.
Yhtään lukureittiä ei suojattu uudella tarkastuksella. Kuitenkin seuraavat lukupyynnöt vaativat varmennustiedot, jotka on luotu suojattujen reittien kautta, joten kolmansien osapuolien sovellukset eivät enää pääse niihin:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Keskeytetyt käyttäjät eivät voi saada uusia tokeneita#
Token-myynti ja userinfo torjutaan nyt keskeytetyille käyttäjille invalid_grant:lla, mikä vastaa jo käytössä olevaa käytöstä poistettujen käyttäjien kohdalla.
Tämä koskee refresh token-, valtuutuskoodi-, laite-koodi- ja token exchange -kulkuja — vaikka aiempi tokenin tai session peruutus ei olisi onnistunut.
Kolmannen osapuolen sovelluksen skoopit validoidaan uudelleen#
Kun käyttäjäskooppi poistetaan kolmannen osapuolen sovelluksen suostumusasetuksista, tämä vaikuttaa nyt olemassa oleviin myönnytyksiin sekä uusiin valtuutuspyyntöihin.
Refresh token -vaihdossa poistettu scope jätetään pois.
Valtuutuspyynnöt, jotka jatkavat olemassa olevaa myöntöä, epäonnistuvat invalid_scope:lla, kun tarpeen.
Organisaatiotokenpyynnöt epäonnistuvat insufficient_scope:lla sen jälkeen, kun organizations scope on poistettu.
Suostumusruudun latauksen aikana poistettua scopea ei enää myönnetä suostumuksen annetua.
Tunnisteen esto käyttää normalisoituja tunnisteita#
Sentinel-lukitustilastot käyttävät nyt samaa normalisoitua tunnistemuotoa kuin käyttäjähaku:
Sähköpostit pieniksi kirjaimiksi.
Puhelinnumerot kanonisoidaan.
Käyttäjänimet käsitellään kirjainkoosta riippumattomasti, jos vuokraajan politiikka sallii sen.
Tällä estetään vaihtoehtoisilla kirjoitusmuodoilla useiden yritysyritysten syntyminen, mikä heikentäisi maxAttempts-suojaa.
Manuaalinen avaus poistaa myös samankaltaiset kirjoitusasut, jos kyseessä on sama käyttäjätili. Päivityksen jälkeen olemassa oleva epäkanoninen estotila voi päättyä aiemmin, mutta mikään käyttäjä ei lukitu entistä pahemmin.
Kolmannen osapuolen sovelluksen valtuutuksen peruminen mitätöi nyt vain kyseisen sovelluksen tokenit. Käyttäjän selaimen SSO-istunto säilyy aktiivisena.
Elliptic Curve -allekirjoitusavaimet ilmoittavat nyt niiden käyrään sopivan algoritmin: P-256 käyttää ES256, P-384 käyttää ES384 ja P-521 käyttää ES512.
Siirtyminen passkey-kirjautumisesta kertakoodikirjautumiseen ei enää estä käyttäjiä suorittamasta CAPTCHA:a loppuun.
OIDC:n invalid_scope ja insufficient_scope -viestit näyttävät nyt estetyn scope-arvon raakojen {{error_description}} tai {{scope}}-paikkamerkkien sijaan.
Safari ja muut salasananhallinnat voivat nyt ehdottaa ja tallentaa vahvan salasanan uuden salasanan valinnassa ja vaihdossa, käyttäen oikeaa tunnistetta.
Accept-Language -laatuarvot joidenkin välilyöntien, kuten en; q=0.7, kera tulkitaan nyt oikein. Virheelliset arvot palautuvat turvallisesti sen sijaan, että tuottaisivat NaN.
Gmailin mukautettu sallittu- ja estetty-listan vertailu kohtelee gmail.com:ia ja googlemail.com:ia yhtäpitävästi ja jättää pisteet huomioimatta paikallisessa osassa.
Console tarjoaa nyt selkeämmät esimerkit, kuvaukset ja lyhyemmät paikkamerkit mukautetuille sähköpostisäännöille.
Account Centerin tai rekisteröitymisen asetusten tallennus poistaa nyt viittaukset poistettuihin mukautettuihin profiilikenttiin, sen sijaan että palauttaisi custom_profile_fields.entity_not_exists_with_names.
Poistetut kentät ovat yhä poistettavissa Consolesta, vaikka niiden käyttöoikeuden hallinta on pois päältä.
Management API:n relaatiopäätepisteet hyväksyvät nyt tyhjän scope- tai roolilistan no-op:na sen sijaan että palauttaisivat 500-virheen. Tämä koskee esimerkiksi seuraavia reittejä:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
Päivämäärän validointi vastaa nyt koko syötettä ja hylkää perässä olevat merkit muuten kelvollisen päivämäärän jälkeen.
Webhookin POST-pyynnöt yrittävät nyt toimitusta enintään kolme kertaa, jos päätepiste palauttaa HTTP 5xx -vastauksen, mikä vastaa dokumentoitua toimitussopimusta.
Koska uudelleen yritetty tapahtuma voidaan välittää useammin kuin kerran, webhookin vastaanottajan tulisi käsitellä tapahtumat idempotentisti.
Microsoft Azure AD -liitin tukee nyt disableEmailSync-vaihtoehtoa.
Oletuksena liitin kopioi Microsoft Graphin mail-attribuutin Logton käyttäjäprofiiliin. Ota vaihtoehto käyttöön, kun liitin tulee tunnistaa käyttäjä synkronoimatta kyseistä osoitetta, jolloin käytös vastaa Azure OIDC -yritys-SSO:n nykyistä toimintaa.
Toimi — lähtevien pyyntöjen suojaus: Jos webhookit tai yritys-SSO-liittimet tarkoituksella käyttävät palveluita yksityisessä verkossa, lisää tarvittavat IP-osoitteet tai CIDR-alueet SSRF_ALLOWED_ADDRESSES:iin ennen päivitystä:
Sallittujen osoitteiden rajaaminen vain tarvittaviin kohteisiin on turvallisempaa kuin suojauksen poistaminen kokonaan.
Dynaamisten sovellusten yhteensopivuus:SSRF_ALLOWED_ADDRESSES:n asetukseen ottaminen poistaa CIMD:n käytöstä, joten todennuksettomat dynaamiset asiakkaat eivät voi käyttää sallittua listaa päästäkseen yksityisiin palveluihin. SSRF_PROTECTION_DISABLED=true poistaa myös CIMD:n.
Konfiguraation yhteensopivuus:OIDC_PROVIDER_SSRF_PROTECTION_DISABLED tuetaan edelleen alias-muuttujana muuttujalle SSRF_PROTECTION_DISABLED. Nämä muuttujat koskevat vain omaan käyttöön asennettuja ympäristöjä.
Skriptien ajonaikarajoitukset: Custom JWT- ja Actions-skriptien on valmistuttava viidessä sekunnissa, pysyttävä 128 Mt muistirajassa ja palautettava JSON-sarjoitettavia arvoja.
Tietokantamuunnos vaaditaan: Tämä julkaisu sisältää uusia skeemamuutoksia ja indeksejä. Päivityksen jälkeen suorita tietokantamuunnoskomento (npm run alteration deploy hakemistossa @logto/cli/core tai logto db alteration deploy) ennen uuden version käynnistystä. Katso päivitysohje.
