v1.16.0

Custom JWT

JWT access tokens can now be customized with additional claims using custom JavaScript code snippets. This feature is useful when you need to include custom data in the token for compatibility with other systems.

To use this feature, navigate to the "Custom JWT" tab in the Console. Both user and machine-to-machine (M2M) tokens can be customized.

Before deploying the changes, you can use the "Run test" button to see how the token will look with the custom claims.

See 🎫 Custom JWT claims for more information.

Warning

In the open-source version, the code for custom JWT will run in the same environment as the rest of the Logto code. Be careful when adding custom code to the JWT, as it can introduce security vulnerabilities.

API resources for organization roles

You can now assign permissions (scopes) from the API resources to organization roles. Like other permissions in the organization template, these permissions are organization-level, meaning that they only apply to a specific organization.

Let's see an example:

• There is an API resource called https://shopping.api/.
• The API resource has two scopes: read and write.
• There are two organization roles: admin and user.
• The admin role has both read and write scopes; the user role has only the read scope.
• A user Alice is assigned the admin role in the organization foo, and the user role in the organization bar.

When Alice tries to exchange an organization token for the https://shopping.api/ resource, she will receive a token with scopes based on which organization she is requesting the token for.

For the foo organization, Alice will receive a token with both read and write scopes. For the bar organization, she will receive a token with only the read scope.

See 🏢 Organizations (Multi-tenancy) for a comprehensive introduction to organizations.

Third-party app permissions

Organizational API resources can also be used when configuring permissions for third-party apps. User will be prompted to select an organization when configuring permissions for a third-party app.

Organization custom data

Now you can save additional data associated with the organization with the organization-level customData field by:

• Editing in the Console organization details page.
• Specifying the customData field when using organization Management APIs.

Connectors

• Added Hugging Face connector.
• GitHub connector now has the user:email as part of default scope to fetch GitHub account's private email address list.
  • It now picks the verified primary email among private email address list as a fallback if the user does not set a public email for GitHub account.
• Removed the plus sign in front of the phone number in the feishu connector (#5801). Credit @kamto7.

Improvements

• Added support for Redis Cluster and extra TLS options for Redis connections (#5619). Credit @alekitto.
• OIDC and OAuth 2 connectors now support client_secret_basic and client_secret_jwt client authentication methods for the token endpoint.
• When a user is deleted or suspended through Management API, they will be signed out in Logto and their sessions will be invalidated immediately.
• Support comma separated resource parameter as some libraries do not support array of resources.
• Added an API to fetch user organization scopes based on user organization roles (GET /api/organizations/:id/users/:userId/scopes).
• Added Java Spring Boot web integration guide.
• Added zh-cn phrases in OIDC consent page (#5606). Credit @the-pawn-2017.

Fixes

• Organization invitation APIs should handle invitee emails case insensitively.
• Management API will not return 500 in production for status codes that are not listed in the OpenAPI spec.
• Return 403 instead of 400 when Logto tries to grant an access token to a user lacking the required permissions, especially when granting for organization related resources.
• Fixed the wrong social sign-in callback that posts to the native container (e.g. WKWebView in iOS).
• Fixed the new user from SSO register hook event not triggering bug.
• Fixed a bug that API resource indicator does not work if the indicator is not followed by a trailing slash or a pathname.

v1.15.0

Direct sign-in

You can now directly invoke a sign-in method by skipping the first screen. This is useful when you have a direct link to a sign-in method, for instance, when you have a "Sign in with Google" button on your website.

To use this feature, you need to pass the direct_sign_in parameter to the authentication request. It supports the following methods:

• A social connector
• An enterprise SSO connector

To learn more, see the Direct sign-in documentation.

First screen parameter

Sign-in experience can be initiated with a specific screen by setting the first_screen parameter in the OIDC authentication request. This parameter is intended to replace the interaction_mode parameter, which is now deprecated.

See the First screen documentation for more information.

Full OpenID Connect standard claims support

We have added support for the remaining OpenID Connect standard claims. Now, these claims are accessible in both ID tokens and the response from the /me endpoint.

Additionally, we adhere to the standard scopes - claims mapping. This means that you can retrieve most of the profile claims using the profile scope, and the address claim can be obtained by using the address scope.

For all newly introduced claims, we store them in the user.profile field.

Note

Unlike other database fields (e.g. name), the claims stored in the profile field will fall back to undefined rather than null. We refrain from using ?? null here to reduce the size of ID tokens, since undefined fields will be stripped in tokens.

Social data

In addition to the claims that Logto recognizes, all social connectors now also store the raw data returned by the social provider in the rawData field.

To access this data in a user object, you can use the user.identities.[idp-name].details.rawData field.

Lazy password migration

When migrating users from a legacy system to Logto, you can now use the passwordAlgorithm and passwordDigest fields in the POST /users API to store the user's original password hash.

Currently supported algorithms are:

• Bcrypt
• MD5
• SHA1
• SHA256
• Argon2i

When the user logs in, Logto will use the provided algorithm and digest to verify the password; if the verification succeeds, Logto will automatically migrate the password to the new Argon2 hash.

See API reference for more information.

Improvements

• Support avatar and customData fields in the POST /users API.
• Support signing key rotation in Logto OSS Console.
• Carry over search params to the authentication request in the live preview (demo app).
  • When entering the Logto demo app with search parameters, if the user is not authenticated, the search parameters are now carried over to the authentication request. This allows manual testing of the OIDC authentication flow with specific parameters.
• GET /organization-roles can now be called with the q query parameter to filter the results by the role id, name, or description.

Fixes

• Console: Fixed issues in the Microsoft social connector integration guide.
• Console: To create a new API resource, the indicator must be a valid absolute URI.
• Experience: Resolved third-party app's /interaction/consent endpoint 500 error.
• Experience: Skip non-object messages in the native environment. This fixes an issue in the WKWebView of new iOS versions.

Development

• @logto/connector-kit: [BREAKING] update SocialUserInfo and GetUserInfo types
• @logto/connector-kit: [BREAKING] guard results of parseJson and parseJsonObject

v1.14.0

New features

• Support form post callback for social connectors
  • Add the POST /callback/:connectorId endpoint to handle the form post callback for social connectors. This is useful for the connectors that require a form post callback to complete the authentication process, such as Apple.
• SMTP connector: Always show TLS configurations in Logto Console
• Apple connector: Support scope parameter
  • Now you can request for email and name during Sign in with Apple

v1.13.1

Console application guides

• Add Angular, Nuxt, SvelteKit, Expo (React Native) guides
• Update Next.js guide

v1.13.0

Logto as an OpenID Connect identity provider

From now, you can use Logto as an third-party OpenID Connect identity provider by creating an OIDC third party app during the application creating process.

This enables you to configure the permissions that the app requests and the branding for each third party app. When users sign in via this app, it will prompt for user consent:

This feature is useful for multiple scenarios, such as integrating third party services with Logto for in-house identity management, providing an open platform for developers creating third party apps, etc. See 🌐 Logto as an Identity Provider (IdP) to learn more.

Guides

Added .NET Core Blazor WebAssembly and Blazor Server app guides.

Misc.

• Upgrade TypeScript to 5.3.3.
• Use Node v20 LTS. We mark it as minor because Logto is shipping with Docker image and it's not a breaking change for users.

---

For detailed changelog, see this pull request.

v1.12.0

Tip

Logto is an open-source Auth0 alternative designed for modern apps and SaaS products.

---

Logto Organizations (Multi-tenancy)

The term "organization" is also used in other forms, such as "workspace", "team", "company", etc. In Logto, we use "organization" as the generic term to represent the concept of multi-tenancy.

From now, you can create multiple organizations in Logto, each of which can have its own users, while in the same identity pool.

Plus, we also introduce the concept of "organization template". It is a set of permissions and roles that applies to all organizations, while a user can have different roles in different organizations.

We believe this is extremely useful for SaaS products with collaboration features (we love collaboration!). For more information, see 🏢 Organizations (Multi-tenancy).

Enterprise SSO (single sign-on)

Enterprise SSO is designed to support any SAML and OIDC connection, offering the simplest configuration and powered by Logto.

It automatically recognizes all registered domains in the sign-in experience and redirects users to the correct identity provider for authentication. Meanwhile, you can focus on enhancing other aspects of your product without modifying a single line of code.

In this release, we have the following built-in enterprise connectors:

• Google Workspace
• Microsoft Entra ID (formerly Azure AD)
• Okta

To learn more about Enterprise SSO, see ☁️ Enterprise SSO (SAML & OIDC).

Improvements

• Bump libphonenumber-js to v1.10.51 to support China 19 started phone numbers. Credit @agileago.
• Add user ip to webhook event payload.
• The response from /api/swagger.json now includes a summary and description for each API. We will gradually add more helpful information.

---

Note

Multi-factor authentication (MFA) was released in v1.11.0.

v1.11.0

Multi-factor authentication (MFA)

Now you can activate MFA with just one click and take control of the user security. We've made it easy to customize the sign-in experience with these methods:

• Authenticator app OTP: users can add any authenticator app that supports the TOTP standard, such as Google Authenticator, Duo, etc.
• WebAuthn (Passkey): users can use the standard WebAuthn protocol to register a hardware security key, such as biometric keys, Yubikey, etc.
• Backup codes: users can generate a set of backup codes to use when they don't have access to other MFA methods.

For a smooth transition, we also support to configure the MFA policy to require MFA for sign-in experience, or to allow users to opt-in to MFA.

Check out our One-click MFA integration blog post to learn more.

Work in progress

Organizations and enterprise Single Sign-On (SSO) functionalities are on the horizon. With Logto, creating multi-tenancy applications and becoming enterprise-ready will not be a business blocker anymore.

v1.10.1

Fixes

fix 500 error when using search component in console to filter both roles and applications

v1.10.0

New feature: machine-to-machine role-based access control

Role-based access control (RBAC) now extends to machine-to-machine apps. This update allows you to effectively manage permissions for your machine-to-machine apps using the same approach for user authorization.

Note
If you have switched on the "Enable admin access" toggle for machine-to-machine apps, it has been retired in favor of a new "Management API access" role; if you haven't enabled it, a new role with Management API permissions is needed to access the Logto Management API. See 🚝 Interact with Management API to learn more.

Starting today, when you create a new role, you can select either a "user role" or a "machine-to-machine app role" by expanding more options. All existing roles have automatically been converted to "user roles".

Constraints

• After creating a role, you cannot modify its type.
• The Logto Management API resource can only be accessed by machine-to-machine application roles.

Management API updates

Added APIs

Applications

• POST /applications/:appId/roles assigns role(s) to the M2M application
• DELETE /applications/:appId/roles/:roleId deletes the role from the M2M application
• GET /applications/:appId/roles lists all roles assigned to the M2M application

Roles

• POST /roles/:roleId/applications assigns the role to multiple M2M applications
• DELETE /roles/:roleId/applications/:appId removes the M2M application assigned to the role
• GET /roles/:roleId/applications lists all M2M applications granted with the role

Updated APIs

Roles

• POST /roles to specify the role type (either user or machine-to-machine role)

Users

• POST /users/:userId/roles to prevent assigning M2M roles to end-users

Support roles scope for issuing the roles claim in ID tokens

When you include the roles in the scope parameter of the Logto SDK config (or manually append to the OpenID Connect auth request), the ID token will include a roles claim containing an array of the user's roles. This may resolve #3411.

Security update

If an identifier (username, email, or phone number) experiences five authentication failures within an hour, it will be temporarily blocked from the authentication process for ten minutes.

v1.9.1

Fixes

• fix a bug that prevents user from customizing i18n translations in sign-in experience config
• add more intuitive code samples and fix mistakes in express api guide