logto

🧑‍🚀 The better identity infrastructure for developers and the open-source alternative to Auth0.

MPL-2.0 License

Downloads
2.3K
Stars
8.5K
Committers
66
View Code on GitHub Visit Website View on X
Ecosystems: PostgreSQL, JavaScript, TypeScript, Node.js

Bot releases are visible (Hide)

logto - v1.20.0

Published by charIeszhao about 1 month ago

Arabic translation and RTL support

  • #6422 Added new Arabic language translation to both Console and Experience UI (credit @zaaakher).
  • Improved UI layout and details to better support RTL languages.

Personal access token (PAT)

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.

Refer to documentation for more details.

Support additional first-screen options

In addition to sign-in and register, we now enabled more options that allowing developers to customize the initial screen presented to users. These new first-screen options are:

  • 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.

Refer to documentation for more details.

New connectors

  • #6227 Added Kook connector (credit @Misaka-L).
  • #6514 Added Patreon connector (credit @devtekve).
  • #6529 Added GitLab connector (credit @devtekve).

Improvements

  • #6400 Supported login_hint as additional sign-in parameter.
  • #6445 Implemented well-known swagger endpoints.
  • #6451 Split translate command from @logto/cli to make the CLI small and simple.
  • #6451 Added a dedicated @logto/translate package to translate i18n phrases in Console and Experience.
  • #6523 Supported entering name while creating a user in Console.
  • #6525 Added new query parameter parse_error and explicitly set it to false to return raw OIDC error message only.
  • #6532 Added denyAccess() api to custom JWT context in order to conditionally block user token request.
  • #6534 Supported nested attribute profile mapping in OAuth connector (credit @devtekve).
  • #6543 Added hasPassword property to /users Management API response.
  • #6544 Added user password information in user details. Admin can easily check if a user has set password or not, and can then perform set/reset action accordingly.
  • #6567 Added new management API to check password against current password policy settings.

Fixes

  • #6425 Prevented potential error caused by cached identifiers across Experience pages.
  • #6441 Fixed the issue that blocked users from creating Custom JWT.
  • #6481 Fixed wecom connector platform. Use Universal instead of null.
  • #6536 Set lang attribute correctly to <html> in Console, preventing unexpected browser translator prompt.
  • #6560 Allowed linking new social identity to an existing user account when registration is disabled.
  • #6576 Prevented user registration and profile fulfillment with SSO-only email domains.
logto - v1.19.0

Published by silverhand-bot 2 months ago

User impersonation (RFC 8693: OAuth 2.0 Token Exchange)

Added support for user impersonation via Token Exchange:

  • New Management API endpoint POST /subject-tokens to request a subject_token for token exchange use.
  • Updated the OIDC POST /oidc/token endpoint with a new grant type urn:ietf:params:oauth:grant-type:token-exchange to exchange a subject_token for a user-impersonated access_token.

See User impersonation for more details.

Application level custom_data

Added a new arbitrary object field custom_data to applications. This field can store any additional information not defined in the standard Application schema.

  • New PATCH /api/applications/{applicationId}/custom-data endpoint to patch update the custom_data field of an application.
  • Update PATCH /api/applications/{applicationId} endpoint to allow overwriting the custom_data field.

Added a new custom data JSON editor to the application details page (except for Protected Apps).

Multiple app secrets management

Secure apps (machine-to-machine, traditional web, Protected) can now have multiple app secrets with expiration. This allows for secret rotation and provides an even safer experience.

[!Note]
The legacy secret created before this feature can still be used for client authentication. However, it is recommended to delete the old ones and create new secrets with expiration for enhanced security.

  • GET /api/applications/{applicationId}/secrets: List all the secrets of an application.
  • POST /api/applications/{applicationId}/secrets: Create a new secret for an application.
  • DELETE /api/applications/{applicationId}/secrets/{name}: Delete a secret of an application by name.
  • PATCH /api/applications/{applicationId}/secrets/{name}: Update a secret of an application by name.
  • DELETE /api/applications/{applicationId}/legacy-secret: Delete the legacy secret of an application and replace it with a new one.

To manage your application secrets, go to Logto Console -> Applications -> Application Details -> Endpoints & Credentials.

The original app secret read-only input field is now replaced with a new secrets management table. You can create, update, and delete secrets in this table.

Organization and application level branding

Organization logo

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:

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.

Application 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.

Performance improvements

Support experience app 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.

Package build improvements

  • Use tsup to build the connector packages. This will make the build process faster, and should not affect the functionality of the packages.
  • User Vite for transpilation and bundling of the @logto/console, @logto/demo-app, and @logto/experience packages. Removed ParcelJS and replaced with Vite. No breaking changes should be expected.

Bug fixes

Fix the jsonb update behavior of the PATCH /api/applications/{applicationId} endpoint

All the jsonb fields of the Application object should be updated in the replace mode instead of the merge mode. This change will make the PATCH method more predictable and consistent with the Restful API design.

  • Update the jsonb field update mode from merge to replace in the PATCH /api/applications/{applicationId} endpoint.
  • Update the API jsonb field input parameters validation from partial to full in the PATCH /api/applications/{applicationId} endpoint.
  • Affected fields: oidc_client_metadata, custom_client_metadata, protected_app_metadata and custom_data.

[!Note]
If you are using Logto console to update the Application settings, you should not be affected by this change. API users who are using the PATCH method to update the Application jsonb field settings should be aware of this change. The PATCH method will now replace the whole jsonb field with the new input data. Any partial input data of the affected fields will be rejected.

Fix some of the webhooks event payload always return API response status 404 bug

Affected webhook events: Role.Scopes.Updated, Organizations.Membership.Updates.

The API response status code returned from the webhook event payload was always 404. That was caused by inserting the webhook event payload before the API response context was set.

Since we only trigger the webhook when the event is successfully processed, the status code should always be 2xx.

This issue have been fixed by moving the webhook event payload insertion after the API response context is set.

Other improvements

  • The favicon for the dark theme now can be set in the sign-in experience branding settings.
  • Add new password digest algorithms: Argon2d and Argon2id. Users with those algorithms will be migrated to Argon2i upon successful sign-in.
  • The browser list configuration for @logto/experience has been synced with what is stated in README.md.
  • Improve swagger auth description. Use the native OpenAPI OAuth2 security scheme instead of the custom HTTP header-based security schema.
logto - v1.18.0

Published by silverhand-bot 3 months ago

[!Note]
Our public roadmap has come back. Upvote the features you need and feel free to leave comments!

Compliance

We are SOC 2 Type I compliant, officially! 🎉 A Type II audit is on the horizon.

SOC 2 Type I

Just-in-Time 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.

To use this feature, head to the organization settings and find the "Just-in-Time provisioning" section. Management APIs are also available to configure this feature via routes under /api/organizations/{id}/jit. To learn more, see Just-in-Time provisioning.

Organization 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:
    • GET /organizations/{organizationId}/jit/email-domains
    • POST /organizations/{organizationId}/jit/email-domains
    • PUT /organizations/{organizationId}/jit/email-domains
    • DELETE /organizations/{organizationId}/jit/email-domains/{emailDomain}
  • 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:
    • GET /organizations/{organizationId}/jit/sso-connectors
    • POST /organizations/{organizationId}/jit/sso-connectors
    • PUT /organizations/{organizationId}/jit/sso-connectors
    • DELETE /organizations/{organizationId}/jit/sso-connectors/{ssoConnectorId}
  • 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:
    • GET /organizations/{organizationId}/jit/roles
    • POST /organizations/{organizationId}/jit/roles
    • PUT /organizations/{organizationId}/jit/roles
    • DELETE /organizations/{organizationId}/jit/roles/{organizationRoleId}
  • In the Logto Console, you can manage default roles in the organization details page -> "Just-in-Time provisioning" section.

Machine-to-machine apps for organizations

This feature allows machine-to-machine apps to be associated with organizations, and be assigned with organization roles.

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.

  • 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.

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.

Swagger (OpenAPI) improvements

[!Note]
Shout out to @mostafa for bringing these amazing improvements to Logto!

Build operationId for Management API in OpenAPI response

As per the specification:

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:

- org, _, err := s.Client.OrganizationsAPI.ApiOrganizationsIdGet(ctx, req.GetId()).Execute()
+ org, _, err := s.Client.OrganizationsAPI.GetOrganization(ctx, req.GetId()).Execute()

- users, _, err := s.Client.OrganizationsAPI.ApiOrganizationsIdUsersGet(ctx, req.GetId()).Execute()
+ users, _, err := s.Client.OrganizationsAPI.ListOrganizationUsers(ctx, req.GetId()).Execute()

Fixed OpenAPI schema returned by the GET /api/swagger.json endpoint

  • The : character is invalid in parameter names, such as organizationId:root. These characters have been replaced with -.
  • 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.

Backchannel logout support

We've enabled the support of OpenID Connect Back-Channel Logout 1.0.

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.

Sign-in experience

Support Google One Tap

When you added Google as a social connector, you can now enable Google One Tap to provide a smoother sign-in experience for your users with Google accounts.

Head to the Google connector settings in the Logto Console and switch on the "Google One Tap" option.

Google One Tap settings

To learn more about Google One Tap, see Enable Google One Tap.

Allow skipping manual account linking during sign-in

You can find this configuration in Console -> Sign-in experience -> Sign-up and sign-in -> Social sign-in -> Automatic account linking.

When switched on, if a user signs in with a social identity that is new to the system, and there is exactly one existing account with the same identifier (e.g., email), Logto will automatically link the account with the social identity instead of prompting the user for account linking.

Agree to terms polices for sign-in experience

We've added a new configuration to allow you to set the terms of service agreement policy for sign-in experience:

  • 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.

Console improvements

  • Added Ruby and Chrome extension guide.
  • Display OIDC issuer endpoint in the application details form.
  • Application guides have been reorganized to provide a better developer experience.
  • Now you can view and update user's profile property in the user settings page.
  • Improved machine-to-machine application integration user experience.
  • Fixed a regression bug that error toasts pop up in audit log when logs are associated with deleted applications.

Other improvements

  • Added hasPassword to custom JWT user context.
  • Connector: Google and Azure AD connectors now support custom prompt.
  • 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.
  • A dev panel is available after you sign in to the live preview.
  • Pagination is now optional for GET /api/organizations/{id}/users/{userId}/roles. If you don't provide page and limit query parameters, the API will return all roles.
  • Added user detail data payload to the User.Deleted webhook event.
logto - v1.17.0

Published by silverhand-bot 5 months ago

[!Note]
The US region is now available in Logto Cloud.

New webhook events

We are introducing a series of new webhook events triggered by data updates, mostly through the Management API, which are useful for various automation scenarios. These include user events, role events, organization events, etc. For the full list of events, please see Webhook events.

To improve clarity, the Console now displays the raw event key instead of the translated text for webhooks. For example, "Create new account" is now displayed as "PostRegister".

User default roles

You can now set default roles for users by visiting the role details page, clicking on the "General" tab, and then enabling the "Default role" switch. Once activated, all new users will automatically be assigned all the default roles upon account creation.

This enables you to configure Logto apps with resources and scopes associated with a default role, ensuring new users receive the necessary scopes right after registration.

[!Note]
All existing users will not be affected.

Improvements

  • #5915 Added DingTalk web connector (credit @anyidea).
  • #5908 A pre-configured role with Management API access will be created when seeding the database.
  • #5955 Added sso_identities ID token claim to the userinfo endpoint response. It is an array of objects that stores the current user's SSO identities.
    • To request this claim, you can use the identities scope which is shared with social identities.
  • #5950 In OSS, show the current version number in the top right corner.
  • Improved error handling and deleted item display on Console.
  • Show global loading state on page redirects to prevent user interactions.
  • Updated documentation reference links.

Fixes

  • #5925 GitHub connector: Fix a potential blocking error in when GET /users/emails responds 403
  • #5912 Fixed Microsoft EntraID OIDC SSO connector invalid authorization code response issue
logto - v1.16.0

Published by silverhand-bot 5 months ago

Custom JWT

JWT access tokens can now be customized with additional claims using custom JavaScript code snippets. This feature is useful when you need to include custom data in the token for compatibility with other systems.

To use this feature, navigate to the "Custom JWT" tab in the Console. Both user and machine-to-machine (M2M) tokens can be customized.

Before deploying the changes, you can use the "Run test" button to see how the token will look with the custom claims.

See 🎫 Custom JWT claims for more information.

[!Warning]
In the open-source version, the code for custom JWT will run in the same environment as the rest of the Logto code. Be careful when adding custom code to the JWT, as it can introduce security vulnerabilities.

API resources for organization roles

You can now assign permissions (scopes) from the API resources to organization roles. Like other permissions in the organization template, these permissions are organization-level, meaning that they only apply to a specific organization.

Let's see an example:

  • There is an API resource called https://shopping.api/.
  • The API resource has two scopes: read and write.
  • There are two organization roles: admin and user.
  • The admin role has both read and write scopes; the user role has only the read scope.
  • A user Alice is assigned the admin role in the organization foo, and the user role in the organization bar.

When Alice tries to exchange an organization token for the https://shopping.api/ resource, she will receive a token with scopes based on which organization she is requesting the token for.

For the foo organization, Alice will receive a token with both read and write scopes. For the bar organization, she will receive a token with only the read scope.

See 🏢 Organizations (Multi-tenancy) for a comprehensive introduction to organizations.

Third-party app permissions

Organizational API resources can also be used when configuring permissions for third-party apps. User will be prompted to select an organization when configuring permissions for a third-party app.

Organization custom data

Now you can save additional data associated with the organization with the organization-level customData field by:

  • Editing in the Console organization details page.
  • Specifying the customData field when using organization Management APIs.

Connectors

  • Added Hugging Face connector.
  • GitHub connector now has the user:email as part of default scope to fetch GitHub account's private email address list.
    • It now picks the verified primary email among private email address list as a fallback if the user does not set a public email for GitHub account.
  • Removed the plus sign in front of the phone number in the feishu connector (#5801). Credit @kamto7.

Improvements

  • Added support for Redis Cluster and extra TLS options for Redis connections (#5619). Credit @alekitto.
  • OIDC and OAuth 2 connectors now support client_secret_basic and client_secret_jwt client authentication methods for the token endpoint.
  • When a user is deleted or suspended through Management API, they will be signed out in Logto and their sessions will be invalidated immediately.
  • Support comma separated resource parameter as some libraries do not support array of resources.
  • Added an API to fetch user organization scopes based on user organization roles (GET /api/organizations/:id/users/:userId/scopes).
  • Added Java Spring Boot web integration guide.
  • Added zh-cn phrases in OIDC consent page (#5606). Credit @the-pawn-2017.

Fixes

  • Organization invitation APIs should handle invitee emails case insensitively.
  • Management API will not return 500 in production for status codes that are not listed in the OpenAPI spec.
  • Return 403 instead of 400 when Logto tries to grant an access token to a user lacking the required permissions, especially when granting for organization related resources.
  • Fixed the wrong social sign-in callback that posts to the native container (e.g. WKWebView in iOS).
  • Fixed the new user from SSO register hook event not triggering bug.
  • Fixed a bug that API resource indicator does not work if the indicator is not followed by a trailing slash or a pathname.
logto - v1.15.0 Latest Release

Published by silverhand-bot 6 months ago

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
logto - v1.14.0

Published by silverhand-bot 8 months ago

New features

  • Support form post callback for social connectors
    • Add the POST /callback/:connectorId endpoint to handle the form post callback for social connectors. This is useful for the connectors that require a form post callback to complete the authentication process, such as Apple.
  • SMTP connector: Always show TLS configurations in Logto Console
  • Apple connector: Support scope parameter
    • Now you can request for email and name during Sign in with Apple
logto - v1.13.1

Published by silverhand-bot 8 months ago

Console application guides

  • Add Angular, Nuxt, SvelteKit, Expo (React Native) guides
  • Update Next.js guide
logto - v1.13.0

Published by silverhand-bot 8 months ago

logto - v1.12.0

Published by silverhand-bot 11 months ago

logto - v1.11.0

Published by silverhand-bot 11 months ago

Multi-factor authentication (MFA)

Now you can activate MFA with just one click and take control of the user security. We've made it easy to customize the sign-in experience with these 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.

Set up MFA by one-click

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.

Check out our One-click MFA integration blog post to learn more.

Work in progress

Organizations and enterprise Single Sign-On (SSO) functionalities are on the horizon. With Logto, creating multi-tenancy applications and becoming enterprise-ready will not be a business blocker anymore.

logto - v1.10.1

Published by silverhand-bot 12 months ago

Fixes

fix 500 error when using search component in console to filter both roles and applications

logto - v1.10.0

Published by silverhand-bot about 1 year ago

New feature: machine-to-machine role-based access control

Role-based access control (RBAC) now extends to machine-to-machine apps. This update allows you to effectively manage permissions for your machine-to-machine apps using the same approach for user authorization.

Note
If you have switched on the "Enable admin access" toggle for machine-to-machine apps, it has been retired in favor of a new "Management API access" role; if you haven't enabled it, a new role with Management API permissions is needed to access the Logto Management API. See 🚝 Interact with Management API to learn more.

Starting today, when you create a new role, you can select either a "user role" or a "machine-to-machine app role" by expanding more options. All existing roles have automatically been converted to "user roles".

Constraints

  • After creating a role, you cannot modify its type.
  • The Logto Management API resource can only be accessed by machine-to-machine application roles.

Added APIs

Applications

  • POST /applications/:appId/roles assigns role(s) to the M2M application
  • DELETE /applications/:appId/roles/:roleId deletes the role from the M2M application
  • GET /applications/:appId/roles lists all roles assigned to the M2M application

Roles

  • POST /roles/:roleId/applications assigns the role to multiple M2M applications
  • DELETE /roles/:roleId/applications/:appId removes the M2M application assigned to the role
  • GET /roles/:roleId/applications lists all M2M applications granted with the role

Updated APIs

Roles

  • POST /roles to specify the role type (either user or machine-to-machine role)

Users

  • POST /users/:userId/roles to prevent assigning M2M roles to end-users

Support roles scope for issuing the roles claim in ID tokens

When you include the roles in the scope parameter of the Logto SDK config (or manually append to the OpenID Connect auth request), the ID token will include a roles claim containing an array of the user's roles. This may resolve #3411.

Security update

If an identifier (username, email, or phone number) experiences five authentication failures within an hour, it will be temporarily blocked from the authentication process for ten minutes.

logto - v1.9.1

Published by silverhand-bot about 1 year ago

Fixes

  • fix a bug that prevents user from customizing i18n translations in sign-in experience config
  • add more intuitive code samples and fix mistakes in express api guide
logto - v1.9.0

Published by silverhand-bot about 1 year ago

New feature: Password policy

Summary

This newly introduced feature empowers you to customize a range of password policies specific to your Logto tenant:

  • Minimum password length (default: 8)
  • Minimum character types (default: 1)
  • Prevention of breached passwords (default: Enabled)
  • Restriction of repetitive or sequential characters (default: Enabled)
  • Restriction of user information in passwords (default: Enabled)
  • Custom restricted words (default: None specified)

To begin configuring these settings, simply navigate to the Logto Console under "Sign-in experience" and select "Password policy".

Note
New to password policy? Check out our blog post Design your password policy to master this feature!

For Logto Cloud users, or if you are upgrading Logto from a previous version, please take note that we are committed to ensuring a smooth upgrade. As such, we will maintain your existing password policy as follows:

  • Minimum length: 8 characters
  • Minimum character types: 2
    • Please be aware that, with the implementation of the new policy, combining lowercase and uppercase letters will no longer be considered as a single character type.
  • Prevention of breached passwords: Disabled
  • Restriction of repetitive or sequential characters: Disabled
  • Restriction of user information in passwords: Disabled
  • Custom restricted words: None specified

Should you wish to update your password policy manually, you can do so within the Logto Console as described above.

Impact on users

  • All new users will be subject to the new policy immediately upon creation.
  • Existing users will not be affected by the updated policy until they choose to change their password.

Management API changes

We have removed password restrictions for adding or updating users via the Management API.

CLI improvements

  • Support region option for s3 storage (#4439).
  • Keep original untranslated mark when syncing translate keys (#4443).

Refactoring

  • Rename @logto/ui to @logto/experience.
  • Rename @logto/phrases-ui to @logto/phrases-experience.

These renames do not affect Logto product, so we didn't mark them as breaking changes.

Fixes

  • Fix the app crash when inputting verification code in Console profile page.
  • Align cli output for a better looking.
logto - v1.8.0

Published by silverhand-bot about 1 year ago

Note
We are busily building MFA, Organizations, Enterprise SSO, and more security features. Subscribe to our newsletter so you won't miss any updates!

Feature updates

New app guides design

The app guides have been completely redesigned for an even more streamlined experience. Now when you create an app, you can search for your favorite framework or integration, and enjoy the tailored interactive tutorial.

New SDKs

We've crafted four new official SDKs: Python, PHP, ASP.NET Core, and CapacitorJS.

Don't hesitate to let us know if your favorite framework is missing. :-)

Mailgun connector

We added a dedicated connector to make sending emails via Mailgun easier. It also supports Mailgun email templates.

Specify algorithm when rotating keys

The CLI command to rotate OIDC private keys now supports specifying the key type. While the default key type ec may not work in legacy platforms, you can use --type rsa to prepend a new RSA key, for example:

logto db config rotate oidc.privateKey --type rsa

Improvements

  • Application CORS config now allows non-http origins. This is helpful for cross-platform frameworks like CapacitorJS.
  • Remove connector link from session storage when needed (#4406 by @jay-dee7)
  • Regular content updates, code improvements, bug fixes.
logto - v1.7.0

Published by silverhand-bot about 1 year ago

It has been a busy month, and we just launched Logto Cloud! Meanwhile, we also improved our OSS with some new features:

Feature updates

  • Added translate sync-keys command in CLI. This command is helpful for syncing keys from one language to another. See Translation for details.
  • Added SMSAero connector (credit @evist0).
  • Allow editing refresh token time-to-live (TTL) for applications except machine-to machine.

We are gradually shifting resources back to OSS and we'll bring more exciting features this year. Stay tuned.

logto - v1.6.0

Published by silverhand-bot over 1 year ago

Features

Application details page in Console

  • Added OpenID Provider configuration endpoint display
  • Added application "Rotate Refresh Token" toggle
  • Added application "Refresh Token TTL" configuration

Fixes

  • Fix interaction issues of sign-in experience preview in Console
logto - v1.5.0

Published by silverhand-bot over 1 year ago

Security update

Enabled Content Security Policy (CSP) header check

Removed the report-only flag from the Content Security Policy (CSP) header for both Console and Sign-in Experience. Ensure your endpoints are configured correctly and see no CSP error in the browser's console before upgrading, otherwise frontend may break in this version.

Feature updates

Webhook in Console

We're thrilled to introduce the new Webhook feature in Logto Console, making integration and real-time event notifications a breeze. Here's what's new:

  • Easy Configuration: Configure webhooks effortlessly by multi-selecting events like user registration, sign-in, and password reset. One-click testing of payload delivery ensures smooth setup.
  • Enhanced Security: Each webhook is assigned an auto-generated Signing Key, ensuring the authenticity of payload data from Logto. Customize headers to add extra context.
  • Monitor Webhook Health: Keep an eye on webhook performance with success rates and request times in the last 24 hours. Access independent logs of recent requests for easy troubleshooting.

Note
If you were using Webhooks via Management API, some API details are changed with backward compatibility so you can safely upgrade to this version.

Support setting default API Resource from Console and API

Logto leverages RFC 8707: Resource Indicators for OAuth 2.0 to implement Role-Based Access Control (RBAC). While it is one of the features of OAuth 2.0, it is not yet widely supported.

In Logto's implementation, every user-defined permission (scope) must be associated with an API Resource. Otherwise, it will be treated as an OpenID Connect (or OAuth) permission. Generally, this doesn't affect your authorization process. However, when integrating with third-party apps that lack support for RFC 8707 (e.g., ChatGPT plugins), it can pose challenges since the initial authorization request may not include a resource parameter. Consequently, Logto will always issue Opaque Access Tokens.

To address this issue, now you can designate an API Resource as the tenant-level default resource by heading to the details page of an API Resource:

See the documentation to learn what will be affected after turning it on.

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.

Fixes

  • Reset password webhooks will be correctly triggered
  • Bumped oidc-provider version to v8.2.2. This version fixes a bug that prevented the revoked scopes from being removed from the access token.
logto - v1.4.0

Published by silverhand-bot over 1 year ago

This version brings us one step closer to resolving issue #3344. We are actively working on a backward-compatible solution for authorization.

Below are some articles that demonstrate how to use Logto as an OAuth or OIDC Identity Provider:

Feature updates

Introducing the "Always issue Refresh Token" configuration for web apps

Turning on this toggle ensures that Refresh Tokens are always issued, regardless of whether prompt=consent was included in the authorization request or if offline_access was specified in the scope.

Patch updates

  • Improved compatibility by parsing requests with application/json content-type for /oidc APIs.
  • Automated synchronization of trusted social email and phone information for newly registered users, irrespective of the sign-up identifier configuration.
    • For example: Previously, if the "email" was not set as a sign-up identifier (meaning a valid email connector had to be configured and enabled) and Google sign-in was added, the emails from new users would not be synchronized.
    • Starting from v1.4.0, this requirement has been removed, as "social sign-in only" scenarios are not uncommon in real-world cases.
Package Rankings
Top 3.51% on Npmjs.org
Top 6.75% on Proxy.golang.org
Badges
Extracted from project README
discord checks release core coverage cloud gitpod render