v1.15.0

## Direct sign-in

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

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

- A social connector
- An enterprise SSO connector

To learn more, see the [Direct sign-in](https://docs.logto.io/docs/recipes/openid-connect/authentication-parameters/#direct-sign-in) documentation.

## First screen parameter

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

See the [First screen](https://docs.logto.io/docs/recipes/openid-connect/authentication-parameters/#first-screen) documentation for more information.

## Full OpenID Connect 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.

## Social data

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

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

## Lazy password migration

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

Currently supported algorithms are:

- Bcrypt
- MD5
- SHA1
- SHA256
- Argon2i

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

See [API reference](https://openapi.logto.io/operation/operation-post-api-users) for more information.

## Improvements

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

## Fixes

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

## Development

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