Skip to content

v1.15.0

Compare
Choose a tag to compare
@silverhand-bot silverhand-bot released this 10 Apr 14:00
· 200 commits to master since this release
v1.15.0
fb55249

Direct sign-in

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

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

  • A social connector
  • An enterprise SSO connector

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

First screen parameter

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

See the First screen documentation for more information.

Full OpenID Connect standard claims support

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

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

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

Note

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

Social data

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

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

Lazy password migration

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

Currently supported algorithms are:

  • Bcrypt
  • MD5
  • SHA1
  • SHA256
  • Argon2i

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

See API reference for more information.

Improvements

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

Fixes

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

Development

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