Logto v1.43.0 voegt dynamische apps toe met OAuth Client ID Metadata Documents, ondertekende SAML-authenticatieverzoeken, een begrensde Custom JWT- en Actions-runtime, sterkere tokenuitwisseling-validatie en uitgebreidere SSRF-bescherming voor webhooks en enterprise SSO.
CharlesDeveloper
Stop met weken verspillen aan gebruikersauthenticatie
Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.
Logto v1.43.0 breidt uit hoe applicaties en zakelijke identiteitsproviders verbinden, terwijl het de beveiligingsgrenzen rond tokens en uitgaande verzoeken versterkt. Het introduceert dynamische apps met OAuth Client ID Metadata Documents, ondertekende SAML-authenticatieverzoeken en een geconsolideerde runtime voor Custom JWT en Actions. De release maakt bovendien token exchange, webhooks en enterprise SSO robuuster, naast verbeteringen aan Account Center, ondersteuning voor Spaans (Mexico) en betrouwbaarheidsfixes. Dit is er nieuw.
De aanmeld-ervaring ondersteunt nu es-MX (Spaans, Mexico).
Voor gebruikers met Spaans (Mexico) als taal, staat het telefooninput standaard op de Mexicaanse landcode (+52). In deze release zijn ook list-formatter placeholders en het laatste niet-vertaalde MFA-bericht in de Spaanse talen opgelost.
Uitgaande verzoeken die via de Management API zijn geconfigureerd, worden nu geblokkeerd als ze leiden naar loopback-, privéadressen, link-locale, cloud metadata of andere speciaal gebruikte adressen.
Bescherming geldt nu voor:
Webhooklevering, inclusief POST /api/hooks/:id/test.
OIDC enterprise SSO ontdekking, tokens en userinfo-verzoeken.
SAML identity-provider metadata ophalen.
Elke redirectstap die deze verzoeken maken.
DNS-namen worden gecontroleerd zodra de verbinding tot stand komt, zodat een hostnaam die naar een beschermd adres resolveert, net als een letterlijk IP-adres wordt geweigerd.
Naast de eis voor first-party subject tokens, valideert Logto nu dat een JWT gepresenteerd als onderwerp van een access_token daadwerkelijk een access token is.
De JWT moet bevatten:
De RFC 9068 at+jwt type-header.
Een client_id claim.
OIDC ID-tokens en andere door de tenant ondertekende JWT's mogen niet langer worden gebruikt als access token. Ongeldige subject tokens worden geweigerd met invalid_grant.
Derde-partij- applicaties kunnen niet langer accountgegevens aanpassen via de Account API of Verification API. Dergelijke verzoeken retourneren nu:
Applicaties van de eerste partij, zoals Account Center en Console, zijn niet beïnvloed.
De controle sluit alle onopgeloste client-identifiers af. Dit geldt ook voor verwijderde applicaties waarvan de access tokens nog actief zijn en CIMD-clients waarvan de identifier een metadata-url is.
Geen enkel leesroute kreeg een nieuwe directe beveiliging. Maar de volgende leesacties vereisen verificatie-records aangemaakt via beveiligde routes en zijn daarom niet langer toegankelijk voor derde-partij- applicaties:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Geschorste gebruikers kunnen geen nieuwe tokens ontvangen#
Token uitgifte en userinfo weigeren nu geschorste gebruikers met invalid_grant, gelijk aan het bestaande gedrag voor verwijderde gebruikers.
Dit geldt voor refresh token-, autorisatiecode-, devicecode- en token exchange-flows, zelfs als een eerdere token of sessie-herroeping niet succesvol is afgerond.
Scopes van derde-partij-applicaties worden opnieuw gevalideerd#
Het verwijderen van een gebruikersscope uit de toestemmingsconfiguratie van een derde-partij-applicatie heeft nu invloed op bestaande toekenningen én op nieuwe autorisatieverzoeken.
Refresh token-exchanges laten scopes vallen die niet meer zijn geconfigureerd.
Autorisatieverzoeken die een bestaande grant hervatten falen met invalid_scope wanneer toepasselijk.
Organisatie-tokenverzoeken mislukken met insufficient_scope nadat de organisatiescope is verwijderd.
Toestemmingsindiening verleent geen scope meer die is verwijderd terwijl het toestemmingsscherm nog geopend was.
Lockoutcounters gebruiken nu dezelfde genormaliseerde identificatievorm als account-opzoekingen:
E-mailadressen worden in kleine letters gezet.
Telefoonnummers worden gecanoniseerd.
Gebruikersnamen worden alleen case-insensitief gemaakt als het gebruikersnaambeleid van de tenant dit vereist.
Dit voorkomt dat alternatieve schrijfwijzen van dezelfde identifier aparte pogingen genereren en maxAttempts verzwakken.
Handmatige deblokkering wist ook gelijkwaardige schrijfwijzen wanneer ze hetzelfde account identificeren. Na de upgrade kan een bestaande lockout met een niet-canonieke schrijfwijze eerder eindigen, maar geen gebruiker raakt meer geblokkeerd dan voorheen.
Intrekken van de autorisatie van een derde-partij-applicatie verwijdert nu alleen de tokens van die applicatie. De SSO-sessie van de gebruiker in de browser blijft actief.
Elliptische Curve-ondertekeningssleutels tonen nu het algoritme dat past bij hun curve: P-256 gebruikt ES256, P-384 gebruikt ES384 en P-521 gebruikt ES512.
Wisselen van passkey-aanmelding naar verificatiecode-aanmelding verhindert niet langer het voltooien van een CAPTCHA door gebruikers.
OIDC-berichten invalid_scope en insufficient_scope tonen nu de geweigerde scope in plaats van de ruwe {{error_description}} of {{scope}} placeholders.
Safari en andere wachtwoordmanagers kunnen nu een sterk wachtwoord suggereren en opslaan op set-password- en reset-password-schermen via de juiste accountidentifier.
Accept-Language kwaliteitswaarden met witruimte, zoals en; q=0.7, worden nu correct geparseerd. Ongeldige kwaliteitswaarden vallen veilig terug in plaats van NaN te produceren.
Gmail custom allowlist en blocklist-behandeling ziet gmail.com en googlemail.com nu als gelijkwaardig en negeert punten in het lokale deel.
Console geeft nu duidelijkere voorbeelden, beschrijvingen en kortere placeholders voor aangepaste e-mailregels.
Opslaan van Account Center- of aanmeldinstellingen verwijdert nu verwijzingen naar verwijderde custom profielvelden, in plaats van custom_profile_fields.entity_not_exists_with_names te retourneren.
Verwijderde velden blijven verwijderbaar vanuit Console, zelfs als hun rechtencontrole uitgeschakeld is.
Management API-relatie-endpoints accepteren nu lege arrays van scopes of rollen als no-op in plaats van een 500-fout. Dit geldt voor endpoints zoals:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
Datavalidatie komt nu overeen met de volledige invoer en wijst overtollige tekens na een anders geldige datum af.
Webhook POST-verzoeken worden nu tot drie keer opnieuw geprobeerd als de endpoint een HTTP 5xx-response retourneert, volgens het gedocumenteerde leveringscontract.
Omdat een opnieuw verstuurde gebeurtenis meer dan eens kan worden geleverd, dienen webhook-ontvangers gebeurtenissen idempotent te verwerken.
De Microsoft Azure AD-connector ondersteunt nu een disableEmailSync-optie.
Standaard blijft de connector het Microsoft Graph mail-attribuut kopiëren naar het Logto-gebruikersprofiel. Schakel deze optie in wanneer de connector de gebruiker moet authenticeren zonder dat adres te synchroniseren, dit komt overeen met het bestaande beheer voor Azure OIDC enterprise SSO.
Actie vereist — bescherming uitgaande verzoeken: Als webhooks of enterprise SSO-connectors bewust services op een privénetwerk moeten benaderen, voeg de vereiste IP-adressen of CIDR-ranges toe aan SSRF_ALLOWED_ADDRESSES vóór het updaten:
Alleen vereiste bestemmingen allowlisten is veiliger dan bescherming wereldwijd uitschakelen.
Compatibiliteit dynamische apps: Het instellen van SSRF_ALLOWED_ADDRESSES schakelt CIMD uit, zodat niet-geauthenticeerde dynamische clients de allowlist niet kunnen gebruiken om private services te bereiken. Ook SSRF_PROTECTION_DISABLED=true schakelt CIMD uit.
Compatibiliteit instellingen: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED wordt nog steeds ondersteund als alias voor SSRF_PROTECTION_DISABLED. Deze variabelen gelden alleen voor zelfgehoste omgevingen.
Limieten script-runtime: Custom JWT- en Actions-scripts moeten binnen 5 seconden klaar zijn, maximaal 128 MB werkgeheugen gebruiken en JSON-serialiseerbare waarden teruggeven.
Database-upgrade vereist: Deze release bevat nieuwe schema-aanpassingen en indexen. Na de upgrade voer je het database-aanpassingscommando uit (npm run alteration deploy in de @logto/cli/core image, of logto db alteration deploy) vóór het starten van de nieuwe versie. Zie de upgradegids.
