Logto v1.43.0 lägger till dynamiska appar med OAuth Client ID Metadata Documents, signerade SAML-autentiseringsförfrågningar, ett begränsat runtime för Custom JWT och Actions, starkare validering av tokenutbyte och utökad SSRF-skydd för webhooks och företagets SSO.
CharlesDeveloper
Sluta slösa veckor på användarautentisering
Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.
Logto v1.43.0 utökar hur applikationer och företagsidentitetsleverantörer kopplas medan säkerhetsgränserna kring tokens och utgående förfrågningar stärks. Den introducerar dynamiska appar med OAuth Client ID Metadata Documents, signerade SAML-autentiseringsförfrågningar och ett samlat runtime för Custom JWT och Actions. Den här versionen stärker även tokenutbyte, webhooks och företagets SSO, tillsammans med förbättringar i Account Center, stöd för spanska (Mexiko) och stabilitetsfixar. Här är vad som är nytt.
Inloggningsupplevelsen stödjer nu es-MX (spanska, Mexiko).
För användare vars språk är spanska (Mexiko), förinställs telefonnummerinmatning på Mexikos landskod (+52). Den här versionen åtgärdar även platshållare för listformatering och den sista oöversatta MFA-meddelandet i de spanska lokalerna.
Utgående förfrågningar som konfigureras via Management API blockeras nu när de resolvas till loopback, privata, länk-lokala, molnmetadatadress eller andra adresser för specialanvändning.
Skyddet täcker nu:
Webhook-leverans, inklusive POST /api/hooks/:id/test.
OIDC enterprise SSO discovery, token- och userinfo-förfrågningar.
SAML identity-provider metadata-hämtning.
Varje omdirigeringssteg som görs av dessa förfrågningar.
DNS-namn kontrolleras när anslutningen upprättas, så ett värdnamn som resolvas till en skyddad adress avvisas på samma sätt som en bokstavlig IP-adress.
Tredjepartsapplikationer kan inte längre ändra kontodata via Account API eller Verification API. Sådana förfrågningar returnerar nu:
Förstapartsapplikationer, inklusive Account Center och Console, påverkas inte.
Kontrollen misslyckas stängt för olösta klientidentifierare. Detta inkluderar borttagna applikationer vars access tokens fortfarande är aktiva och CIMD-klienter vars identifierare är en metadata-URL.
Ingen läsroute fick ett nytt direkt skydd. Men följande läsningar kräver verifieringsposter skapade via skyddade vägar och är därför inte längre tillgängliga för tredjepartsapplikationer:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Tokenutgivning och userinfo avvisar nu avstängda användare med invalid_grant, i enlighet med redan existerande beteende för borttagna användare.
Detta gäller för alla flöden: refresh token, authorization code, device code och token exchange – även om en tidigare token- eller sessionsavslutning inte slutfördes korrekt.
Att ta bort ett användarscope från en tredjepartsapplikations samtyckeskonfiguration påverkar nu befintliga tilldelningar och nya auktoriseringsförfrågningar.
Refresh token-utbyten tappar scopes som inte längre är konfigurerade.
Auktoriseringsförfrågningar som återupptar en befintlig tilldelning misslyckas med invalid_scope när det är tillämpligt.
Organisationstoken-förfrågningar misslyckas med insufficient_scope efter att organisationsscope tagits bort.
Samtyckesinlämning beviljar inte längre ett scope som togs bort medan samtyckesskärmen var öppen.
Låsningar med identifierare använder normaliserade identifierare#
Sentinel-låsningräknare använder nu samma normaliserade identifierarform som kontouppslag:
E-postadresser görs till gemener.
Telefonnummer kanoniseras.
Användarnamn jämförs utan att ta hänsyn till versaler bara när tenantens användarnamnspolicy är case-insensitiv.
Detta förhindrar att alternativa stavningar av samma identifierare skapar separata försöksbunkar och försvagar maxAttempts.
Manuell upplåsning rensar också likvärdiga stavningar där de identifierar samma konto. Efter uppgradering kan ett befintligt lås inspelat under en icke-kanonisk stavning sluta tidigare, men ingen användare blir mer låst än tidigare.
Att upphäva en användares tredjepartsapplikationsauktorisation ogiltigförklarar nu endast tokens för den applikationen. Användarens webbläsar-SSO-session förblir aktiv.
Elliptiska kurv-signeringsnycklar annonserar nu algoritmen som passar deras kurva: P-256 använder ES256, P-384 använder ES384 och P-521 använder ES512.
Att byta från passkey-inloggning till kodverifieringsinloggning hindrar inte längre användaren från att avklara CAPTCHA.
OIDC invalid_scope och insufficient_scope-meddelanden visar nu det avvisade scopet istället för råa {{error_description}} eller {{scope}}-platshållare.
Safari och andra lösenordshanterare kan nu föreslå och spara ett starkt lösenord på sätta lösenord- och återställ-lösenord-skärmar genom att använda korrekt kontonamn.
Accept-Language-kvalitetsvärden med whitespace, t.ex. en; q=0.7, tolkas nu korrekt. Ogiltiga kvalitetsvärden faller tillbaka säkert istället för att ge NaN.
Gmail anpassad allowlist och blocklist-behandling betraktar nu gmail.com och googlemail.com som ekvivalenta och ignorerar punkter i den lokala delen.
Console ger nu tydligare exempel, beskrivningar och kortare platshållare för egna e-postregler.
Att spara Account Center- eller registreringsinställningar tappar nu referenser till borttagna anpassade profilfält istället för att returnera custom_profile_fields.entity_not_exists_with_names.
Borttagna fält kan fortfarande tas bort från Console även om deras behörighetskontroll är avstängd.
Management API:s relationsändpunkter accepterar nu tomma scope- eller rollarrayer som no-ops istället för att returnera ett 500-fel. Detta inkluderar ändpunkter som:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
Datumvalidering matchar nu hela inmatningen och avvisar tecken som följer efter ett annars giltigt datum.
Webhook-POST-förfrågningar försöks nu upp till tre gånger när ändpunkten returnerar ett HTTP 5xx-svar, vilket överensstämmer med den dokumenterade leveransavtalet.
Eftersom en omprövad händelse kan levereras mer än en gång, bör webhook-mottagare behandla händelser idempotent.
Microsoft Azure AD-connectorn har nu stöd för alternativet disableEmailSync.
Som standard fortsätter connectorn att kopiera Microsoft Graph mail-attributet till Logto-användarprofilen. Aktivera detta alternativ när connectorn ska autentisera användaren utan att synkronisera den adressen, vilket matchar den kontroll som redan finns för Azure OIDC enterprise SSO.
Åtgärd krävs — skydd för utgående förfrågningar: Om webhooks eller enterprise SSO-connectors avsiktligt ska nå tjänster på ett privat nätverk, lägg till de nödvändiga IP-adresserna eller CIDR-intervallen till SSRF_ALLOWED_ADDRESSES före uppgradering:
Att tillåta endast nödvändiga destinationer är säkrare än att inaktivera skyddet globalt.
Dynamisk applikationskompatibilitet: Att konfigurera SSRF_ALLOWED_ADDRESSES inaktiverar CIMD så att icke-autentiserade dynamiska klienter inte kan använda tillåtlistan för att nå privata tjänster. Att ange SSRF_PROTECTION_DISABLED=true inaktiverar också CIMD.
Konfigurationskompatibilitet: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED stöds fortfarande som ett alias för SSRF_PROTECTION_DISABLED. Dessa variabler gäller endast för självhostade installationer.
Skriptbegränsningar: Custom JWT- och Actions-skript måste slutföras inom 5 sekunder, hålla sig inom 128 MB minnesbudget och returnera JSON-serialiserbara värden.
Databasuppgradering krävs: Denna version innehåller nya schemaändringar och index. Efter uppgradering, kör databasens alterationskommando (npm run alteration deploy i @logto/cli/core-image, eller logto db alteration deploy) innan du startar den nya versionen. Se uppgraderingsguiden.
