Estructura de datos de la aplicación
Introducción
En Logto, una aplicación se refiere a un programa o servicio de software específico que está registrado en la plataforma Logto y ha recibido autorización para acceder a la información del usuario o realizar acciones en nombre de un usuario. Las aplicaciones se utilizan para identificar la fuente de las solicitudes realizadas a la API de Logto, así como para gestionar el proceso de autenticación y autorización para los usuarios que acceden a esas aplicaciones.
El uso de aplicaciones en la experiencia de inicio de sesión de Logto permite a los usuarios acceder y gestionar fácilmente sus aplicaciones autorizadas desde un solo lugar, con un proceso de autenticación coherente y seguro. Esto ayuda a simplificar la experiencia del usuario y garantiza que solo las personas autorizadas accedan a información sensible o realicen acciones en nombre de la organización.
Las aplicaciones también se utilizan en los registros de auditoría de Logto para rastrear la actividad del usuario e identificar posibles amenazas o brechas de seguridad. Al asociar acciones específicas con una aplicación en particular, Logto puede proporcionar información detallada sobre cómo se accede y utiliza la información, permitiendo a las organizaciones gestionar mejor sus requisitos de seguridad y cumplimiento. Si deseas integrar tu aplicación con Logto, consulta Integrar Logto.
Propiedades
ID de la aplicación
Application ID es una clave única generada automáticamente para identificar tu aplicación en Logto, y se referencia como client id en OAuth 2.0.
Tipos de aplicación
Una aplicación puede ser uno de los siguientes tipos de aplicación:
- Aplicación nativa es una aplicación que se ejecuta en un entorno nativo. Ejemplo: aplicación iOS, aplicación Android.
- Aplicación de flujo de dispositivo es un tipo especial de aplicación nativa para dispositivos con entrada limitada o aplicaciones sin interfaz gráfica (por ejemplo, televisores inteligentes, consolas de juegos, herramientas CLI, dispositivos IoT). Utiliza el OAuth 2.0 Device Authorization Grant en lugar del flujo estándar basado en redirección. Consulta Inicio rápido de Device flow para más detalles.
- Aplicación de una sola página (SPA) es una aplicación que se ejecuta en un navegador web, que actualiza la página con nuevos datos del servidor sin cargar páginas completas nuevas. Ejemplo: aplicación React DOM, aplicación Vue.
- Aplicación web tradicional es una aplicación que renderiza y actualiza páginas únicamente por el servidor web. Ejemplo: JSP, PHP.
- Aplicación máquina a máquina (M2M) es una aplicación que se ejecuta en un entorno de máquina para la comunicación directa entre servicios sin interacción del usuario.
Secreto de la aplicación
Application secret es una clave utilizada para autenticar la aplicación en el sistema de autenticación, específicamente para clientes privados (aplicaciones web tradicionales y M2M) como barrera de seguridad privada.
Las aplicaciones de una sola página (SPA) y las aplicaciones nativas no proporcionan secreto de aplicación. Las SPA y las aplicaciones nativas son "clientes públicos" y no pueden mantener secretos (el código del navegador o los paquetes de la aplicación son inspeccionables). En lugar de un secreto de aplicación, Logto las protege con PKCE, validación estricta de URI de redirección / CORS, tokens de acceso de corta duración y rotación de tokens de actualización.
Nombre de la aplicación
Application name es el nombre legible por humanos de la aplicación y se mostrará en la consola de administración.
El Application name es un componente importante para la gestión de aplicaciones en Logto, ya que permite a los administradores identificar y rastrear fácilmente la actividad de aplicaciones individuales dentro de la plataforma.
Es importante tener en cuenta que el Application name debe elegirse cuidadosamente, ya que será visible para todos los usuarios que tengan acceso a la consola de administración. Debe reflejar con precisión el propósito y la función de la aplicación, además de ser fácil de entender y reconocer.
Descripción
Una breve descripción de la aplicación se mostrará en la página de detalles de la aplicación en la consola de administración. La descripción está destinada a proporcionar a los administradores información adicional sobre la aplicación, como su propósito, funcionalidad y cualquier otro detalle relevante.
URIs de redirección
Redirect URIs son una lista de URIs de redirección válidas que han sido preconfiguradas para una aplicación. Cuando un usuario inicia sesión en Logto e intenta acceder a la aplicación, es redirigido a uno de los URIs permitidos especificados en la configuración de la aplicación.
La lista de URIs permitidas se utiliza para validar el URI de redirección que se incluye en la solicitud de autorización enviada por la aplicación a Logto durante el proceso de autenticación. Si el URI de redirección especificado en la solicitud de autorización coincide con uno de los URIs permitidos en la configuración de la aplicación, el usuario es redirigido a ese URI tras la autenticación exitosa. Si el URI de redirección no está en la lista permitida, el usuario no será redirigido y el proceso de autenticación fallará.
Es importante asegurarse de que todos los URIs de redirección válidos se agreguen a la lista permitida para una aplicación en Logto, para garantizar que los usuarios puedan acceder correctamente a la aplicación después de la autenticación.
Puedes consultar el Redirection endpoint para más información.
Entendiendo los URIs de redirección en OIDC con Authorization Code Flow
Patrones comodín
Disponibilidad: Aplicación de una sola página, aplicación web tradicional
Los URIs de redirección admiten patrones comodín (*) para entornos dinámicos como despliegues de vista previa. Los comodines pueden usarse en los componentes de nombre de host y ruta de los URIs HTTP / HTTPS.
Reglas:
- Los comodines solo están permitidos en el nombre de host y la ruta
- Los comodines no están permitidos en el esquema, puerto, parámetros de consulta o fragmentos hash
- Los comodines en el nombre de host deben incluir al menos un punto (por ejemplo,
https://*.example.com/callback)
Ejemplos:
https://*.example.com/callback- coincide con cualquier subdominiohttps://preview-*.example.com/callback- coincide con despliegues de vista previahttps://example.com/*/callback- coincide con cualquier segmento de ruta
Los URIs de redirección comodín no son estándar OIDC y pueden aumentar la superficie de ataque. Úsalos con precaución y prefiere URIs de redirección exactos siempre que sea posible.
URIs de redirección post cierre de sesión
Post sign-out redirect URIs son una lista de URIs válidas que han sido preconfiguradas para una aplicación para redirigir al usuario después de que haya cerrado sesión en Logto.
El uso de Post Sign-out Redirect URIs permitidos para el cierre de sesión es parte de la especificación de Logout iniciado por la parte confiable (RP-Initiated Logout) en OIDC. Esta especificación proporciona un método estandarizado para que las aplicaciones inicien una solicitud de cierre de sesión para un usuario, que incluye redirigir al usuario a un endpoint preconfigurado después de que haya cerrado sesión.
Cuando un usuario cierra sesión en Logto, su sesión se termina y es redirigido a uno de los URIs permitidos especificados en la configuración de la aplicación. Esto garantiza que el usuario solo sea dirigido a endpoints autorizados y válidos después de cerrar sesión, ayudando a prevenir accesos no autorizados y riesgos de seguridad asociados con redirigir usuarios a endpoints desconocidos o no verificados.
Puedes consultar el RP-initiated logout para más información.
Orígenes permitidos por CORS
Los orígenes permitidos por CORS (Cross-origin resource sharing) son una lista de orígenes permitidos desde los cuales una aplicación puede realizar solicitudes al servicio Logto. Cualquier origen que no esté incluido en la lista permitida no podrá realizar solicitudes al servicio Logto.
La lista de orígenes permitidos por CORS se utiliza para restringir el acceso al servicio Logto desde dominios no autorizados y para ayudar a prevenir ataques de falsificación de solicitudes entre sitios (CSRF). Al especificar los orígenes permitidos para una aplicación en Logto, el servicio puede garantizar que solo los dominios autorizados puedan realizar solicitudes al servicio.
La lista de orígenes permitidos debe contener el origen donde se servirá la aplicación. Esto garantiza que las solicitudes de la aplicación estén permitidas, mientras que las solicitudes de orígenes no autorizados sean bloqueadas.
Endpoint de configuración del proveedor OpenID
El endpoint para OpenID Connect Discovery.
Endpoint de autorización
Authorization Endpoint es un término de OIDC, y es un endpoint requerido que se utiliza para iniciar el proceso de autenticación de un usuario. Cuando un usuario intenta acceder a un recurso protegido o una aplicación que ha sido registrada en la plataforma Logto, será redirigido al Authorization Endpoint para autenticar su identidad y obtener autorización para acceder al recurso solicitado.
Puedes consultar el Authorization Endpoint para más información.
Endpoint de token
Token Endpoint es un término de OIDC, es un endpoint de API web que utiliza un cliente OIDC para obtener un token de acceso, un token de ID o un token de actualización de un proveedor OIDC.
Cuando un cliente OIDC necesita obtener un token de acceso o un token de ID, envía una solicitud al Token Endpoint con una concesión de autorización, que normalmente es un código de autorización o un token de actualización. El Token Endpoint valida la concesión de autorización y emite un token de acceso o un token de ID al cliente si la concesión es válida.
Puedes consultar el Token Endpoint para más información.
Endpoint de Userinfo
El UserInfo Endpoint de OpenID Connect.
Emitir siempre token de actualización
Disponibilidad: Web tradicional, SPA
Cuando está habilitado, Logto siempre emitirá tokens de actualización, independientemente de si prompt=consent está presente en la solicitud de autenticación, o si offline_access está presente en los alcances.
Sin embargo, esta práctica no se recomienda a menos que sea necesario (normalmente es útil para algunas integraciones OAuth de terceros que requieren token de actualización), ya que no es compatible con OpenID Connect y puede causar problemas potenciales.
Rotar token de actualización
Predeterminado: true
Cuando está habilitado, Logto puede emitir un nuevo token de actualización cuando un cliente utiliza un token de actualización para solicitar nuevos tokens. Si el token de actualización y su concesión de aplicación siguen siendo válidos, la política de rotación predeterminada es:
- Los tokens de actualización solo pueden rotarse antes de que la cadena de tokens de actualización haya existido durante un año. Este es un límite de seguridad interno para la rotación; el TTL propio del token de actualización o el TTL de la concesión de la aplicación pueden expirar antes. Una vez alcanzado el límite, Logto ya no rota el token de actualización y la expiración del token de actualización actual es definitiva.
- Para clientes públicos que no utilizan tokens de actualización restringidos al remitente (por ejemplo, aplicaciones nativas regulares y aplicaciones de una sola página), Logto rota el token de actualización en cada solicitud de token de actualización mientras la rotación esté permitida.
- Para otros clientes, Logto rota el token de actualización solo cuando está cerca de expirar (>=70% de su Tiempo de Vida (TTL) original ha pasado).
Para clientes públicos, se recomienda encarecidamente mantener habilitada la rotación de tokens de actualización por razones de seguridad.
Los tokens de actualización restringidos al remitente están vinculados a una clave de prueba o certificado en poder del cliente. Para SPA regulares, la rotación emite un nuevo token de actualización pero no extiende la vida útil del token de actualización. El nuevo token de actualización hereda el TTL restante del token de actualización anterior.
Los tokens de actualización están asociados a una concesión de aplicación. El TTL predeterminado de la concesión en Logto es 180 días. Cuando la concesión expira, las solicitudes de token de actualización fallan y el token de actualización ya no puede usarse para obtener nuevos tokens, incluso si la rotación de tokens de actualización está habilitada.
Esto significa que la vida útil máxima práctica de una autorización respaldada por token de actualización está actualmente limitada por el TTL de la concesión, la revocación explícita o la expiración propia del token de actualización, lo que ocurra primero.
Entendiendo la rotación de tokens de actualización
Tiempo de vida (TTL) del token de actualización en días
Disponibilidad: Aplicación nativa, Web tradicional, SPA; Predeterminado: 14 días; Máximo: 180 días
La duración durante la cual un token de actualización puede usarse para solicitar nuevos tokens de acceso antes de que expire y se vuelva inválido. Las solicitudes de token extenderán el TTL del token de actualización a este valor.
Normalmente, se prefiere un valor más bajo.
La actualización del TTL no está disponible en aplicaciones de una sola página (SPA) por razones de seguridad. Para las SPA, esta configuración controla la vida útil fija del token de actualización desde el momento de su emisión original. Logto no extenderá el TTL mediante solicitudes de token, y la rotación de tokens de actualización no evita que los tokens de actualización de SPA expiren.
El TTL del token de actualización no es el único límite de expiración. Los tokens de actualización están vinculados a una concesión de aplicación, y el TTL predeterminado de la concesión en Logto es 180 días. Cuando la concesión expira, las solicitudes de token de actualización fallan incluso si el token de actualización aún sería válido.
Para los clientes donde las solicitudes de token actualizan el TTL del token de actualización, el TTL de la concesión actúa como la vida útil máxima absoluta para la cadena de tokens de actualización. Para las SPA, el TTL fijo del token de actualización puede expirar antes que la concesión.
Cuando se emite un token de actualización sin el alcance offline_access en la solicitud de autorización, estará vinculado a la sesión del usuario. La sesión tiene un TTL fijo de 14 días. Después de que la sesión expire, el token de actualización se vuelve inválido independientemente de su propia configuración de TTL.
Para garantizar que la configuración de TTL del token de actualización tenga efecto completo, asegúrate de incluir el alcance offline_access en tu solicitud de autorización.
URI de cierre de sesión backchannel
El endpoint de cierre de sesión backchannel de OpenID Connect. Consulta Cierre de sesión federado: Back-channel logout para más información.
Máximo de concesiones permitidas (maxAllowedGrants)
maxAllowedGrants es un campo opcional a nivel de aplicación bajo customClientMetadata que controla el número máximo de concesiones activas concurrentes por usuario para la aplicación actual.
- Predeterminado:
undefined(sin límite) - Cuando se configura: En cada autorización exitosa, Logto verifica el total de concesiones activas para el usuario en la aplicación actual (a través de navegadores y dispositivos). Si se supera el límite, Logto revoca las concesiones más antiguas.
Esta configuración es útil cuando deseas limitar los dispositivos autenticados concurrentes por aplicación.
Este campo no es compatible con:
- Aplicaciones máquina a máquina
- Aplicaciones protegidas
- Aplicaciones SAML
Datos personalizados
Información adicional personalizada de la aplicación no listada en las propiedades predefinidas de la aplicación; los usuarios pueden definir sus propios campos de datos personalizados según sus necesidades específicas, como configuraciones y ajustes específicos del negocio.