Aggiornamento del prodotto Logto: stato di conformità, JWT personalizzato, risorse API per ruoli dell'organizzazione e altro
Siamo entusiasti di condividere gli ultimi aggiornamenti sulla conformità e le nuove funzionalità. È stato un mese produttivo per il team di Logto, quindi assicurati di aver preparato il tuo caffè preferito prima di immergerti.
GaoFounder
Smetti di sprecare settimane sull'autenticazione degli utenti
Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.
Logto Cloud ora supera tutti i controlli SOC 2 dalla piattaforma di automazione della conformità. Abbiamo programmato un audit di Tipo I SOC 2 e stiamo lavorando verso un audit di Tipo II SOC 2.
I token di accesso JWT possono ora essere personalizzati con dichiarazioni aggiuntive utilizzando frammenti di codice JavaScript personalizzati. Questa funzionalità è utile quando hai bisogno di includere dati personalizzati nel token per la compatibilità con altri sistemi.
Per utilizzare questa funzionalità, vai alla scheda "JWT personalizzato" nella Console. Sia i token utente che quelli macchina a macchina (M2M) possono essere personalizzati.
Prima di distribuire le modifiche, puoi utilizzare il pulsante "Esegui test" per vedere come apparirà il token con le dichiarazioni personalizzate.
Ora puoi assegnare permessi (scope) dalle risorse API ai ruoli dell'organizzazione. Come gli altri permessi nel modello organizzativo, questi permessi sono a livello organizzativo, il che significa che si applicano solo a una specifica organizzazione.
Vediamo un esempio:
Esiste una risorsa API chiamata https://shopping.api/.
La risorsa API ha due scope: read e write.
Ci sono due ruoli dell'organizzazione: admin e user.
Il ruolo admin ha entrambi gli scope read e write; il ruolo user ha solo lo scope read.
Una utente Alice ha assegnato il ruolo admin nell'organizzazione foo, e il ruolo user nell'organizzazione bar.
Quando Alice cerca di scambiare un token dell'organizzazione per la risorsa https://shopping.api/, riceverà un token con scope basate sull'organizzazione per cui sta richiedendo il token.
Per l'organizzazione foo, Alice riceverà un token con entrambi gli scope read e write. Per l'organizzazione bar, riceverà un token con solo lo scope read.
Le risorse API organizzative possono anche essere utilizzate quando si configurano i permessi per app di terze parti. L'utente sarà invitato a selezionare un'organizzazione quando si configurano i permessi per un'app di terze parti.
Il connettore GitHub ora ha user:email come parte dello scope predefinito per recuperare l'elenco degli indirizzi email privati dell'account GitHub.
Ora seleziona l'email primaria verificata tra l'elenco degli indirizzi email privati come fallback se l'utente non imposta un'email pubblica per l'account GitHub.
Rimosso il segno più davanti al numero di telefono nel connettore feishu (#5801). Credito a @kamto7.
Le API di invito dell'organizzazione dovrebbero gestire le email degli invitati in modo insensibile alla maiuscola.
L'API di gestione non restituirà 500 in produzione per codici di stato non elencati nelle specifiche OpenAPI.
Restituisce 403 invece di 400 quando Logto cerca di concedere un token di accesso a un utente privo dei permessi richiesti, specialmente quando si concede per risorse legate all'organizzazione.
Corretto il callback di accesso sociale errato che pubblica sul container nativo (ad esempio, WKWebView su iOS).
Corretto bug che non attivava l'evento di registrazione dall'hook di un nuovo utente da SSO.
Corretto bug in cui l'indicatore della risorsa API non funzionava se non era seguito da una slash finale o un pathname.
