Logto v1.41.0 introducerar åtkomstkontroll på app-nivå, lösenordets utgångspolicys, större uppgraderingar av Account Center, konfigurerbara regler för användarnamn och verifieringskod, säkrare meddelandeleverans och en omgång förbättringar av protokoll/säkerhet.
Logto v1.41.0 är en release med fokus på kontroll och säkerhet. Den ger team mer detaljerade sätt att bestämma vem som kan få åtkomst till varje app, mer fullständig kontroll över lösenordets livscykel och ett mycket mer kapabelt Account Center för slutanvändare. Den stramar också åt leverans av verifieringskoder, regler för användarnamn, hantering av SAML/OIDC, skydd mot återanvändning av MFA och uppgraderingsvägar för self-hosting. Här är vad som är nytt.
Du kan nu begränsa tillgången till en applikation direkt från Logto. Åtkomstregler kan rikta sig till specifika användare, användarroller, organisationer eller organisationsroller.
När en användare inte matchar den konfigurerade regeluppsättningen blockerar Logto inloggningen eller appens åtkomstflöde med en sida för nekad åtkomst istället för att låta begäran fortsätta. Detta gör det enklare att hantera appstarter, kundspecifik åtkomst, skydd av interna verktyg och organisationsbegränsad åtkomst utan att behöva lägga allt beslutsfattande i din applikationskod.
Se dokumentationen om åtkomstkontroll på app-nivå för hela installationsflödet.
Console stöder nu lösenordets utgång på hyresgäst-nivå under Security > Password policy.
Administratörer kan aktivera lösenordets utgång, konfigurera hur många dagar ett lösenord är giltigt och manuellt få ett specifikt användarlösenord att gå ut från användardetaljsidan. När ett lösenord går ut måste användaren återställa det genom den konfigurerade återställningsmetoden innan lösenordsinloggning kan fortsätta.
SSO- och passkey-inloggningar påverkas inte. Befintliga användare utan en registrerad tidpunkt för lösenordsbyte hanteras smidigt: Logto förankrar dem till den tid policyn aktiveras så att de får hela den giltiga perioden istället för att omedelbart gå ut.
Account Center fortsätter att växa till en komplett självbetjäningsidentitetsyta för slutanvändare.
Den här releasen lägger till sessionshantering, översikt över anslutna tredjepartsappar, hantering av profil, uppladdning av avatar, avataruppladdning vid registrering med collect-profile, oberoende passkey-kontroller och ett användarinställt val för passkey-inloggningsprompt.
Account Center profilsida, anpassade profilfält vid registrering och avataruppladdnings-endpoints har nu också släppts från utvecklings-gate.
Några viktiga buggar har också rättats här:
Hyresgäst-nivåregler för användarnamn är nu konfigurerbara från Console > Sign-in experience > Sign-up and sign-in > Advanced options.
Policyn omfattar skiftlägeskänslighet, längdgränser och tillåtna teckentyper. Den upprätthålls för alla användarskrivningar, inklusive registrering, profilkomplettering, Account Center, Account API och /me.
Övergång till skiftlägesokänsliga användarnamn är skyddad: Logto kontrollerar om det finns befintliga användarnamn som endast skiljer sig i skiftläge och blockerar policyändringen tills konflikter lösts. OIDC-kravet preferred_username faller nu tillbaka till användarens username när profile.preferredUsername inte är satt.
Kontroller för verifieringskod har också flyttats in i Console säkerhetsinställningar. Administratörer kan konfigurera utgångstid för verifieringskod och maximala antal försök.
Logto tillämpar nu en systemnivå-begränsning av sändningshastighet per mottagare över e-post/SMS-verifiering och inbjudningsvägar, inklusive Experience, MFA, Account API, Management API, /me, organisationsinbjudningar och det äldre interaktions-API:et.
När en sändning stryps skickar Logto en webhook-händelse Message.RateLimited som nu är valbar i Console webhook-inställningar.
Leverans av verifieringskod till okända mottagare undertrycks också när registrering är inaktiverad, vilket minskar risken för kontouppspårning.
För organisationers API-resurstokens får JWT-anpassaren nu context.organization med målorganisationens id, name, description och customData.
Detta gör det enklare att lägga till per-organisations-claims utan att behöva bädda in varje organisationsmappning i varje token.
Några interna API-förbättringar har också införts:
POST /api/applications/:applicationId/roles är nu idempotent. Befintliga roll-ID:n ignoreras istället för att returnera 422 application.role_exists.201 med { roleIds, addedRoleIds }, vilket överensstämmer med API:ets modell för tilldelning av användarroll.Den här versionen innehåller ett antal riktade förbättringar av protokoll och säkerhet:
samlify är uppgraderad till ^2.13.0 för förbättrad XML escaping i genererade SAML-assertions.400 invalid_request.Kompatibilitets- och lagringskorrigeringar ingår också: äldre Safari och iOS 15 kraschar inte längre vid uppstart på grund av saknat stöd för lookbehind-syntax i regex, OIDC företagskopplingar kan hämta upptäcktskonfiguration från leverantörer som avvisar JSON-only förhandling och fel vid överföring av anpassade UI-tillgångar till Azure Blob kartläggs nu till möjliga nedladdningsfel för lagring med möjlighet till försök igen.
Den här versionen lägger till och förbättrar flera kopplingsrelaterade funktioner:
samlify och dess striktare returtyper.En databasändring krävs för v1.41.0. Den här versionen innehåller schemaändringar för lösenordets utgång, användarnamnspolicy, verifieringskodspolicy, index för meddelandehastigheter, standardvärden för Account Center och index för serviceloggar.
Efter uppgradering ska du köra kommandot för databasändring innan du startar den nya versionen. Se uppgraderingsguiden för detaljer.
Miljövariabeln CASE_SENSITIVE_USERNAME är nu föråldrad. Den fungerar fortfarande som en runtime-override, men skiftlägeskänslighet för användarnamn ska konfigureras per tenant via den nya användarnamnspolicyn. Variabeln är planerad att tas bort i nästa stora version.
Redo att uppgradera? Kolla in uppgraderingsguiden för steg-för-steg-instruktioner.
För den fullständiga listan med ändringar, se GitHub releasesidan.
Har du frågor eller feedback? Gå med oss på Discord eller öppna ett ärende på GitHub.