Skip to main content

Test user experience with live preview

You can use the Live preview feature for convenient testing of your sign-in experience configurations.

Live preview

Navigating to Console > Sign-in experience" and clicking the "Live preview" button in the top right corner will open a new browser tab with a fully functional demo of Logto's capabilities. This demo showcases our experience design approach for sign-in and sign-up flows. It is highly customizable and can be seamlessly integrated into your application.

note:

In this preview, you should create an account first to test the experience. You can manage this account later in Console > User management.

If you try to sign in with the user account you created and the process is successful with no issues, you will be redirected to a success page that displays your identifiers and ID.

Dev panel

After a successful sign-in using Logto’s Live Preview, you’ll land on a dashboard containing two primary actions:

  • Sign out the live preview button: Terminates the current session.
  • Open dev panel button: Launches debugging tools for analyzing your authentication flow.

The Development Panel provides real-time insights for troubleshooting OIDC integration, inspecting tokens and claims, and testing advanced identity scenarios.

Logto Config

Live Preview relies on a hidden demo app featuring a unified sign-in experience by default. In the Logto Config section, you can configure authentication parameters included in authentication requests to instruct Logto OIDC endpoint on how to handle the authentication process. This includes defining your app ID, assigning an organization ID, requesting specific scopes, etc. This setup is similar to initializing the LogtoClient with the LogtoProvider, which establishes a Logto context for your application.

note:

Remember to save your configuration changes. They will take effect the next time you sign in with Live Preview.

  • App ID: Specify your unique App ID. It’s essential for testing per-app sign-in experience, resource protection policies.
  • Sign-in extra parameters: Supply additional authentication parameters to test the custom sign-in process. For examples:
  • Prompt: Add OIDC prompt values (space delimited) to specify whether the Authorization Server prompts the end-user for reauthentication and consent. The defined values are:
    • login: Forces to reauthenticate the end user.
    • consent: Requires user consent before sharing information with the client.
    • none: Indicates that no UI should be displayed. This option is used to check for pre-existing authentication or consent.
  • Scope: Specify the scopes (space delimited) for claim requests. For example:
    • To request user organization details, use two scopes: urn:logto:scope:organizations urn:logto:scope:organization_roles
    • To request API permissions, provide the scope names in the Scope field and enter the corresponding API identifier in the Resource field below.
  • Resource: Enter the API resource identifiers (space delimited) that your application needs access to. This field allows your app to request specific resource access tokens as required.

Refresh token grant

This section details how to refresh tokens for different access types:

  • Resource: Input the specific API Identifier (space delimited) if you need to refresh the API resource access token.
  • Organization ID: Input the organization ID (space delimited) if you need to refresh the organization token.

If both a Resource and an Organization ID are provided, the refresh request will return a access token that supports API resource protection with organization template.

note:

Include consent in the prompt parameter for offline_access. A refresh token will only be issued if the prompt includes consent.

User info

Check the user data retrieved from your authentication flow:

  • Get ID token claims: Retrieve all claims contained in the ID token, such as at_hash, aud, auth_time, exp, iat, issu, and additional user profiles. This is useful for validating the token and extracting necessary user information.
  • Fetch user info: Retrieve only the user profile information by querying the userinfo endpoint.
note:

Use Chrome’s Developer Tools (F12 → Console) to inspect network requests and review the tokens and claims.