Lovable crea aplicaciones con un backend integrado; OIDC conecta el acceso de sus usuarios con un proveedor de identidad.
Lovable permite conectar el acceso de una aplicación con Entra ID, Okta o Keycloak mediante OIDC
El acceso OIDC se configura en el backend Cloud y está documentado para todos los planes, sujeto a las políticas del espacio. Es distinto del SSO de quienes trabajan dentro de Lovable.
Contexto esencialEl recorrido entre el usuario, su organización y la aplicación, y las decisiones que siguen correspondiendo al backend.Minimizar
Tres participantes con funciones distintas
La persona abre una aplicación, la aplicación necesita identificarla y el proveedor comprueba su cuenta. Al separar esas funciones, el usuario puede utilizar una identidad ya administrada por su organización. No significa que la aplicación reciba su contraseña corporativa para guardarla.
El proveedor devuelve información de identidad mediante un flujo definido. La aplicación debe comprobar esa respuesta y asociarla a una cuenta propia. Ese vínculo es importante para conservar correctamente las preferencias y los datos del usuario en accesos posteriores.
Qué aporta registrar el retorno
Durante la configuración se acuerda a qué dirección puede volver el proveedor. Esa dirección forma parte del contrato del acceso: no basta con que el dominio parezca correcto. Una configuración que funciona en pruebas puede necesitar un retorno diferente al publicar con otro dominio.
Por eso conviene distinguir los ajustes del proyecto, los del proveedor y la dirección utilizada por el lector. Un error en el recorrido puede impedir el acceso aunque la cuenta y su contraseña sean válidas.
Entrar no equivale a poder verlo todo
Autenticar es comprobar una identidad. Autorizar es decidir qué puede hacer. Un panel con clientes distintos necesita controles de datos aunque todos utilicen el mismo proveedor corporativo. Mostrar u ocultar un botón en la interfaz no sustituye esas reglas del backend.
Un ejemplo para preparar una integración
Para una herramienta interna, una comprobación orientativa sería entrar con una cuenta permitida y verificar qué datos conserva; después, revisar qué ocurre con otra cuenta que no deba acceder al mismo contenido. También interesa comprobar cierre de sesión y políticas del espacio. No se ha configurado aquí una aplicación Lovable: el ejemplo explica qué debe validarse además de que aparezca el botón de acceso.
Las aplicaciones que utilizan el backend Cloud de Lovable pueden incorporar un proveedor OpenID Connect, como Microsoft Entra ID, Okta, Auth0 o Keycloak. La identidad se configura en los ajustes de autenticación del proyecto y convive con otros métodos de acceso.
La documentación exige acceso de edición al proyecto y administración del proveedor para registrar la aplicación y su retorno. En espacios Business y Enterprise, la política App login methods puede impedir habilitarlo. El proveedor conserva sus reglas de contraseña, MFA y dispositivo; la aplicación recibe el perfil y el correo.
El cambio interesa a herramientas internas y productos para clientes con identidad corporativa. No debe confundirse con iniciar sesión en el propio espacio de Lovable, ni con SAML. El alta del botón provoca una compilación que consume créditos ordinarios; los inicios de sesión no consumen créditos según el changelog.
A tener en cuenta
Se requiere Lovable Cloud y configurar el proveedor. Autenticar a alguien no le concede por sí solo acceso a todos los datos de la aplicación.