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.
- 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.
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`
- 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.
- 62f5e5e0c: support dark favicon
The favicon for the dark theme now can be set in the sign-in experience branding settings.
- 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
- 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.
- 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
- 942780fcf: support Google One Tap
- 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
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: add oidc params variables and types
- Add `ExtraParamsKey` enum for all possible OIDC extra parameters that Logto supports.
- Add `FirstScreen` enum for the `first_screen` parameter.
- Add `extraParamsObjectGuard` guard and `ExtraParamsObject` type for shaping the extra parameters object in the OIDC authentication request.
- cc01acbd0: Create a new user through API with password digest and corresponding algorithm
- Create an organization scope with an empty description and assign this scope to a third-party application.
- Login to the third-party application and request the organization scope.
- Proceed through the interaction flow until reaching the consent page.
- An internal server error 500 is returned.
### Root cause
For the `/interaction/consent` endpoint, the organization scope is returned alongside other resource scopes in the `missingResourceScopes` property.
In the `consentInfoResponseGuard`, we utilize the resource Scopes zod guard to validate the `missingResourceScopes` property. However, the description field in the resource scope is mandatory while organization scopes'description is optional. An organization scope with an empty description will not pass the validation.
### Solution
Alter the resource scopes table to make the description field nullable. Related Scope zod guard and the consentInfoResponseGuard will be updated to reflect this change. Align the resource scopes table with the organization scopes table to ensure consistency.
- 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.
- 32df9acde: update Logto application schemas to support the new third-party application feature (Logto as IdP)
- Applications table alteration. Add new column `is_third_party` to indicate if the application is a third-party application.
- Create new table `application_user_consent_resource_scopes` to store the enabled user consent resource scopes for the third-party application.
- Create new table `application_user_consent_organization_scopes` to store the enabled user consent organization scopes for the third-party application.
- Create new table `application_user_consent_user_scopes` to store the enabled user consent user scopes for the third-party application.
- Create new table `application_user_consent_organizations` to store the user granted organizations for the third-party application.
- Create new table `application_sign_in_experiences` to store the application level sign-in experiences for the third-party application.
- 9a7b19e49: Add single sign-on (SSO) table and schema definitions
- Add new sso_connectors table, which is used to store the SSO connector data.
- Add new user_sso_identities table, which is used to store the user's SSO identity data received from IdP through a SSO interaction.
- Add new single_sign_on_enabled column to the sign_in_experiences table, which is used to indicate if the SSO feature is enabled for the sign-in experience.
- Define new SSO feature related types
### Patch Changes
- 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.
- 46d0d4c0b: convert private signing key type from string to JSON object, in order to provide additional information such as key ID and creation timestamp.
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:
- Update `passwordPolicy` property in the sign-in experience via Management API.
### Side effects
- All new users will be affected by the new policy immediately.
- Existing users will not be affected by the new policy until they change their password.
- We removed password restrictions when adding or updating a user via Management API.
- 17fd64e64: Support region option for s3 storage
- 5d78c7271: Add `type` field to `roles` schema.
`type` can be either 'User' or 'MachineToMachine' in our case, this change distinguish between the two types of roles.
Roles with type 'MachineToMachine' are not allowed to be assigned to users and 'User' roles can not be assigned to machine-to-machine apps.
It's worth noting that we do not differentiate by `scope` (or `permission` in Admin Console), so a scope can be assigned to both the 'User' role and the 'MachineToMachine' role simultaneously.
### Patch Changes
- f8408fa77: rename the package `phrases-ui` to `phrases-experience`
- f6723d5e2: rename the package `ui` to `experience`
- 2cab3787c: Add cloudflare configurations to system
- 73666f8fa: Provide new features for webhooks
## Features
- Manage webhooks via the Admin Console
- Securing webhooks by validating signature
- Allow to enable/disable a webhook
- Track recent execution status of a webhook
- Support multi-events for a webhook
## Updates
- 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.
- fa0dbafe8: Add custom domain support
### Patch Changes
- 497d5b526: Support updating sign-in identifiers in user details form
- Admin can now update user sign-in identifiers (username, email, phone number) in the user details form in user management.
- Other trivial improvements and fixes, e.g. input field placeholder, error handling, etc.
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.
- 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
- 343b1090f: Add demo social connectors for new tenant
- f41fd3f05: Replace `passcode` naming convention in the interaction APIs and main flow ui with `verificationCode`.
- 343b1090f: ### Add dynamic favicon and html title
- Add the favicon field in the sign-in-experience branding settings. Users would be able to upload their own favicon. Use local logto icon as a fallback
- Set different html title for different pages.
- sign-in
- register
- forgot-password
- logto
- 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.
- 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: remove the branding style config and make the logo URL config optional
- 1c9160112: ### Features
- Enhanced user search params #2639
- Web hooks
### Improvements
- Refactored Interaction APIs and Audit logs
- 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
- f41fd3f05: Replace the `sms` naming convention using `phone` cross logto codebase. Including Sign-in Experience types, API paths, API payload and internal variable names.
### Patch Changes
- e63f5f8b0: Bump connector kit version to fix "Continue" issues on sending email/sms.
- 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`
- 7fb689b73: Fix version lifecycle script
- 2d45cc3e6: Update alteration script names after versioning
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.
- 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: Replace the `sms` naming convention using `phone` cross logto codebase. Including Sign-in Experience types, API paths, API payload and internal variable names.
- add tables to schemas files ([582f3d6](https://github.com/logto-io/logto/commit/582f3d615862c3d8b2c00d8e60a3617429d48e30))
- handle versioning when no `next-*.ts` found ([#2202](https://github.com/logto-io/logto/issues/2202)) ([61336df](https://github.com/logto-io/logto/commit/61336dfbc833c96ddce88be5082b82a30527ee73))
- make packages public ([e24fd04](https://github.com/logto-io/logto/commit/e24fd0479bc20c92bd38b5e214abe441404ce496))
- 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))
- **console,ui:** generate dark mode color in console ([#1231](https://github.com/logto-io/schemas/issues/1231)) ([f72b21d](https://github.com/logto-io/schemas/commit/f72b21d1602ab0fb35ef3e7d84f6c8ebd7e18b08))
- **console:** add application column in user management ([#728](https://github.com/logto-io/schemas/issues/728)) ([a035587](https://github.com/logto-io/schemas/commit/a0355872c65bc0da27e57e25568fbe5dcc5b671b))
- **console:** add column lastSignIn in user management ([#679](https://github.com/logto-io/schemas/issues/679)) ([a0b4b98](https://github.com/logto-io/schemas/commit/a0b4b98c35ff08c2df0863e4bc2110386fc54aee))
- **console:** dark logo ([#860](https://github.com/logto-io/schemas/issues/860)) ([664a218](https://github.com/logto-io/schemas/commit/664a2180a51b577fb517661cf0d7efb1374f3858))
- **console:** sie form reorg ([#1218](https://github.com/logto-io/schemas/issues/1218)) ([2c41334](https://github.com/logto-io/schemas/commit/2c413341d1c515049faa130416f7a5e591d10e8a))
- **console:** sign in exp guide ([#755](https://github.com/logto-io/schemas/issues/755)) ([bafd094](https://github.com/logto-io/schemas/commit/bafd09474c68ca5539d676d2cbf06fa16e070edb))
- **console:** support persisting get-started progress in settings config ([43b2309](https://github.com/logto-io/schemas/commit/43b2309c994b2eb8b1b8f1c12893eb66b5ce1d95))
- **core,console:** social connector targets ([#851](https://github.com/logto-io/schemas/issues/851)) ([127664a](https://github.com/logto-io/schemas/commit/127664a62f1b1c794569b7fe9d0bfceb7b97dc74))
- **core,schemas:** log IP and user agent ([#682](https://github.com/logto-io/schemas/issues/682)) ([0ecb7e4](https://github.com/logto-io/schemas/commit/0ecb7e4d2fe869ada46cc39e0fef98d2240cb1b2))
- **core,schemas:** save application id that the user first consented ([#688](https://github.com/logto-io/schemas/issues/688)) ([4521c3c](https://github.com/logto-io/schemas/commit/4521c3c8d17becb6b322fc0128fff992f34d2a0d))
- **core:** grantRevokedListener for logging revocation of access and refresh token ([#900](https://github.com/logto-io/schemas/issues/900)) ([e5196fc](https://github.com/logto-io/schemas/commit/e5196fc31dc1c4ec8086c9df2d1cc8f5486af380))
- **core:** log error body ([#1065](https://github.com/logto-io/schemas/issues/1065)) ([2ba1121](https://github.com/logto-io/schemas/commit/2ba11215edc8bc83efcd41e1587b53fddc5bb101))
- **core:** log sending passcode with connector id ([#824](https://github.com/logto-io/schemas/issues/824)) ([82c7138](https://github.com/logto-io/schemas/commit/82c7138683f1027a227b3939d7516e0912773fe5))
- **core:** update connector db schema ([#732](https://github.com/logto-io/schemas/issues/732)) ([8e1533a](https://github.com/logto-io/schemas/commit/8e1533a70267d459feea4e5174296b17bef84d48))
- **demo-app:** show notification in main flow ([#1038](https://github.com/logto-io/schemas/issues/1038)) ([90ca76e](https://github.com/logto-io/schemas/commit/90ca76eeb5460b66d2241f137f179bf4d5d6ae37))
- remove target, platform from connector schema and add id to metadata ([#930](https://github.com/logto-io/schemas/issues/930)) ([054b0f7](https://github.com/logto-io/schemas/commit/054b0f7b6a6dfed66540042ea69b0721126fe695))
- **schemas:** create log indices on application id and user id ([#933](https://github.com/logto-io/schemas/issues/933)) ([bf6e08c](https://github.com/logto-io/schemas/commit/bf6e08c37233da372bc5570f9855df023704a93b))
- **schemas:** make users.avatar URL length 2048 ([#1141](https://github.com/logto-io/schemas/issues/1141)) ([3ac01d7](https://github.com/logto-io/schemas/commit/3ac01d72f9d30eca5836dcfbddd1700ebb3ddac1))
- update field check rules ([#854](https://github.com/logto-io/schemas/issues/854)) ([85a407c](https://github.com/logto-io/schemas/commit/85a407c5f6f76fed0513acd6fb41943413935b5a))
- use user level custom data to save preferences ([#1045](https://github.com/logto-io/schemas/issues/1045)) ([f2b44b4](https://github.com/logto-io/schemas/commit/f2b44b49f9763b365b0062000146fee2b8df72a9))
- **console:** align usage of customizeSignInExperience ([#837](https://github.com/logto-io/schemas/issues/837)) ([808a676](https://github.com/logto-io/schemas/commit/808a676da6239fa0471c65f9920bd9715bfe4c19))
- **console:** update terms of use ([#1122](https://github.com/logto-io/schemas/issues/1122)) ([9262a6f](https://github.com/logto-io/schemas/commit/9262a6f3beb7c2c46708453ce7d667dc5b39da8e))
- **schemas:** remove user foreign key on application id ([#964](https://github.com/logto-io/schemas/issues/964)) ([9d8ef76](https://github.com/logto-io/schemas/commit/9d8ef7632b2d1d2094eae1b232eba334342e5d74))
