Application data structure
Introduction
In Logto, an application refers to a specific software program or service that is registered with the Logto platform and has been granted authorization to access user information or perform actions on behalf of a user. Applications are used to identify the source of requests made to the Logto API, as well as to manage the authentication and authorization process for users accessing those applications.
The use of applications in Logto's sign-in experience allows users to easily access and manage their authorized applications from a single location, with a consistent and secure authentication process. This helps to streamline the user experience and ensure that only authorized individuals are accessing sensitive information or performing actions on behalf of the organization.
Applications are also used in Logto's audit logs to track user activity and identify any potential security threats or breaches. By associating specific actions with a particular application, Logto can provide detailed insights into how data is being accessed and used, allowing organizations to better manage their security and compliance requirements. If you want to integrate your application with Logto, see Integrate Logto.
Properties
Application ID
Application ID is a unique auto-generated key to identify your application in Logto, and is referenced as client id in OAuth 2.0.
Application types
An Application can be one of the following application types:
- Native app is an app that runs in a native environment. E.g., iOS app, Android app.
- Single page app is an app that runs in a web browser, which updates the page with the new data from the server without loading entire new pages. E.g., React DOM app, Vue app.
- Traditional web app is an app that renders and updates pages by the web server alone. E.g., JSP, PHP.
- Machine-to-machine (M2M) app is an application that runs in a machine environment for direct service-to-service communication without user interaction.
Application secret
Application secret is a key used to authenticate the application in the authentication system, specifically for private clients (Traditional Web and M2M apps) as a private security barrier.
Application name
Application name is a human-readable name of the application and will be displayed in the admin console.
The Application name is an important component of managing applications in Logto, as it allows administrators to easily identify and track the activity of individual applications within the platform.
It's important to note that the _Application name_ should be chosen carefully, as it will be visible to all users who have access to the admin console. It should accurately reflect the purpose and function of the application, while also being easy to understand and recognize.
Description
A brief description of the application will be displayed on the admin console application details page. The description is intended to provide administrators with additional information about the application, such as its purpose, functionality, and any other relevant details.
Redirect URIs
Redirect URIs that are a list of valid redirect URIs that have been pre-configured for an application. When a user signs in to Logto and attempts to access the application, they are redirected to one of the allowed URIs specified in the application settings.
The allowed URIs list is used to validate the redirect URI that is included in the authorization request sent by the application to Logto during the authentication process. If the redirect URI specified in the authorization request matches one of the allowed URIs in the application settings, the user is redirected to that URI after successful authentication. If the redirect URI is not on the allowed list, the user will not be redirected and the authentication process will fail.
It is important to ensure that all valid redirect URIs are added to the allowed list for an application in Logto, in order to ensure that users can successfully access the application after authentication.
You can check out the Redirection endpoint for more information.
Post sign-out redirect URIs
Post sign-out redirect URIs are a list of valid URIs that have been pre-configured for an application to redirect the user after they have signed out from Logto.
The use of Allowed Post Sign-out Redirect URIs for Logout is part of the RP-Initiated (Relying Party Initiated) Logout specification in OIDC. This specification provides a standardized method for applications to initiate a logout request for a user, which includes redirecting the user to a pre-configured endpoint after they have signed out.
When a user signs out of Logto, their session is terminated and they are redirected to one of the allowed URIs specified in the application settings. This ensures that the user is directed only to authorized and valid endpoints after they have signed out, helping to prevent unauthorized access and security risks associated with redirecting users to unknown or unverified endpoints.
You can check out the RP-initiated logout for more information.
CORS allowed origins
The CORS (Cross-origin resource sharing) allowed origins are a list of permitted origins from which an application can make requests to the Logto service. Any origin that is not included in the allowed list will not be able to make requests to the Logto service.
The CORS allowed origins list is used to restrict access to the Logto service from unauthorized domains, and to help prevent cross-site request forgery (CSRF) attacks. By specifying the allowed origins for an application in Logto, the service can ensure that only authorized domains are able to make requests to the service.
The allowed origins list should contain the origin where the application will be served. This ensures that requests from the application are allowed, while requests from unauthorized origins are blocked.
OpenID provider configuration endpoint
The endpoint for OpenID Connect Discovery.
Authorization endpoint
Authorization Endpoint is an OIDC term, and it is a required endpoint that is used to initiate the authentication process for a user. When a user attempts to access a protected resource or application hat has been registered with the Logto platform, they will be redirected to the Authorization Endpoint to authenticate their identity and obtain authorization to access the requested resource.
You can check out the Authorization Endpoint for more information.
Token endpoint
Token Endpoint is an OIDC term, it is a web API endpoint that is used by an OIDC client to obtain an access token, an ID token, or a refresh token from an OIDC provider.
When an OIDC client needs to obtain an access token or ID token, it sends a request to the Token Endpoint with an authorization grant, which is typically an authorization code or a refresh token. The Token Endpoint then validates the authorization grant and issues an access token or ID token to the client if the grant is valid.
You can check out the Token Endpoint for more information.
Userinfo endpoint
The OpenID Connect UserInfo Endpoint.
Always issue refresh token
Availability: Traditional web, SPA
When enabled, Logto will always issue refresh tokens, regardless of whether prompt=consent is presented in the authentication request, nor offline_access is presented in the scopes.
However, this practice is discouraged unless necessary (usually it's useful for some third-party OAuth integrations that require refresh token), as it is not compatible with OpenID Connect and may potentially cause issues.
Rotate refresh token
Default: true
When enabled, Logto will issue a new refresh token for token requests under the following conditions:
- If the refresh token has been rotated (have its TTL prolonged by issuing a new one) for one year; OR
- If the refresh token is close to its expiration time (>=70% of its original Time to Live (TTL) passed); OR
- If the client is a public client, e.g. Native application or single page application (SPA).
For public clients, when this feature is enabled, a new refresh token will always be issued when the client is exchanging for a new access token using the refresh token. Although you can still turn off the feature for those public clients, it is highly recommended to keep it enabled for security reasons.
Refresh token time-to-live (TTL) in days
Availability: Not SPA; Default: 14 days
The duration for which a refresh token can be used to request new access tokens before it expires and becomes invalid. Token requests will extend the TTL of the refresh token to this value.
Typically, a lower value is preferred.
Note: TTL refreshment is unavailable in SPA (single page app) for security reasons. This means Logto will not extend the TTL through token requests. To enhance the user experience, you can enable the "Rotate refresh token" feature, allowing Logto to issue a new refresh token when necessary.
Backchannel logout URI
The OpenID Connect backchannel logout endpoint. See Federated sign-out: Back-channel logout for more information.
Custom data
Additional custom application info not listed in the pre-defined application properties, users can define their own custom data fields according to their specific needs, such as business-specific settings and configurations.