- 640425414: add `trustUnverifiedEmail` setting for the Microsoft EntraID OIDC SSO connector
Since we launched the **EntraID OIDC SSO connector** we have received several feedbacks that their customer's email address can not be populated to Logto's user profile when signing up through the EntraID OIDC SSO connector.
This is because Logto only syncs verified email addresses, meaning the `email_verified` claim must be `true` in the user info response from the OIDC provider.
However, based on Microsoft's documentation, since the user's email address in manually managed by the organization, they are not verified guaranteed. This means that the `email_verified` claim will not be included in their user info response.
To address this issue, we have added a new `trustUnverifiedEmail` exclusively for the Microsoft EntraID OIDC SSO connector. When this setting is enabled, Logto will trust the email address provided by the Microsoft EntraID OIDC SSO connector even if the `email_verified` claim is not included in the user info response. This will allow users to sign up and log in to Logto using their email address without any issues. Please note this may introduce a security risk as the email address is not verified by the OIDC provider. You should only enable this setting if you trust the email address provided by the Microsoft EntraID OIDC SSO connector.
You can configure this setting in the **EntraID OIDC SSO connector** settings page in the Logto console or through the management API.
- 640425414: display support email and website info on experience error pages.
Added support email and website info to the error pages of the experience app. E.g. when a user tries to access a page that doesn't exist, or when the social session is not found in a social callback page. This will help users to contact support easily when they encounter an error.
You may configure the support email and website info in the sign-in experience settings page in the Logto console or through the management API.
- 7ebef18e3: add account api
Introduce the new Account API, designed to give end users direct API access without needing to go through the Management API, here is the highlights:
1. Direct access: The Account API empowers end users to directly access and manage their own account profile without requiring the relay of Management API.
2. User profile and identities management: Users can fully manage their profiles and security settings, including the ability to update identity information like email, phone, and password, as well as manage social connections. MFA and SSO support are coming soon.
3. Global access control: Admin has full, global control over access settings, can customize each fields.
4. Seamless authorization: Authorizing is easier than ever! Simply use `client.getAccessToken()` to obtain an opaque access token for OP (Logto), and attach it to the Authorization header as `Bearer <access_token>`.
## Get started
> ![Note]
> Go to the [Logto Docs](https://bump.sh/logto/doc/logto-user-api) to find full API reference.
1. Use `/api/account-center` endpoint to enable the feature, for security reason, it is disabled by default. And set fields permission for each field.
2. Use `client.getAccessToken()` to get the access token.
3. Attach the access token to the Authorization header of your request, and start interacting with the Account API directly from the frontend.
4. You may need to setup `logto-verification-id` header as an additional verification for some requests related to identity verification.
## What you can do with Account API
1. Get user account profile
2. Update basic information including name, avatar, username and other profile information
3. Update password
4. Update primary email
5. Update primary phone
6. Manage social identities
- 640425414: add unknown session redirect url in the sign-in experience settings
In certain cases, Logto may be unable to properly identify a user’s authentication session when they land on the sign-in page. This can happen if the session has expired, if the user bookmarks the sign-in URL for future access, or if they directly share the sign-in link. By default, an "unknown session" 404 error is displayed.
To improve user experience, we have added a new `unknownSessionRedirectUrl` field in the sign-in experience settings.You can configure this field to redirect users to a custom URL when an unknown session is detected. This will help users to easily navigate to your client application or website and reinitiate the authentication process automatically.
By default, out database connection timeout is set to 5 seconds, which might not be enough for some network conditions. This change allows users to override the default value by setting the `DATABASE_CONNECTION_TIMEOUT` environment variable.
- 3c993d59c: fix an issue that prevent mp4 video from playing in custom sign-in pages on Safari browser
Safari browser uses range request to fetch video data, but it was not supported by the `koa-serve-custom-ui-assets` middleware in core. This prevents our users who want to build custom sign-in pages with video background. In order to fix this, we need to partially read the video file stream based on the `range` request header, and set proper response headers and status code (206).
Personal access tokens (PATs) provide a secure way for users to grant access tokens without using their credentials and interactive sign-in.
You can create a PAT by going to the user's detail page in Console or using the Management API `POST /users/:userId/personal-access-tokens`.
To use a PAT, call the token exchange endpoint `POST /oidc/token` with the following parameters:
1.`grant_type`: REQUIRED. The value of this parameter must be `urn:ietf:params:oauth:grant-type:token-exchange` indicates that a token exchange is being performed.
2.`resource`: OPTIONAL. The resource indicator, the same as other token requests.
3.`scope`: OPTIONAL. The requested scopes, the same as other token requests.
4.`subject_token`: REQUIRED. The user's PAT.
5.`subject_token_type`: REQUIRED. The type of the security token provided in the `subject_token` parameter. The value of this parameter must be `urn:logto:token-type:personal_access_token`.
6.`client_id`: REQUIRED. The client identifier of the client application that is making the request, the returned access token will contain this client_id claim.
And the response will be a JSON object with the following properties:
1.`access_token`: REQUIRED. The access token of the user, which is the same as other token requests like `authorization_code` or `refresh_token`.
2.`issued_token_type`: REQUIRED. The type of the issued token. The value of this parameter must be `urn:ietf:params:oauth:token-type:access_token`.
3.`token_type`: REQUIRED. The type of the token. The value of this parameter must be `Bearer`.
4.`expires_in`: REQUIRED. The lifetime in seconds of the access token.
5.`scope`: OPTIONAL. The scopes of the access token.
- 3d3a22030: add support for additional first screen options
This feature introduces new first screen options, allowing developers to customize the initial screen presented to users. In addition to the existing `sign_in` and `register` options, the following first screen choices are now supported:
-`identifier:sign_in`: Only display specific identifier-based sign-in methods to users.
-`identifier:register`: Only display specific identifier-based registration methods to users.
-`reset_password`: Allow users to directly access the password reset page.
-`single_sign_on`: Allow users to directly access the single sign-on (SSO) page.
Example:
```javascript
// Example usage (React project using React SDK)
void signIn({
redirectUri,
firstScreen: "identifier:sign_in",
/**
* Optional. Specifies which sign-in methods to display on the identifier sign-in page.
* If not specified, the default sign-in experience configuration will be used.
* This option is effective when the `firstScreen` value is `identifier:sign_in`, `identifier:register`, or `reset_password`.
*/
identifiers: ["email", "phone"],
});
```
- 25187ef63: add support for `login_hint` parameter in sign-in method
This feature allows you to provide a suggested identifier (email, phone, or username) for the user, improving the sign-in experience especially in scenarios where the user's identifier is known or can be inferred.
Example:
```javascript
// Example usage (React project using React SDK)
void signIn({
redirectUri,
loginHint: "user@example.com",
firstScreen: "signIn", // or 'register'
});
```
- b837efead: add access deny method to the custom token claims script
Introduce a new `api` parameter to the custom token claims script. This parameter is used to provide more access control context over the token exchange process.
Use `api.denyAccess()` to reject the token exchange request. Use this method to implement your own access control logics.
```javascript
const getCustomJwtClaims: async ({ api }) => {
// Reject the token request, with a custom error message
return api.denyAccess('Access denied');
}
```
- cc346b4e0: add password policy checking api
Add `POST /api/sign-in-exp/default/check-password` API to check if the password meets the password policy configured in the default sign-in experience. A user ID is required for this API if rejects user info is enabled in the password policy.
Here's a non-normative example of the request and response:
- a748fc85b: fix: add `hasPassword` field to user API response
- fae8725a4: improve RTL language support
- 6951e3157: introduce new `parse_error` query parameter flag. The value of `parse_error` can only be `false`.
By default, Logto returns the parsed error code and error description in all the `RequestError` error responses. This is to ensure the error responses are consistent and easy to understand.
However, when integrating Logto with Google OAuth, the error response body containing `code` will be rejected by Google. `code` is considered as a reserved OIDC key, can't be used as the error code key in the error response body.
To workaround this, we add a new `parse_error` query parameter flag. When parsing the OIDC error body, if the `parse_error` is set to false, only oidc error body will be returned.
example:
```curl
curl -X POST "http://localhost:3001/oidc/token?parse_error=false"
```
```json
{
"error": "invalid_grant",
"error_description": "Invalid value for parameter 'code': 'invalid_code'."
}
```
- 5aab7c01b: prevent user registration and profile fulfillment with SSO-only email domains
Emails associated with SSO-enabled domains should only be used through the SSO authentication process.
Bug fix:
- Creating a new user with a verification record that contains an SSO-only email domain should return a 422 `RequestError` with the error code `session.sso_required`.
- Updating a user profile with an SSO-only email domain should return a 422 `RequestError` with the error code `session.sso_required`.
Introduce a new property `custom_data` to the `Application` schema. This property is an arbitrary object that can be used to store custom data for an application.
Added a new API to update the custom data of an application:
-`PATCH /applications/:applicationId/custom-data`
- 3a839f6d6: support organization logo and sign-in experience override
Now it's able to set light and dark logos for organizations. You can upload the logos in the organization settings page.
Also, it's possible to override the sign-in experience logo from an organization. Simply add the `organization_id` parameter to the authentication request. In most Logto SDKs, it can be done by using the `extraParams` field in the `signIn` method.
For example, in the JavaScript SDK:
```ts
import LogtoClient from "@logto/client";
const logtoClient = new LogtoClient(/* your configuration */);
logtoClient.signIn({
redirectUri: "https://your-app.com/callback",
extraParams: {
organization_id: "<organization-id>",
},
});
```
The value `<organization-id>` can be found in the organization settings page.
If you could not find the `extraParams` field in the SDK you are using, please let us know.
- 62f5e5e0c: support app-level branding
You can now set logos, favicons, and colors for your app. These settings will be used in the sign-in experience when the app initiates the authentication flow. For apps that have no branding settings, the omni sign-in experience branding will be used.
If `organization_id` is provided in the authentication request, the app-level branding settings will be overridden by the organization's branding settings, if available.
- 18c8fdf01: implement token exchange for user impersonation
Added support for user impersonation via token exchange:
1. New endpoint: `POST /subject-tokens` (Management API)
Refer to documentation for usage examples and the [Token Exchange RFC](https://tools.ietf.org/html/rfc8693) for more details.
- d203c8d2f: support experience data server-side rendering
Logto now injects the sign-in experience settings and phrases into the `index.html` file for better first-screen performance. The experience app will still fetch the settings and phrases from the server if:
- The server didn't inject the settings and phrases.
- The parameters in the URL are different from server-rendered data.
- b188bb161: support multiple app secrets with expiration
Now secure apps (machine-to-machine, traditional web, Protected) can have multiple app secrets with expiration. This allows for secret rotation and provides an even safer experience.
To manage your application secrets, go to Logto Console -> Applications -> Application Details -> Endpoints & Credentials.
We've also added a set of Management APIs (`/api/applications/{id}/secrets`) for this purpose.
> [!Important]
> You can still use existing app secrets for client authentication, but it is recommended to delete the old ones and create new secrets with expiration for enhanced security.
- b91ec0cd6: update the jsonb field update mode from `merge` to `replace` for the `PATCH /application/:id` endpoint.
remove the `deepPartial` statement from the `PATCH /application/:id` endpoint payload guard.
For all the jsonb typed fields in the application entity, the update mode is now `replace` instead of `merge`. This means that when you send a `PATCH` request to update an application, the jsonb fields will be replaced with the new values instead of merging them.
This change is to make the request behavior more strict aligned with the restful API principles for a `PATCH` request.
- d56bc2f73: add support for new password digest algorithm argon2d and argon2id
In `POST /users`, the `passwordAlgorithm` field now accepts `Argon2d` and `Argon2id`.
Users with those algorithms will be migrated to `Argon2i` upon succussful sign in.
- 510f681fa: use tsup for building
We've updated some of the packages to use `tsup` for building. This will make the build process faster, and should not affect the functionality of the packages.
Use minor version bump to catch your attention.
### Patch Changes
- 84f7e13a2: use native OpenAPI OAuth 2 security schema
The built-in OpenAPI OAuth 2 security schema is now used instead of the custom HTTP header-based security schema. This change improves compatibility with OpenAPI tools and libraries that support OAuth 2.
- f76252e0d: fix the status code 404 error in webhook events payload
Impact webhook events:
-`Role.Scopes.Updated`
-`Organizations.Membership.Updates`
Issue: These webhook event payloads were returning a API response status code of 404 when the webhook was triggered.
Expected: A status code of 200 should be returned, as we only trigger the webhook when the request is successful.
Fix: All webhook event contexts should be created and inserted into the webhook pipeline after the response body and status code are properly set.
- core: `GET /api/.well-known/sign-in-exp` now returns `googleOneTap` field with the configuration when available
- core: add Google Sign-In (GSI) url to the security headers
- core: verify Google One Tap CSRF token in `verifySocialIdentity()`
- phrases: add Google One Tap phrases
- schemas: migrate sign-in experience types from core to schemas
- 754d0e134: pagination is now optional for `GET /api/organizations/:id/users/:userId/roles`
The default pagination is now removed. This isn't considered a breaking change, but we marked it as minor to get your attention.
- 87615d58c: support machine-to-machine apps for organizations
This feature allows machine-to-machine apps to be associated with organizations, and be assigned with organization roles.
### Console
- Add a new "machine-to-machine" type to organization roles. All existing roles are now "user" type.
- You can manage machine-to-machine apps in the organization details page -> Machine-to-machine apps section.
- You can view the associated organizations in the machine-to-machine app details page.
### OpenID Connect grant
The `client_credentials` grant type is now supported for organizations. You can use this grant type to obtain an access token for an organization.
### Management API
A set of new endpoints are added to the Management API:
-`/api/organizations/{id}/applications` to manage machine-to-machine apps.
-`/api/organizations/{id}/applications/{applicationId}` to manage a specific machine-to-machine app in an organization.
-`/api/applications/{id}/organizations` to view the associated organizations of a machine-to-machine app.
- 061a30a87: support agree to terms polices for Logto’s sign-in experiences
- Automatic: Users automatically agree to terms by continuing to use the service
- ManualRegistrationOnly: Users must agree to terms by checking a box during registration, and don't need to agree when signing in
- Manual: Users must agree to terms by checking a box during registration or signing in
- ef21c7a99: support per-organization multi-factor authentication requirement
An organization can now require its member to have multi-factor authentication (MFA) configured. If an organization has this requirement and a member does not have MFA configured, the member will not be able to fetch the organization access token.
- b52609a1e: add `hasPassword` to custom JWT user context
- efa884c40: feature: just-in-time user provisioning for organizations
This feature allows users to automatically join the organization and be assigned roles upon their first sign-in through some authentication methods. You can set requirements to meet for just-in-time provisioning.
### Email domains
New users will automatically join organizations with just-in-time provisioning if they:
- Sign up with verified email addresses, or;
- Use social sign-in with verified email addresses.
This applies to organizations that have the same email domain configured.
To enable this feature, you can add email domain via the Management API or the Logto Console:
- We added the following new endpoints to the Management API:
- In the Logto Console, you can manage email domains in the organization details page -> "Just-in-time provisioning" section.
### SSO connectors
New or existing users signing in through enterprise SSO for the first time will automatically join organizations that have just-in-time provisioning configured for the SSO connector.
To enable this feature, you can add SSO connectors via the Management API or the Logto Console:
- We added the following new endpoints to the Management API:
- In the Logto Console, you can manage SSO connectors in the organization details page -> "Just-in-time provisioning" section.
### Default organization roles
You can also configure the default roles for users provisioned via this feature. The default roles will be assigned to the user when they are provisioned.
To enable this feature, you can set the default roles via the Management API or the Logto Console:
- We added the following new endpoints to the Management API:
- In the Logto Console, you can manage default roles in the organization details page -> "Just-in-time provisioning" section.
- b50ba0b7e: enable backchannel logout support
Enable the support of [OpenID Connect Back-Channel Logout 1.0](https://openid.net/specs/openid-connect-backchannel-1_0.html).
To register for backchannel logout, navigate to the application details page in the Logto Console and locate the "Backchannel logout" section. Enter the backchannel logout URL of your RP and click "Save".
You can also enable session requirements for backchannel logout. When enabled, Logto will include the `sid` claim in the logout token.
For programmatic registration, you can set the `backchannelLogoutUri` and `backchannelLogoutSessionRequired` properties in the application `oidcClientMetadata` object.
### Patch Changes
- d60f6ce48: build `operationId` for Management API in OpenAPI response (credit to @mostafa)
As per [the specification](https://swagger.io/docs/specification/paths-and-operations/):
> `operationId` is an optional unique string used to identify an operation. If provided, these IDs must be unique among all operations described in your API.
This greatly simplifies the creation of client SDKs in different languages, because it generates more meaningful function names instead of auto-generated ones, like the following examples:
- 7a279be1f: add user detail data payload to the `User.Deleted` webhook event
- d51e839cd: fix OpenAPI schema returned by the `GET /api/swagger.json` endpoint
1. The `:` character is invalid in parameter names, such as `organizationId:root`. These characters have been replaced with `-`.
2. The `tenantId` parameter of the `/api/.well-known/endpoints/{tenantId}` route was missing from the generated OpenAPI spec document, resulting in validation errors. This has been fixed.
- 0c70d65c7: define new `sso_identities` user claim to the userinfo endpoint response
- Define a new `sso_identities` user claim that will be used to store the user's SSO identities. The claim will be an array of objects with the following properties:
-`details`: detailed user info returned from the SSO provider.
-`issuer`: the issuer of the SSO provider.
-`identityId`: the user id of the user in the SSO provider.
- The new claims will share the same scope as the social `identities` claim.
- When the user `identities` scope is requested, the new `sso_identities` claim will be returned along with the `identities` claim in the userinfo endpoint response.
- For public organizations access EntraID OIDC applications, the token endpoint returns `expires_in` value type in number.
- For private organization access only applications, the token endpoint returns `expires_in` value type in string.
- Expected `expires_in` value type is number. (See [v2-oauth2-auth-code-flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow#successful-response-2) for reference)
String type `expires_in` value is not supported by the current Microsoft EntraID OIDC connector, a invalid authorization response error will be thrown.
Update the token response guard to handle both number and string type `expires_in` value. Make the SSO connector more robust.
- 8ef021fb3: add support for Redis Cluster and extra TLS options for Redis connections
- 21bb35b12: refactor the definition of hook event types
- Add `DataHook` event types. `DataHook` are triggered by data changes.
- Add "interaction" prefix to existing hook event types. Interaction hook events are triggered by end user interactions, e.g. completing sign-in.
- e8c41b164: support organization custom data
Now you can save additional data associated with the organization with the organization-level `customData` field by:
- Edit in the Console organization details page.
- Specify `customData` field when using organization Management APIs.
- 5872172cb: enable custom JWT feature for OSS version
OSS version users can now use custom JWT feature to add custom claims to JWT access tokens payload (previously, this feature was only available to Logto Cloud).
- 1ef32d6d5: update token grant to support organization API resources
Organization roles can be assigned with scopes (permissions) from the API resources, and the token grant now supports this.
Once the user is consent to an application with "resources" assigned, the token grant will now include the scopes inherited from all assigned organization roles.
Users can narrow down the scopes by passing `organization_id` when granting an access token, and the token will only include the scopes from the organization roles of the specified organization, the access token will contain an extra claim `organization_id` to indicate the organization the token is granted for. Then the resource server can use this claim to protect the resource with additional organization-level authorization.
This change is backward compatible, and the existing token grant will continue to work as before.
### Patch Changes
- 52df3ebbb: Bug fix: organization invitation APIs should handle invitee emails case insensitively
- 368385b93: Management API will not return 500 in production for status codes that are not listed in the OpenAPI spec
- d54530356: Fix OIDC AccessDenied error code to 403.
This error may happen when you try to grant an access token to a user lacking the required permissions, especially when granting for orgnization related resources. The error code should be 403 instead of 400.
- 5b03030de: Not allow to modify management API resource through API.
Previously, management API resource and its scopes are readonly in Console. But it was possible to modify through the API. This is not allowed anymore.
- 5660c54cb: Sign out user after deletion or suspension
When a user is deleted or suspended through Management API, they should be signed out immediately, including sessions and refresh tokens.
- a9ccfc738: implement request ID for API requests
- All requests will now include a request ID in the headers (`Logto-Core-Request-Id`)
- Terminal logs will now include the request ID as the prefix
- bbd399e15: fix the new user from SSO register hook event not triggering bug
### Issue
When a new user registers via SSO, the `PostRegister` interaction hook event is not triggered. `PostSignIn` event is mistakenly triggered instead.
### Root Cause
In the SSO `post /api/interaction/sso/:connectionId/registration` API, we update the interaction event to `Register`.
However, the hook middleware reads the event from interaction session ahead of the API logic, and the event is not updated resulting in the wrong event being triggered.
In the current interaction API design, we should mutate the interaction event by calling the `PUT /api/interaction/event` API, instead of updating the event directly in the submit interaction APIs. (Just like the no direct mutation rule for a react state). So we can ensure the correct side effect like logs and hooks are triggered properly.
All the other sign-in methods are using the `PUT /api/interaction/event` API to update the event. But when implementing the SSO registration API, we were trying to reduce the API requests and directly updated the event in the registration API which will submit the interaction directly.
### Solution
Remove the event update logic in the SSO registration API and call the `PUT /api/interaction/event` API to update the event.
This will ensure the correct event is triggered in the hook middleware.
### Action Items
Align the current interaction API design for now.
Need to improve the session/interaction API logic to simplify the whole process.
- b4b8015db: fix a bug that prevents invitee from accepting the organization invitation if the email letter case is not matching
- b575f57ac: Support comma separated resource parameter
Some third-party libraries or plugins do not support array of resources, and can only specify `resource` through `additionalParameters` config, e.g. `flutter-appauth`. However, only one resource can be specified at a time in this way. This PR enables comma separated resource parameter support in Logto core service, so that multiple resources can be specified via a single string.
For example: Auth URL like `/oidc/auth?resource=https://example.com/api1,https://example.com/api2` will be interpreted and parsed to Logto core service as `/ordc/auth?resource=https://example.com/api1&resource=https://example.com/api2`.
- aacbebcbc: Provide management API to fetch user organization scopes based on user organization roles
- GET `organizations/:id/users/:userId/scopes`
- 3486b12e8: Fix file upload API.
The `koa-body` has been upgraded to the latest version, which caused the file upload API to break. This change fixes the issue.
The `ctx.request.files.file` in the new version is an array, so the code has been updated to pick the first one.
- ead2abde6: fix a bug that API resource indicator does not work if the indicator is not followed by a trailing slash or a pathname
- Bump `oidc-provider@8.4.6` to fix the above issue
- 172411946: Add avatar and customData fields to create user API (POST /api/users)
- abffb9f95: full oidc standard claims support
We have added support for the remaining [OpenID Connect standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). 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.
- 2cbc591ff: support `first_screen` parameter in authentication request
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.
The `first_screen` parameter can have the following values:
-`signIn`: The sign-in screen is displayed first.
-`register`: The registration screen is displayed first.
Here's a non-normative example of how to use the `first_screen` parameter:
When `first_screen` is set, the legacy `interaction_mode` parameter is ignored.
- 468558721: Get organization roles with search keyword.
- cc01acbd0: Create a new user through API with password digest and corresponding algorithm
- 2cbc591ff: support direct sign-in
Instead of showing a screen for the user to choose between the sign-in methods, a specific sign-in method can be initiated directly by setting the `direct_sign_in` parameter in the OIDC authentication request.
This parameter follows the format of `direct_sign_in=<method>:<target>`, where:
-`<method>` is the sign-in method to trigger. Currently the only supported value is `social`.
-`<target>` is the target value for the sign-in method. If the method is `social`, the value is the social connector's `target`.
When a valid `direct_sign_in` parameter is set, the first screen will be skipped and the specified sign-in method will be triggered immediately upon entering the sign-in experience. If the parameter is invalid, the default behavior of showing the first screen will be used.
### Patch Changes
- 7c22c50cb: Fix SSO connector new user authentication internal server error.
## Description
Thanks to the [issue](https://github.com/logto-io/logto/issues/5502) report, we found that the SSO connector new user authentication was causing an internal server error. Should return an 422 status code instead of 500. Frontend sign-in page can not handle the 500 error and complete the new user registration process.
### Root cause
When the SSO connector returns a new user that does not exist in the Logto database, the backend with throw a 422 error. Frontend relies the 422 error to redirect and complete the new user registration process.
However, the backend was throwing a 500 error instead. That is because we applied a strict API response status code guard at the koaGuard middleware level. The status code 422 was not listed. Therefore, the middleware threw a 500 error.
### Solution
We added the 422 status code to the koaGuard middleware. Now, the backend will return a 422 status code when the SSO connector returns a new user that does not exist in the Logto database. The frontend sign-in page can handle the 422 error and complete the new user registration process.
- 532454b92: support form post callback for social connectors
Add the `POST /callback/:connectorId` endpoint to handle the form post callback for social connectors. This usefull for the connectors that require a form post callback to complete the authentication process, such as Apple.
- 32df9acde: implement Logto core API to support the new third-party application feature, and user consent interaction flow
### Management API
- Add new endpoint `/applications/sign-in-experiences` with `PUT`, `GET` methods to manage the application level sign-in experiences.
- Add new endpoint `/applications/:id/users/:userId/consent-organizations` with `PUT`, `GET`, `POST`, `DELETE` methods to manage the user granted organizations for the third-party application.
- Add new endpoint `/applications/:id/user-consent-scopes` with `GET`, `POST`, `DELETE` methods to manage the user consent resource, organization, and user scopes for the third-party application.
- Update the `/applications` endpoint to include the new `is_third_party` field. Support create third-party applications, and query by `is_third_party` field.
### Interaction API
- Add the `koaAutoConsent` to support the auto-consent interaction flow for the first-party application. If is the first-party application we can auto-consent the requested scopes. If is the third-party application we need to redirect the user to the consent page to get the user consent manually.
- Add the `GET /interaction/consent` endpoint to support fetching the consent context for the user consent page. Including the application detail, authenticated user info, all the requested scopes and user organizations info (if requested scopes include the organization scope).
- Update the `POST /interaction/consent` endpoint to support the user consent interaction flow. Including grant all the missing scopes, and update the user granted organizations for the third-party application.
- 31e60811d: use Node 20 LTS for engine requirement.
Note: We mark it as minor because Logto is shipping with Docker image and it's not a breaking change for users.
### Patch Changes
- 9222eb9f8: Set `on conflict do nothing` for all the `RelationQueries` insert operation.
- For all the relation table entities, we want to safely insert them into the database. If the relation entity already exists, instead of throwing an error, we ignore the insert operation, especially on a batch insert. Unlike other resource data entities, user does not care if the relation entity already exists. Therefore, we want to silently ignore the insert operation if the relation entity already exists.
- acb7fd3fe: Add case sensitive username env variable
- 9a7b19e49: Support single sign-on (SSO) on Logto.
- Implement new SSO connector management APIs.
-`GET /api/sso-connector-providers` - List all the supported SSO connector providers.
-`POST /api/sso-connectors` - Create new SSO connector.
-`GET /api/sso-connectors` - List all the SSO connectors.
-`GET /api/sso-connectors/:id` - Get SSO connector by id.
-`PATCH /api/sso-connectors/:id` - Update SSO connector by id.
-`DELETE /api/sso-connectors/:id` - Delete SSO connector by id.
- Implement new SSO interaction APIs to enable the SSO connector sign-in methods
-`POST /api/interaction/single-sign-on/:connectorId/authorization-url` - Init a new SSO connector sign-in interaction flow by retrieving the IdP's authorization URL.
-`POST /api/interaction/single-sign-on/:connectorId/authentication` - Handle the SSO connector sign-in interaction flow by retrieving the IdP's authentication data.
-`POST /api/interaction/single-sign-on/:connectorId/registration` - Create new user account by using the SSO IdP's authentication result.
-`GET /api/interaction/single-sign-on/connectors` - List all the enabled SSO connectors by a given email address.
- Implement new SSO connector factory to support different SSO connector providers.
-`OIDC` - Standard OIDC connector that can be used to connect with any OIDC compatible IdP.
-`SAML` - Standard SAML 2.0 connector that can be used to connect with any SAML 2.0 compatible IdP.
-`AzureAD` - Azure Active Directory connector that can be used to connect with Azure AD.
-`Okta` - Okta connector that can be used to connect with Okta.
-`Google Workspace` - Google Workspace connector that can be used to connect with Google Workspace.
- becf59169: introduce Logto Organizations
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.
See [🏢 Organizations (Multi-tenancy)](https://docs.logto.io/docs/recipes/organizations/) for more details.
### Patch Changes
- b05fb2960: add summary and description to APIs
- 9a4da065d: fix incorrect swagger components
- b4f702a86: userinfo endpoint will return `organization_data` claim if organization scope is requested
The claim includes all organizations that the user is a member of with the following structure:
```json
{
"organization_data": [
{
"id": "organization_id",
"name": "organization_name",
"description": "organization_description"
}
]
}
```
- 3e92a2032: refactor: add user ip to webhook event payload
We're excited to announce that Logto now supports multi-factor authentication (MFA) for your sign-in experience. Navigate to the "Multi-factor auth" tab to configure how you want to secure your users' accounts.
In this release, we introduce the following MFA 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.
### Patch Changes
- bbe7f0b8e: refactored swagger json api
- reuse parameter definitions, which reduces the size of the swagger response.
- tags are now in sentence case.
- path parameters now follow the swagger convention, using `{foo}` instead of `:foo`.
- 46d0d4c0b: convert private signing key type from string to JSON object, in order to provide additional information such as key ID and creation timestamp.
- 1ab39d19b: fix 500 error when using search component in console to filter both roles and applications.
This feature enables custom password policy for users. Now it is possible to guard with the following rules when a user is creating a new password:
- Minimum length (default: `8`)
- Minimum character types (default: `1`)
- If the password has been pwned (default: `true`)
- If the password is exactly the same as or made up of the restricted phrases:
- Repetitive or sequential characters (default: `true`)
- User information (default: `true`)
- Custom words (default: `[]`)
If you are an existing Logto Cloud user or upgrading from a previous version, to ensure a smooth experience, we'll keep the original policy as much as possible:
> The original password policy requires a minimum length of 8 and at least 2 character types (letters, numbers, and symbols).
Note in the new policy implementation, it is not possible to combine lower and upper case letters into one character type. So the original password policy will be translated into the following:
- schemas: add `name`, `events`, `signingKey`, and `enabled` fields to the `hook` schema
- core: change the `user-agent` value from `Logto (https://logto.io)` to `Logto (https://logto.io/)` in the webhook request headers
- core: deprecate `event` field in all hook-related APIs, use `events` instead
- core: deprecate `retries` field in the `HookConfig` for all hook-related APIs, now it will fallback to `3` if not specified and will be removed in the future
- core: add new APIs for webhook management
-`GET /api/hooks/:id/recent-logs` to retrieve recent execution logs(24h) of a webhook
-`POST /api/hooks/:id/test` to test a webhook
-`PATCH /api/hooks/:id/signing-key` to regenerate the signing key of a webhook
- core: support query webhook execution stats(24h) via `GET /api/hooks/:id` and `GET /api/hooks/:id` by specifying `includeExecutionStats` query parameter
- console: support webhook management
- 268dc50e7: Support setting default API Resource from Console and API
- New API Resources will not be treated as default.
- Added `PATCH /resources/:id/is-default` to setting `isDefault` for an API Resource.
- Only one default API Resource is allowed per tenant. Setting one API default will reset all others.
This change removes the report only flag from CSP security header settings, which will enables the strict CSP policy check for all requests.
- 3d9885233: ## Bump oidc-provider version
Bump oidc-provider version to [v8.2.2](https://github.com/panva/node-oidc-provider/releases/tag/v8.2.2). This version fixes a bug that prevented the revoked scopes from being removed from the access token.
> Issued Access Tokens always only contain scopes that are defined on the respective Resource Server (returned from features.resourceIndicators.getResourceServerInfo).
If the scopes are revoked from the resource server, they should be removed from the newly granted access token. This is now fixed in the new version of oidc-provider.
- 813e21639: Bug fix: reset password webhook should be triggered when the user resets password
- 1548e0732: implement a central cache store to cache well-known with Redis implementation
### Patch Changes
- 7af8e9c9b: Add new management API `/users/:userId/password/verify` to help verify user password, which would be helpful when building custom profile or sign-in pages
- 6b1948592: Provide management API to detect if a user has set the password.
- 4945b0be2: Apply security headers
Apply security headers to logto http request response using (helmetjs)[https://helmetjs.github.io/].
Logto was using a single port to serve both normal users and admins, as well as the web console. While we continuously maintain a high level of security, it’ll still be great to decouple these components into two separate parts to keep data isolated and provide a flexible infrastructure.
From this version, Logto now listens to two ports by default, one for normal users (`3001`), and one for admins (`3002`).
- Nothing changed for normal users. No adaption is needed.
- For admin users:
- The default Admin Console URL has been changed to `http://localhost:3002/console`.
- To change the admin port, set the environment variable `ADMIN_PORT`. For instance, `ADMIN_PORT=3456`.
- You can specify a custom endpoint for admins by setting the environment variable `ADMIN_ENDPOINT`. For example, `ADMIN_ENDPOINT=https://admin.your-domain.com`.
- You can now completely disable admin endpoints by setting `ADMIN_DISABLE_LOCALHOST=1` and leaving `ADMIN_ENDPOINT` unset.
- Admin Console and admin user data are not accessible via normal user endpoints, including `localhost` and `ENDPOINT` from the environment.
- Admin Console no longer displays audit logs of admin users. However, these logs still exist in the database, and Logto still inserts admin user logs. There is just no convenient interface to inspect them.
- Due to the data isolation, the numbers on the dashboard may slightly decrease (admins are excluded).
If you are upgrading from a previous version, simply run the database alteration command as usual, and we'll take care of the rest.
> **Note** DID YOU KNOW
>
> Under the hood, we use the powerful Postgres feature Row-Level Security to isolate admin and user data.
- 1c9160112: Packages are now ESM.
- 343b1090f: **💥 BREAKING CHANGE 💥** Move `/api/phrase` API to `/api/.well-known/phrases`
- f41fd3f05: drop settings table and add systems table
**BREAKING CHANGES**
- core: removed `GET /settings` and `PATCH /settings` API
- core: added `GET /configs/admin-console` and `PATCH /configs/admin-console` API
-`/configs/*` APIs are config/key-specific now. they may have different logic per key
- cli: change valid `logto db config` keys by removing `alterationState` and adding `adminConsole` since:
- OIDC configs and admin console configs are tenant-level configs (the concept of "tenant" can be ignored until we officially announce it)
- alteration state is still a system-wide config
### Minor Changes
- c12717412: - mask sensitive password value in audit logs
- f41fd3f05: Replace `passcode` naming convention in the interaction APIs and main flow ui with `verificationCode`.
- c12717412: ## Creating your social connector with ease
We’re excited to announce that Logto now supports standard protocols (SAML, OIDC, and OAuth2.0) for creating social connectors to integrate external identity providers. Each protocol can create multiple social connectors, giving you more control over your access needs.
To simplify the process of configuring social connectors, we’re replacing code-edit with simple forms. SAML already supports form configuration, with other connectors coming soon. This means you don’t need to compare documents or worry about code format.
- c12717412: ## Enable connector method `getUserInfo` read and write access to DB
Logto connectors are designed to be stateless to the extent possible and practical, but it still has some exceptions at times.
With the recent addition of database read and write access, connectors can now store persistent information. For example, connectors can now store access tokens and refresh tokens to minimize number of requests to social vendor's APIs.
- 343b1090f: - Automatically create a new tenant for new cloud users
- Support path-based multi-tenancy
- 343b1090f: Add storage provider: S3Storage
- 343b1090f: Allow admin tenant admin to create tenants without limitation
- 343b1090f: ### Add privacy policy url
In addition to the terms of service url, we also provide a privacy policy url field in the sign-in-experience settings. To better support the end-users' privacy declaration needs.
- 18e3b82e6: Add user suspend API endpoint
Use `PATCH /api/users/:userId/is-suspended` to update a user's suspended state, once a user is suspended, all refresh tokens belong to this user will be revoked.
Suspended users will get an error toast when trying to sign in.
- 343b1090f: Add API for uploading user images to storage providers: Azure Storage.
- f41fd3f05: Officially cleanup all deprecated `/session` APIs in core and all the related integration tests.
- User can use this optional config to designate the URL to redirect if session not found in Sign-in Experience.
- Session guard now works for root path as well.
- 343b1090f: New feature: User account settings page
- We have removed the previous settings page and moved it to the account settings page. You can access to the new settings menu by clicking the user avatar in the top right corner.
- You can directly change the language or theme from the popover menu, and explore more account settings by clicking the "Profile" menu item.
- You can update your avatar, name and username in the profile page, and also changing your password.
- [Cloud] Cloud users can also link their email address and social accounts (Google and GitHub at first launch).
- 343b1090f: remove the branding style config and make the logo URL config optional
- c12717412: **Customize CSS for Sign-in Experience**
We have put a lot of effort into improving the user sign-in experience and have provided a brand color option for the UI. However, we know that fine-tuning UI requirements can be unpredictable. While Logto is still exploring the best options for customization, we want to provide a programmatic method to unblock your development.
You can now use the Management API `PATCH /api/sign-in-exp` with body `{ "customCss": "arbitrary string" }` to set customized CSS for the sign-in experience. You should see the value of `customCss` attached after `<title>` of the page. If the style has a higher priority, it should be able to override.
> **Note**
>
> Since Logto uses CSS Modules, you may see a hash value in the `class` property of DOM elements (e.g. a `<div>` with `vUugRG_container`). To override these, you can use the `$=` CSS selector to match elements that end with a specified value. In this case, it should be `div[class$=container]`.
- 2168936b9: **Sign-in Experience v2**
We are thrilled to announce the release of the newest version of the Sign-in Experience, which includes more ways to sign-in and sign-up, as well as a framework that is easier to understand and more flexible to configure in the Admin Console.
When compared to Sign-in Experience v1, this version’s capability was expanded so that it could support a greater variety of flexible use cases. For example, now users can sign up with email verification code and sign in with email and password.
We hope that this will be able to assist developers in delivering a successful sign-in flow, which will also be appreciated by the end users.
- 1c9160112: ### Features
- Enhanced user search params #2639
- Web hooks
### Improvements
- Refactored Interaction APIs and Audit logs
- f41fd3f05: - cli: use `ec` with `secp384r1` as the default key generation type
- core: use `ES384` as the signing algorithm for EC keys
- 343b1090f: ### Add custom content sign-in-experience settings to allow insert custom static html content to the logto sign-in pages
- feat: combine with the custom css, give the user the ability to further customize the sign-in pages
- fdb2bb48e: **Streamlining the social sign-up flow**
- detect trusted email (or phone number) from the social account
- email (or phone number) has been registered: automatically connecting the social identity to the existing user account with a single click
- email (or phone number) not registered: automatically sync up the user profile with the social provided email (or phone) if and only if marked as a required user profile.
- f41fd3f05: Replace the `sms` naming convention using `phone` cross logto codebase. Including Sign-in Experience types, API paths, API payload and internal variable names.
- 402866994: **💥 Breaking change 💥**
Use case-insensitive strategy for searching emails
- f41fd3f05: Add support to send and verify verification code in management APIs
### Patch Changes
- e63f5f8b0: Bump connector kit version to fix "Continue" issues on sending email/sms.
- 51f527b0c: bug fixes
- core: fix 500 error when enabling app admin access in console
- ui: handle required profile errors on social binding flow
- 343b1090f: ## Refactor the Admin Console 403 flow
- Add 403 error handler for all AC API requests
- Show confirm modal to notify the user who is not authorized
- Click `confirm` button to sign out and redirect user to the sign-in page
- 343b1090f: Add interactionMode extra OIDC params to specify the desired use interaction experience
- signUp: Deliver a sign-up first interaction experience
- signIn & undefined: Deliver a default sign-in first interaction experience
- 38970fb88: Fix a Sign-in experience bug that may block some users to sign in.
- 343b1090f: **Seed data for cloud**
- cli!: remove `oidc` option for `database seed` command as it's unused
- cli: add hidden `--cloud` option for `database seed` command to init cloud data
- cli, cloud: appending Redirect URIs to Admin Console will deduplicate values before update
- move `UrlSet` and `GlobalValues` to `@logto/shared`
- 5e1466f40: Allow localhost CORS when only one endpoint available
Logto was using a single port to serve both normal users and admins, as well as the web console. While we continuously maintain a high level of security, it’ll still be great to decouple these components into two separate parts to keep data isolated and provide a flexible infrastructure.
From this version, Logto now listens to two ports by default, one for normal users (`3001`), and one for admins (`3002`).
- Nothing changed for normal users. No adaption is needed.
- For admin users:
- The default Admin Console URL has been changed to `http://localhost:3002/console`.
- To change the admin port, set the environment variable `ADMIN_PORT`. For instance, `ADMIN_PORT=3456`.
- You can specify a custom endpoint for admins by setting the environment variable `ADMIN_ENDPOINT`. For example, `ADMIN_ENDPOINT=https://admin.your-domain.com`.
- You can now completely disable admin endpoints by setting `ADMIN_DISABLE_LOCALHOST=1` and leaving `ADMIN_ENDPOINT` unset.
- Admin Console and admin user data are not accessible via normal user endpoints, including `localhost` and `ENDPOINT` from the environment.
- Admin Console no longer displays audit logs of admin users. However, these logs still exist in the database, and Logto still inserts admin user logs. There is just no convenient interface to inspect them.
- Due to the data isolation, the numbers on the dashboard may slightly decrease (admins are excluded).
If you are upgrading from a previous version, simply run the database alteration command as usual, and we'll take care of the rest.
> **Note** DID YOU KNOW
>
> Under the hood, we use the powerful Postgres feature Row-Level Security to isolate admin and user data.
### Minor Changes
- c12717412: - mask sensitive password value in audit logs
- c12717412: ## Creating your social connector with ease
We’re excited to announce that Logto now supports standard protocols (SAML, OIDC, and OAuth2.0) for creating social connectors to integrate external identity providers. Each protocol can create multiple social connectors, giving you more control over your access needs.
To simplify the process of configuring social connectors, we’re replacing code-edit with simple forms. SAML already supports form configuration, with other connectors coming soon. This means you don’t need to compare documents or worry about code format.
- c12717412: ## Enable connector method `getUserInfo` read and write access to DB
Logto connectors are designed to be stateless to the extent possible and practical, but it still has some exceptions at times.
With the recent addition of database read and write access, connectors can now store persistent information. For example, connectors can now store access tokens and refresh tokens to minimize number of requests to social vendor's APIs.
- c12717412: **Customize CSS for Sign-in Experience**
We have put a lot of effort into improving the user sign-in experience and have provided a brand color option for the UI. However, we know that fine-tuning UI requirements can be unpredictable. While Logto is still exploring the best options for customization, we want to provide a programmatic method to unblock your development.
You can now use the Management API `PATCH /api/sign-in-exp` with body `{ "customCss": "arbitrary string" }` to set customized CSS for the sign-in experience. You should see the value of `customCss` attached after `<title>` of the page. If the style has a higher priority, it should be able to override.
> **Note**
>
> Since Logto uses CSS Modules, you may see a hash value in the `class` property of DOM elements (e.g. a `<div>` with `vUugRG_container`). To override these, you can use the `$=` CSS selector to match elements that end with a specified value. In this case, it should be `div[class$=container]`.
- f41fd3f0: drop settings table and add systems table
**BREAKING CHANGES**
- core: removed `GET /settings` and `PATCH /settings` API
- core: added `GET /configs/admin-console` and `PATCH /configs/admin-console` API
-`/configs/*` APIs are config/key-specific now. they may have different logic per key
- cli: change valid `logto db config` keys by removing `alterationState` and adding `adminConsole` since:
- OIDC configs and admin console configs are tenant-level configs (the concept of "tenant" can be ignored until we officially announce it)
- alteration state is still a system-wide config
### Minor Changes
- f41fd3f0: Replace `passcode` naming convention in the interaction APIs and main flow ui with `verificationCode`.
- f41fd3f0: Officially cleanup all deprecated `/session` APIs in core and all the related integration tests.
- f41fd3f0: - cli: use `ec` with `secp384r1` as the default key generation type
- core: use `ES384` as the signing algorithm for EC keys
- fdb2bb48: **Streamlining the social sign-up flow**
- detect trusted email (or phone number) from the social account
- email (or phone number) has been registered: automatically connecting the social identity to the existing user account with a single click
- email (or phone number) not registered: automatically sync up the user profile with the social provided email (or phone) if and only if marked as a required user profile.
- f41fd3f0: Replace the `sms` naming convention using `phone` cross logto codebase. Including Sign-in Experience types, API paths, API payload and internal variable names.
- f41fd3f0: Add support to send and verify verification code in management APIs
Use `PATCH /api/users/:userId/is-suspended` to update a user's suspended state, once a user is suspended, all refresh tokens belong to this user will be revoked.
We are thrilled to announce the release of the newest version of the Sign-in Experience, which includes more ways to sign-in and sign-up, as well as a framework that is easier to understand and more flexible to configure in the Admin Console.
When compared to Sign-in Experience v1, this version’s capability was expanded so that it could support a greater variety of flexible use cases. For example, now users can sign up with email verification code and sign in with email and password.
- **core:** add GET /custom-phrases route ([#1935](https://github.com/logto-io/logto/issues/1935)) ([5fe0cf4](https://github.com/logto-io/logto/commit/5fe0cf4257a72f96fc439132c7b5b58e07352aa3))
- **core:** add POST /session/forgot-password/{email,sms}/send-passcode ([#1963](https://github.com/logto-io/logto/issues/1963)) ([af2600d](https://github.com/logto-io/logto/commit/af2600d828bf315ce57de5813168571e7042d8de))
- **core:** add POST /session/forgot-password/{email,sms}/verify-passcode ([#1968](https://github.com/logto-io/logto/issues/1968)) ([1ea39f3](https://github.com/logto-io/logto/commit/1ea39f346367d9f300be7281a65e689bf198a65c))
- **core:** add POST /session/forgot-password/reset ([#1972](https://github.com/logto-io/logto/issues/1972)) ([acdc86c](https://github.com/logto-io/logto/commit/acdc86c8560d30a89eccb6b0f6892221ea1bc5e0))
- **core:** add PUT /custom-phrases/:languageKey route ([#1907](https://github.com/logto-io/logto/issues/1907)) ([0ae13f0](https://github.com/logto-io/logto/commit/0ae13f091b69c717cc17ed4f400f456f1737fc5c))
- **core:** add ts to interaction result ([#1917](https://github.com/logto-io/logto/issues/1917)) ([e01042c](https://github.com/logto-io/logto/commit/e01042cbcd77c486afa1ee9fc2fa5c1d2df92542))
- **core:** cannot delete custom phrase used as default language in sign-in exp ([#1951](https://github.com/logto-io/logto/issues/1951)) ([a1aef26](https://github.com/logto-io/logto/commit/a1aef26905f624569ee47e43bb3a9c9cf05b997b))
- **core:** check migration state before app start ([#1979](https://github.com/logto-io/logto/issues/1979)) ([bf1d281](https://github.com/logto-io/logto/commit/bf1d281905bcf91a09dd8330212b6db838d65344))
- **core:** deploy migration in transaction mode ([#1980](https://github.com/logto-io/logto/issues/1980)) ([9a89c1a](https://github.com/logto-io/logto/commit/9a89c1a200322c678e2b0246ed324c847e734fc6))
- **core:** machine to machine apps ([cd9c697](https://github.com/logto-io/logto/commit/cd9c6978a35d9fc3a571c7bd56c972939c49a9b5))
- **core:** save empty string as null value in DB ([#1901](https://github.com/logto-io/logto/issues/1901)) ([ecdf06e](https://github.com/logto-io/logto/commit/ecdf06ef39a177b207dc75930e96dfcf2ae12cdc))
- **core:** support base64 format `OIDC_PRIVATE_KEYS` config in `.env` file ([#1903](https://github.com/logto-io/logto/issues/1903)) ([5bdb675](https://github.com/logto-io/logto/commit/5bdb6755d2e1bf5b6a004859561d60f1103aec69))
- **core:** update migration state after db init ([f904b88](https://github.com/logto-io/logto/commit/f904b88f564110c1ed00b2fa1c7b3c1e168fc106))
- bump react sdk and essentials toolkit to support CJK characters in idToken ([2f92b43](https://github.com/logto-io/logto/commit/2f92b438644bd330fa4b8cd3698d9129ecbae282))
- **core,schemas:** move alteration types into schemas src ([#2005](https://github.com/logto-io/logto/issues/2005)) ([10c1be6](https://github.com/logto-io/logto/commit/10c1be6eb76e1cb94746aee632a421aea8d4c211))
- **core:** filter out connector-kit ([#1987](https://github.com/logto-io/logto/issues/1987)) ([f4cf89f](https://github.com/logto-io/logto/commit/f4cf89fb8deee7472d8e9bdbcb7ae7364ced1f74))
- support capital letter "Y" in command line prompt ([416f4e8](https://github.com/logto-io/logto/commit/416f4e86e390318dbb0bdb262139ca4ec72ce5fe))
- fetch connectors list from npm ([#1894](https://github.com/logto-io/logto/issues/1894)) ([c6764f9](https://github.com/logto-io/logto/commit/c6764f95f78ce30148e5439cd08ff87b1608b9b5))
- **core:** set user default roles from env ([#1793](https://github.com/logto-io/logto/issues/1793)) ([4afdf3c](https://github.com/logto-io/logto/commit/4afdf3cb4c868cc85ba1d6b155165515a431d771))
- **core:** support signing key rotation ([#1732](https://github.com/logto-io/logto/issues/1732)) ([00bab4c](https://github.com/logto-io/logto/commit/00bab4c09582797c31d9bc5c7fe6d3c4b44a2f36))
- **core:** use comma separated values as a string array in the env file ([#1762](https://github.com/logto-io/logto/issues/1762)) ([f6db981](https://github.com/logto-io/logto/commit/f6db981600fd16a860262336ad88d886ca502628))
- **core:** api GET /me ([#1650](https://github.com/logto-io/logto/issues/1650)) ([4bf6483](https://github.com/logto-io/logto/commit/4bf6483ff4674052d4b5d00d647c0c408b3ecc7f))
- **core:** support integration test env config ([#1619](https://github.com/logto-io/logto/issues/1619)) ([708523e](https://github.com/logto-io/logto/commit/708523ed5287683cc23c6a93e01fe55dbd838e8c))
- **connector:** fix connector getConfig and validateConfig type ([#1530](https://github.com/logto-io/logto/issues/1530)) ([88a54aa](https://github.com/logto-io/logto/commit/88a54aaa9ebce419c149a33150a4927296cb705b))
- **connector:** passwordless connector send test msg with unsaved config ([#1539](https://github.com/logto-io/logto/issues/1539)) ([0297f6c](https://github.com/logto-io/logto/commit/0297f6c52f7b5d730de44fbb08f88c2e9b951874))
- **connector:** refactor ConnectorInstance as class ([#1541](https://github.com/logto-io/logto/issues/1541)) ([6b9ad58](https://github.com/logto-io/logto/commit/6b9ad580ae86fbcc100a100aab1d834090e682a3))
- **core:** do not titlize tags of .well-known APIs ([#1412](https://github.com/logto-io/logto/issues/1412)) ([5559fb1](https://github.com/logto-io/logto/commit/5559fb10c33932300d9f863cb3f57c48c504acdc))
- **connector:** apple ([#966](https://github.com/logto-io/logto/issues/966)) ([7400ed8](https://github.com/logto-io/logto/commit/7400ed8896fdceda6165a0540413efb4e3a47438))
- **connectors:** handle authorization callback parameters in each connector respectively ([#1166](https://github.com/logto-io/logto/issues/1166)) ([097aade](https://github.com/logto-io/logto/commit/097aade2e2e1b1ea1531bcb4c1cca8d24961a9b9))
- **console,core:** hide admin user ([#1182](https://github.com/logto-io/logto/issues/1182)) ([9194a6e](https://github.com/logto-io/logto/commit/9194a6ee547e2eb83ec106a834409c33644481e5))
- **console:** add column lastSignIn in user management ([#679](https://github.com/logto-io/logto/issues/679)) ([a0b4b98](https://github.com/logto-io/logto/commit/a0b4b98c35ff08c2df0863e4bc2110386fc54aee))
- **console:** dark logo ([#860](https://github.com/logto-io/logto/issues/860)) ([664a218](https://github.com/logto-io/logto/commit/664a2180a51b577fb517661cf0d7efb1374f3858))
- **console:** sie form reorg ([#1218](https://github.com/logto-io/logto/issues/1218)) ([2c41334](https://github.com/logto-io/logto/commit/2c413341d1c515049faa130416f7a5e591d10e8a))
- **console:** support persisting get-started progress in settings config ([43b2309](https://github.com/logto-io/logto/commit/43b2309c994b2eb8b1b8f1c12893eb66b5ce1d95))
- **core,connectors:** update Aliyun logo and add logo_dark to Apple, Github ([#1194](https://github.com/logto-io/logto/issues/1194)) ([98f8083](https://github.com/logto-io/logto/commit/98f808320b1c79c51f8bd6f49e35ca44363ea560))
- **core,console:** change admin user password ([#1268](https://github.com/logto-io/logto/issues/1268)) ([a4d0a94](https://github.com/logto-io/logto/commit/a4d0a940bdabb213866407afb6c064b6740ce593))
- **core,schemas:** log IP and user agent ([#682](https://github.com/logto-io/logto/issues/682)) ([0ecb7e4](https://github.com/logto-io/logto/commit/0ecb7e4d2fe869ada46cc39e0fef98d2240cb1b2))
- **core,schemas:** save application id that the user first consented ([#688](https://github.com/logto-io/logto/issues/688)) ([4521c3c](https://github.com/logto-io/logto/commit/4521c3c8d17becb6b322fc0128fff992f34d2a0d))
- **core,shared:** get /dashboard/users/active ([#953](https://github.com/logto-io/logto/issues/953)) ([1420bb2](https://github.com/logto-io/logto/commit/1420bb28cec9c0e20b4d0645a58e436135f87c83))
- **core:** add admin role validation to the koaAuth ([#920](https://github.com/logto-io/logto/issues/920)) ([cf360b9](https://github.com/logto-io/logto/commit/cf360b9c15594b0923c79adf3a401e29d84fad23))
- **core:** add custom claims to id token ([#911](https://github.com/logto-io/logto/issues/911)) ([9ccda93](https://github.com/logto-io/logto/commit/9ccda932a45816be2089d3e58c8e91f55b9ecce9))
- **core:** add etag for settings api ([#1011](https://github.com/logto-io/logto/issues/1011)) ([d4f38bc](https://github.com/logto-io/logto/commit/d4f38bce2b016ddd4e6d5f260e04c7e0f4f312f7))
- **core:** add phone number and email mask ([#891](https://github.com/logto-io/logto/issues/891)) ([67f080e](https://github.com/logto-io/logto/commit/67f080e8623de0417436f9897f1179e6cdc62130))
- **core:** add role table seed ([#1145](https://github.com/logto-io/logto/issues/1145)) ([837ad52](https://github.com/logto-io/logto/commit/837ad523cef4a41ab9fdddfe7a92b6ed074114a0))
- **core:** add socialConnectors details for get sign-in-settings ([#804](https://github.com/logto-io/logto/issues/804)) ([7a922cb](https://github.com/logto-io/logto/commit/7a922cbd331b45443f7f19a8af3dcd9156453079))
- **core:** add switch of enabling object fully replace when updating DB ([#1107](https://github.com/logto-io/logto/issues/1107)) ([efa9491](https://github.com/logto-io/logto/commit/efa9491749f6702ba0d15ab50818e8a9622fdd90))
- **core:** any-type parameter shows empty object in swagger example ([#1110](https://github.com/logto-io/logto/issues/1110)) ([7339a85](https://github.com/logto-io/logto/commit/7339a85a1bb4f1a8c69a05fb5bfd61f154b24eb7))
- **core:** append page and page_size to the query parameters in swagger.json ([#1120](https://github.com/logto-io/logto/issues/1120)) ([a262999](https://github.com/logto-io/logto/commit/a26299941f71fd6cae51380c05a9e49f4fae2084))
- **core:** convert route guards to swagger.json ([#1047](https://github.com/logto-io/logto/issues/1047)) ([3145c9b](https://github.com/logto-io/logto/commit/3145c9b34824e9107a98625dc2998f605a936ae8))
- **core:** convert Zod union, literal and string guards to OpenAPI schemas ([#1126](https://github.com/logto-io/logto/issues/1126)) ([511012d](https://github.com/logto-io/logto/commit/511012da92bf1cae9e8429b343f4554b8c4230f0))
- **core:** empty path sould redirect to the console page ([#915](https://github.com/logto-io/logto/issues/915)) ([207c404](https://github.com/logto-io/logto/commit/207c404aebd062f2f46742748ed08c5d97368dbc))
- **core:** expose connector and metadata from sendPasscode ([#806](https://github.com/logto-io/logto/issues/806)) ([0ea5513](https://github.com/logto-io/logto/commit/0ea55134a92252a00f6b3532cdde71ae96979452))
- **core:** get /dashboard/users/new ([#940](https://github.com/logto-io/logto/issues/940)) ([45a9777](https://github.com/logto-io/logto/commit/45a977790eca01b212f51047d5636ff882873dd8))
- **core:** get /dashboard/users/total ([#936](https://github.com/logto-io/logto/issues/936)) ([c4bb0de](https://github.com/logto-io/logto/commit/c4bb0de7d426055b3634d8e4dace5cface7f2f0f))
- **core:** get /logs ([#823](https://github.com/logto-io/logto/issues/823)) ([4ffd4c0](https://github.com/logto-io/logto/commit/4ffd4c048028567f701e5a3d6a507907b63a0151))
- **core:** get /logs/:id ([#934](https://github.com/logto-io/logto/issues/934)) ([bddf47b](https://github.com/logto-io/logto/commit/bddf47bf90213397688f3566f0018029e5959709))
- **core:** grantErrorListener for logging token exchange error ([#894](https://github.com/logto-io/logto/issues/894)) ([797344f](https://github.com/logto-io/logto/commit/797344f6f5e3b64e1d8861eeeac0d18cb59032f2))
- **core:** grantRevokedListener for logging revocation of access and refresh token ([#900](https://github.com/logto-io/logto/issues/900)) ([e5196fc](https://github.com/logto-io/logto/commit/e5196fc31dc1c4ec8086c9df2d1cc8f5486af380))
- **core:** identities key should use target not connectorId ([#1115](https://github.com/logto-io/logto/issues/1115)) ([41e37a7](https://github.com/logto-io/logto/commit/41e37a79955ac4f6437c4e52c1cf3f74adaad811)), closes [#1134](https://github.com/logto-io/logto/issues/1134)
- **core:** log error body ([#1065](https://github.com/logto-io/logto/issues/1065)) ([2ba1121](https://github.com/logto-io/logto/commit/2ba11215edc8bc83efcd41e1587b53fddc5bb101))
- **core:** log sending passcode with connector id ([#824](https://github.com/logto-io/logto/issues/824)) ([82c7138](https://github.com/logto-io/logto/commit/82c7138683f1027a227b3939d7516e0912773fe5))
- **core:** make GET /api/swagger.json contain all api routes ([#1008](https://github.com/logto-io/logto/issues/1008)) ([8af2f95](https://github.com/logto-io/logto/commit/8af2f953cf826cc5c72c0b7a0ae30d50b8caa6d9))
- **core:** order logs by created_at desc ([#993](https://github.com/logto-io/logto/issues/993)) ([2ae4e2e](https://github.com/logto-io/logto/commit/2ae4e2eccfd3699516d4d192f42607fea2b56623))
- **core:** register with admin role ([#1140](https://github.com/logto-io/logto/issues/1140)) ([4f32ad3](https://github.com/logto-io/logto/commit/4f32ad3a511985b1ccb8706cff3b604c86a7d50b))
- **core:** separate social sign-in api ([#735](https://github.com/logto-io/logto/issues/735)) ([e71cf7e](https://github.com/logto-io/logto/commit/e71cf7ea67dbd22eac6a3aa12aa20687c00aa7e6))
- **core:** serve connector logo ([#931](https://github.com/logto-io/logto/issues/931)) ([5b44b71](https://github.com/logto-io/logto/commit/5b44b7194ed4f98c6c2e77aae828a39b477b6010))
- **core:** set claims for `profile` scope ([#1013](https://github.com/logto-io/logto/issues/1013)) ([7781d49](https://github.com/logto-io/logto/commit/7781d496676cc233b4d62214fa11e9fdfda21929))
- **core:** update connector db schema ([#732](https://github.com/logto-io/logto/issues/732)) ([8e1533a](https://github.com/logto-io/logto/commit/8e1533a70267d459feea4e5174296b17bef84d48))
- **native-connectors:** pass random state to native connector sdk ([#922](https://github.com/logto-io/logto/issues/922)) ([9679620](https://github.com/logto-io/logto/commit/96796203dd4247d7ecdee044f13f3d57f04ca461))
- remove target, platform from connector schema and add id to metadata ([#930](https://github.com/logto-io/logto/issues/930)) ([054b0f7](https://github.com/logto-io/logto/commit/054b0f7b6a6dfed66540042ea69b0721126fe695))
- update field check rules ([#854](https://github.com/logto-io/logto/issues/854)) ([85a407c](https://github.com/logto-io/logto/commit/85a407c5f6f76fed0513acd6fb41943413935b5a))
- use user level custom data to save preferences ([#1045](https://github.com/logto-io/logto/issues/1045)) ([f2b44b4](https://github.com/logto-io/logto/commit/f2b44b49f9763b365b0062000146fee2b8df72a9))
- **console,core:** only show enabled connectors in sign in methods ([#988](https://github.com/logto-io/logto/issues/988)) ([4768181](https://github.com/logto-io/logto/commit/4768181bf77261eb84a1c4cb903fa0a22765d837))
- **console:** update terms of use ([#1122](https://github.com/logto-io/logto/issues/1122)) ([9262a6f](https://github.com/logto-io/logto/commit/9262a6f3beb7c2c46708453ce7d667dc5b39da8e))
- **console:** update user data ([#1184](https://github.com/logto-io/logto/issues/1184)) ([a3d3a79](https://github.com/logto-io/logto/commit/a3d3a79dd9c93c2bd23af78da1eb45de81642c3f))
- **core,console:** delete specific user identities by target ([#1176](https://github.com/logto-io/logto/issues/1176)) ([ad86bc8](https://github.com/logto-io/logto/commit/ad86bc8e120e571268cffbb45fe3c8253c1207fe))
- **core:** allow empty condition in logs ([#991](https://github.com/logto-io/logto/issues/991)) ([2819859](https://github.com/logto-io/logto/commit/28198590faa16b010dfb8050738a1f9a60f26bd9))
- **core:** catch interaction not found error ([#827](https://github.com/logto-io/logto/issues/827)) ([38ceae7](https://github.com/logto-io/logto/commit/38ceae78536fadabd1abfb845c3172908d4662b4))
- **core:** disabled session check for preview mode ([#867](https://github.com/logto-io/logto/issues/867)) ([82674ee](https://github.com/logto-io/logto/commit/82674eea885e6819213f10833b6a5a66dec9f6ac))
- **core:** fix preview session not found bug ([#970](https://github.com/logto-io/logto/issues/970)) ([545a392](https://github.com/logto-io/logto/commit/545a3929e4e0bd8853c142ec5ca27520ba428da1))
- **core:** koaAuth should return 403 instead of 401 on non-admin role ([ee16eeb](https://github.com/logto-io/logto/commit/ee16eeb9662d99d04a8d2c2770f89f0641f1e743))
- **core:** prevent session lost for bind social ([#948](https://github.com/logto-io/logto/issues/948)) ([077ed12](https://github.com/logto-io/logto/commit/077ed120f09cdfdb81e95cbb434488569f87bfd1))
- **core:** remove name regex ([#1109](https://github.com/logto-io/logto/issues/1109)) ([a790248](https://github.com/logto-io/logto/commit/a790248c091e444614652b08b05686e9934cb639))
- **core:** remove unavailable social sign in targets on save ([#1201](https://github.com/logto-io/logto/issues/1201)) ([012562e](https://github.com/logto-io/logto/commit/012562e2a8226525b4d4b8c80eb092b1780e0221))
- **core:** revert add custom claims to id token ([#919](https://github.com/logto-io/logto/issues/919)) ([fe99928](https://github.com/logto-io/logto/commit/fe99928a41e1987f7fd078b711c9a0bb2c86e5c9))
- **core:** set module in base config ([#685](https://github.com/logto-io/logto/issues/685)) ([d108f4b](https://github.com/logto-io/logto/commit/d108f4b8833ea86ccfe74b2165e844493f738da4))
- **core:** settings api should not throw session not found error ([#1157](https://github.com/logto-io/logto/issues/1157)) ([e0793fa](https://github.com/logto-io/logto/commit/e0793facb92d0b10a0c52e3346f4fd4ad81662cd))
- **core:** signing in with a non-existing username should throw invalid credentials ([#1239](https://github.com/logto-io/logto/issues/1239)) ([53781d6](https://github.com/logto-io/logto/commit/53781d619dedc4e51d87d4ad917d0dbfcc1510d9))
- **core:** social user info in session ([#794](https://github.com/logto-io/logto/issues/794)) ([74f2940](https://github.com/logto-io/logto/commit/74f2940398ecdfe00f0d8306f01451d859cff186))
- **core:** update role names ([#913](https://github.com/logto-io/logto/issues/913)) ([d659995](https://github.com/logto-io/logto/commit/d65999514f9d3d516bc18e1e0396eff8b42daa50))
- **core:** update roleNames to role_names to resolve 401 errors ([5a1fa14](https://github.com/logto-io/logto/commit/5a1fa14a981cba0fa7314941902a8d017fad42f3))
- **core:** update timestamp field with millisecond precision ([#677](https://github.com/logto-io/logto/issues/677)) ([7278ba4](https://github.com/logto-io/logto/commit/7278ba40958ca57468e562a6978c25e6c993dd20))
- **ui:** fix sign-in not found bug ([#841](https://github.com/logto-io/logto/issues/841)) ([5d34442](https://github.com/logto-io/logto/commit/5d34442018d0577ff3f90d57008d2af5d4f5b54b))
