Logto v1.42.0 introducerar verifieringsfiler för anpassade domäner, tillåtna e-postadresser med jokertecken, återställningslänkar för lösenord, en Grant.LimitExceeded-webhook samt uppdatering av protokollager med node-oidc-provider v9, Koa 3 och SSRF-skydd aktiverat som standard.
SimengDeveloper
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.42.0 är en domän- och protokollrelease. Den ger team möjligheten att bevisa domänägarskap utan att behöva sätta upp en extra värd, bättre kontroll över vilka e-postadresser som får komma in i en tenant samt ett smidigare lösenordsåterställningsflöde för slutanvändare. Under huven flyttar denna version Logto till node-oidc-provider v9 och Koa 3, och aktiverar SSRF-skydd för utgående OIDC-förfrågningar som standard. Här är allt som är nytt.
Tjänster från tredje part verifierar ofta domänägarskap genom att kräva att du tillhandahåller en liten fil på en fast sökväg. Hittills har detta inneburit att du behövde köra en separat värd bredvid din Logto-anpassade domän.
Du kan nu bifoga verifieringsfiler till en aktiv anpassad domän från Konsol > Tenant-inställningar > Domäner. Varje fil har:
En sökväg som antingen är ett filnamn på rot-nivå med filändelse (t.ex. /verify.txt) eller en sökväg under /.well-known/.
En innehållstyp av text/plain eller application/json. JSON-innehåll valideras vid sparandet.
Innehåll på upp till 16 KB.
Upp till 10 filer kan konfigureras per domän, och alla sökvägar måste vara unika. Logto serverar exakta GET- och HEAD-matchningar med den konfigurerade innehållstypen och med härdade svar. Existerande Logto-rutter har alltid företräde över en verifieringsfil på samma sökväg, så en felkonfigurerad fil kan aldrig skymma en riktig slutpunkt. Konsolupplevelsen är lokaliserad för alla stödda språk.
Eftersom Logto inte hanterar filinnehållet fungerar detta för alla leverantörers verifieringsmetod utan att Logto behöver modellera leverantörsspecifikt beteende.
E-poståtkomstregler: tillåtliste- och jokerteckenmönster#
E-postblockeringspolicyn har nu blivit en mer omfattande uppsättning e-poståtkomstregler, konfigurerbara i Konsol > Säkerhet > E-postblocklista.
Anpassad tillåtliste för e-post. Konfigurera en tillåtliste med e-postadresser, domäner eller jokerteckenmönster. När tillåtlistan är inställd accepteras endast matchande e-postadresser för nya registreringar och nytillagda e-postadresser – både vid e-postregistrering och uppdateringar av kontots e-post.
Jokerteckenmönster. Både tillåtlista och blocklista accepterar jokertecken för adresser och domäner, som foo*@example.com, *@example.com och @*.example.com, samt exakta adresser ([email protected]) och domäner (@example.com).
Konfliktvarningar. Konsolen varnar när en tillåtlistepost också matchar en blockregel, när en tillåtlistepost använder ett plustecken och e-postsubadressering är blockerad, samt när kombinerade regler inte skulle tillåta någon ny e-post alls.
Matchnings- och valideringslogiken delas via återanvändbara hjälpfunktioner i @logto/core-kit, så samma regler gäller överallt där e-post adresser läggs till i en tenant.
Experience-appen stöder nu lösenordsåterställningsflöden som verifierar engångstoken-magiska länkar direkt från sidan för återställning av lösenord, förutom verifieringskoder.
När OIDC-beviljanden raderas för att en applikation har överskridit sitt maximala tillåtna antal beviljanden avfyrar Logto nu en Grant.LimitExceeded-webhookhändelse, valbar i Konsolens webhookinställningar som vilken annan händelse som helst.
Payload rapporterar userId, applicationId, revokedGrantIds, maxAllowedGrants och preRevocationActiveGrantCount. Utsändningen är "fire-and-forget": fel loggas som TriggerHook.Grant.LimitExceeded i granskningsloggen och blockerar aldrig autentiseringssvar.
OIDC-leverantör uppgraderad till node-oidc-provider v9#
Den största ändringen här är en säkerhetsfix vid tokenåterkallelse.
När en opak åtkomsttoken återkallas, återkallas nu även alla tokens under samma beviljande, inklusive refresh-token. I v8 kunde refresh-token fortfarande användas efter återkallelse och fortsätta begära nya åtkomsttokens.
Andra protokolluppdateringar i v9:
Återkallelseslutpunkten avvisar nu JWT-åtkomsttokens med unsupported_token_type, istället för att returnera ett lyckat svar utan att faktiskt återkalla något, som i v8.
RFC 8414-metadata för auktorisationsservern är nu tillgänglig på /oidc/.well-known/oauth-authorization-server.
Den överflödiga at_hash-klamen tas bort från ID-tokens utfärdade vid token-slutpunkten.
ID-tokens inkluderar inte längre den valfria typ: "JWT"-huvudet. OpenID Connect definierar ID-tokens som JWT:er och kräver inte att klienter verifierar detta huvud.
Åtgärd krävs för anpassad ID-tokenverifiering. Ingen åtgärd krävs om du använder ett officiellt Logto SDK. Om din integration hanterar anpassad ID-tokenverifiering, uppdatera så att frånvaro av at_hash-klamen accepteras, samt att frånvaron av typ: "JWT"-huvudet accepteras.
Logto körs nu på Koa 3, den aktivt underhållna versionslinjen som får Koa:s säkerhetsfixar först. Ingen beteendeförändring förväntas: alla slutpunkter, OIDC-flöden och API-svar fungerar som tidigare.
Interna applikationshemligheter exponeras inte längre via Management APIs.
Policyn för e-postblocklista returneras inte längre i offentliga inloggningssvar.
Hämtning av lagrade access tokens för tredjepartsleverantörer genom Kontots API kräver nu identities-användarområdet, likt andra SSO-identitets-API:er.
Kontots API:s verifieringskoder skickas inte längre till blockerade e-postadresser.
Validering av e-post och domän matchar nu kompletta värden och upprätthåller striktare domänetiketter.
Förbättringar inom upplevelse, lagring och stabilitet#
När ett socialt eller SSO-registreringsflöde avvisas av e-poståtkomstregler, återvänder nu användaren till Logtos inloggningssida istället för till den externa identitetsleverantören när felet bekräftas.
MFA aktiveras nu automatiskt efter att en faktor kopplats via Kontots API:er.
När en ny e-post- eller SMS-koppling skapas körs både infogning och borttagning av gamla kopplingar i en och samma databastransaktion. Tidigare kunde en krasch mellan dessa två operationer orsaka dubbletter.
Redis-klusteruppgifter avkodas nu enligt procentsatsen, så anslutningen fungerar när användarnamn eller lösenord innehåller URL-reserverade tecken.
TLS aktiveras nu korrekt för Redis-klusteranslutningar som använder rediss-protokollet.
jose v6: Apple-, Google-, OAuth- och OIDC-kopplingarna använder nu jose 6, som bygger på Web Crypto API istället för Nodes crypto-modul. Tokensignering och ID-tokenverifiering fungerar som tidigare.
GitLab: Den oanvända jose-beroendet har tagits bort, så att installationen av kopplingen inte längre drar in ett paket som aldrig importerades.
Aliyun SMS: Hongkong-nummer behandlas nu som utländska nummer.
Aliyun SMS-autentiseringstjänst (MAS): Signaturen anges nu som fri text istället för i en dropdown, så att det fortsätter fungera om Aliyun roterar signaturerna igen.
Åtgärd krävs — OIDC SSRF-skydd. Utgående förfrågningar är nu säkrare och SSRF-skydd är aktiverat som standard. Självhostade distributioner som behöver nå betrodda rely-party-slutpunkter på privata nätverk måste sätta OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true innan Logto startar, annars lämna variabeln oinställd.
Databasändring krävs. Denna version levererar schemaändringar för verifieringsfiler till anpassad domän samt interna index och tabeller. Efter uppgradering, kör kommandot för databasändringar (npm run alteration deploy i @logto/cli/core-bild, eller logto db alteration deploy) innan du startar den nya versionen. Se uppgraderingsguiden för detaljer.
Anpassad ID-tokenverifiering. Se avsnittet ovan om node-oidc-provider v9 för ändringar kring at_hash och typ-huvudet.
