🧑🚀 The better identity infrastructure for developers and the open-source alternative to Auth0.
MPL-2.0 License
Bot releases are visible (Hide)
Published by charIeszhao about 1 month ago
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.
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.
login_hint
as additional sign-in parameter.translate
command from @logto/cli
to make the CLI small and simple.@logto/translate
package to translate i18n phrases in Console and Experience.parse_error
and explicitly set it to false
to return raw OIDC error message only.denyAccess()
api to custom JWT context in order to conditionally block user token request.hasPassword
property to /users
Management API response.Universal
instead of null
.lang
attribute correctly to <html>
in Console, preventing unexpected browser translator prompt.Published by silverhand-bot 2 months ago
Added support for user impersonation via Token Exchange:
POST /subject-tokens
to request a subject_token
for token exchange use.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.
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.
PATCH /api/applications/{applicationId}/custom-data
endpoint to patch update the custom_data
field of an application.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).
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.
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.
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.
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:
tsup
to build the connector packages. This will make the build process faster, and should not affect the functionality of the packages.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.PATCH /api/applications/{applicationId}
endpointAll 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.
merge
to replace
in the PATCH /api/applications/{applicationId}
endpoint.partial
to full
in the PATCH /api/applications/{applicationId}
endpoint.oidc_client_metadata
, custom_client_metadata
, protected_app_metadata
and custom_data
.[!Note]
If you are using Logto console to update theApplication
settings, you should not be affected by this change. API users who are using thePATCH
method to update theApplication
jsonb field settings should be aware of this change. ThePATCH
method will now replace the whole jsonb field with the new input data. Any partial input data of the affected fields will be rejected.
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.
Argon2d
and Argon2id
. Users with those algorithms will be migrated to Argon2i
upon successful sign-in.@logto/experience
has been synced with what is stated in README.md
.Published by silverhand-bot 4 months ago
[!Note]
Our public roadmap has come back. Upvote the features you need and feel free to leave comments!
We are SOC 2 Type I compliant, officially! 🎉 A Type II audit is on the horizon.
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.
New users will automatically join organizations with Just-in-Time provisioning if they:
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:
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}
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:
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}
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:
GET /organizations/{organizationId}/jit/roles
POST /organizations/{organizationId}/jit/roles
PUT /organizations/{organizationId}/jit/roles
DELETE /organizations/{organizationId}/jit/roles/{organizationRoleId}
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.
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.[!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
:
character is invalid in parameter names, such as organizationId:root
. These characters have been replaced with -
.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.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.
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.
To learn more about Google One Tap, see Enable Google One Tap.
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.
We've added a new configuration to allow you to set the terms of service agreement policy for sign-in experience:
profile
property in the user settings page.hasPassword
to custom JWT user context.prompt
.GET /api/organizations/{id}/users/{userId}/roles
. If you don't provide page
and limit
query parameters, the API will return all roles.User.Deleted
webhook event.Published by silverhand-bot 5 months ago
[!Note]
The US region is now available in Logto Cloud.
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".
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.
sso_identities
ID token claim to the userinfo endpoint response. It is an array of objects that stores the current user's SSO identities.
identities
scope which is shared with social identities.GET /users/emails
responds 403Published by silverhand-bot 5 months ago
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.
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:
https://shopping.api/
.read
and write
.admin
and user
.admin
role has both read
and write
scopes; the user
role has only the read
scope.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.
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.
Now you can save additional data associated with the organization with the organization-level customData
field by:
customData
field when using organization Management APIs.user:email
as part of default scope to fetch GitHub account's private email address list.
client_secret_basic
and client_secret_jwt
client authentication methods for the token endpoint.resource
parameter as some libraries do not support array of resources.GET /api/organizations/:id/users/:userId/scopes
).zh-cn
phrases in OIDC consent page (#5606). Credit @the-pawn-2017.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:
To learn more, see the Direct sign-in documentation.
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.
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 theprofile
field will fall back toundefined
rather thannull
. We refrain from using?? null
here to reduce the size of ID tokens, sinceundefined
fields will be stripped in tokens.
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.
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:
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.
avatar
and customData
fields in the POST /users
API.GET /organization-roles
can now be called with the q
query parameter to filter the results by the role id, name, or description./interaction/consent
endpoint 500 error.WKWebView
of new iOS versions.@logto/connector-kit
: [BREAKING] update SocialUserInfo
and GetUserInfo
types@logto/connector-kit
: [BREAKING] guard results of parseJson
and parseJsonObject
Published by silverhand-bot 8 months ago
scope
parameter
Published by silverhand-bot 8 months ago
Published by silverhand-bot 8 months ago
Published by silverhand-bot 11 months ago
Published by silverhand-bot 11 months ago
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:
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.
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.
Published by silverhand-bot 12 months ago
fix 500 error when using search component in console to filter both roles and applications
Published by silverhand-bot about 1 year ago
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".
Applications
POST /applications/:appId/roles
assigns role(s) to the M2M applicationDELETE /applications/:appId/roles/:roleId
deletes the role from the M2M applicationGET /applications/:appId/roles
lists all roles assigned to the M2M applicationRoles
POST /roles/:roleId/applications
assigns the role to multiple M2M applicationsDELETE /roles/:roleId/applications/:appId
removes the M2M application assigned to the roleGET /roles/:roleId/applications
lists all M2M applications granted with the roleRoles
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-usersroles
scope for issuing the roles
claim in ID tokensWhen 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.
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.
Published by silverhand-bot about 1 year ago
Published by silverhand-bot about 1 year ago
This newly introduced feature empowers you to customize a range of password policies specific to your Logto tenant:
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:
Should you wish to update your password policy manually, you can do so within the Logto Console as described above.
We have removed password restrictions for adding or updating users via the Management API.
region
option for s3 storage (#4439).@logto/ui
to @logto/experience
.@logto/phrases-ui
to @logto/phrases-experience
.These renames do not affect Logto product, so we didn't mark them as breaking changes.
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!
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.
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. :-)
We added a dedicated connector to make sending emails via Mailgun easier. It also supports Mailgun email templates.
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
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:
translate sync-keys
command in CLI. This command is helpful for syncing keys from one language to another. See Translation for details.We are gradually shifting resources back to OSS and we'll bring more exciting features this year. Stay tuned.
Published by silverhand-bot over 1 year ago
Published by silverhand-bot over 1 year ago
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.
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:
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.
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.
Admin can now update user sign-in identifiers (username, email, phone number) in the user details form in user management.
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:
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.
application/json
content-type for /oidc
APIs.