v1.26.0

![logto-changelog-2025-03-31](https://github.com/user-attachments/assets/dada7218-0e67-4edd-86fe-3dabcf00c41d)


## Support multiple sign-up identifiers

Logto now supports configuring multiple required identifiers for user registration. This enhancement extends the previous single-identifier limitation, enabling a more comprehensive sign-up process.

### Sign-in experience schema 
Introduces a new optional field, `secondaryIdentifiers`, to the sign-in experience sign-up settings. This enhancement allows developers to specify multiple required user identifiers during the user sign-up process. Available options include `email`, `phone`, `username` and `emailOrPhone`. 

**The difference between `signUp.identifiers `and new `signUp.secondaryIdentifiers`**:

#### Primary identifiers (`signUp.identifiers`):
- Maintains backward compatibility with existing sign-in experience settings
- Represents the initial registration form
- Uses OR logic: Only one type of identifier will be collected
- Special case: `[email, phone]` allows either email OR phone registration, treated as a single requirement.

#### Secondary identifiers (`signUp.secondaryIdentifiers`):
- Optional
- New field introduced for multi-identifier support
- Collects additional required identifiers after primary registration
- Uses AND logic: all configured identifiers are mandatory
- Supports `emailOrPhone` type: requires either email OR phone, treated as a single requirement

**Examples**:

#### Example 1: Username with Required Email and Phone
Primary: `username`  
Secondary: 'email` and `phone`

```json
{
  "identifiers": ["username"],
  "secondaryIdentifiers": [
    {
      "type": "email",
      "verify": true
    },
    {
      "type": "phone",
      "verify": true
    }
  ],
  "verify": true,
  "password": true
}
```

#### Example 2: Username with Either Email or Phone
Primary: `username`  
Secondary: `emailOrPhone`

```json
{
  "identifiers": ["username"],
  "secondaryIdentifiers": [
    {
      "type": "emailOrPhone",
      "verify": true
    }
  ],
  "verify": true,
  "password": true
}
```

#### Example 3: Email/Phone with Required Username
Primary: `email` OR `phone`
Secondary: `username`

```json
{
  "identifiers": ["email", "phone"],
  "secondaryIdentifiers": [
    {
      "type": "username",
      "verify": true
    }
  ],
  "verify": true,
  "password": false
}
```

### Console updates

Enhanced Sign-up Configuration UI:

- Introduced a multi-selector interface replacing the previous single-identifier selector
- Added drag-and-drop functionality for prioritizing identifiers
- The first identifier in the list serves as the primary identifier (`signUp.identifiers`)
- Subsequent identifiers are stored as secondary identifiers (`signUp.secondaryIdentifiers`)

<image src="https://github.com/user-attachments/assets/8fb90f21-9c7c-412d-9e8c-e4ee191ca8a8" width=500 />

## Enhanced sign-in experience configuration

We've relaxed several configuration constraints to give you more flexibility in customizing your authentication flows.

1. The password requirement is now optional when using `username` as a sign-up identifier.  Please note, when configuring `username` as the sole sign-up identifier with password disabled, users will be unable to authenticate after registration. Ensure at least one of the following:

    - Enable password requirement at sign-up
    - Configure additional sign-up identifiers

2. Removed the constraint requiring sign-up identifiers to be enabled as sign-in methods. We have fully decoupled the sign-up identifier settings from the sign-in methods. Developers can now require as many user identifiers as needed during the sign-up process without impacting the sign-in process.

3. Removed the requirement for password verification across all sign-in methods when password is enabled for sign-up.

## Experience package migration

In this release, we have transitioned the user sign-in experience from the legacy `@logto/experience-legacy` package to the latest `@logto/experience package`. This change fully adopts our new Experience API, enhancing the underlying architecture while maintaining the same user experience.

- The sign-in experience front-end  now uses the <code>@logto/experience</code> package by default.
- Fully adopts our new Experience API for improved performance and maintainability
- Maintains complete feature parity with no visible changes to end-users
- Legacy Interaction API and `@logto/experience-legacy` will be deprecated in future releases.

## CLI updates

### @logto/translate
- Improve the OpenAI prompt to better support i18n plural form suffixes
- make method `isLanguageTag` case-insensitive

  Language tag case inconsistency was causing translation mismatches across packages:
     - `@logto/phrases` and `@logto/phrases-experience`: using lowercase tags (e.g., `pt-br`, `zh-cn`)
     - `@logto/language-kit`: using mixed-case tags (e.g., `pt-BR`, `zh-CN`)

  Updated `isLanguageTag` function in language kit to be case-insensitive, ensuring:
     - Consistent language tag matching regardless of case
     - Proper detection of all language tags by translate CLI tool
     - Fixed missing translations due to case mismatches
     
## Logto integrations updates

1. **WordPress integration guide**: Added out-of-box WordPress plugin integration documentation to Logto console
2. **Azure AD social connector enhancement**: Added OAuth `scopes` field to `@logto/connector-azuread`
  - Enables customization of requested user permissions
  - Provides greater flexibility in access control
3.  **OIDC SSO connector authentication bug fixes**: Removed `client_id` from token request body
  - Resolves compatibility issues with OIDC providers like Okta
  - Eliminates redundant client authentication method
    - Before: `client_id` included in both request body and authentication header
    - After: Uses authentication header only
  - This OIDC SSO connector update improves compatibility with providers that enforce strict client authentication methods. By removing the redundant `client_id` from the request body while maintaining the authentication header, we ensure consistent behavior across different OIDC providers.