Cómo construir el inicio de sesión de SAML con Extensión de Chrome

Para nuestros nuevos amigos:

Logto es una alternativa a Auth0 diseñada para aplicaciones modernas y productos SaaS. Ofrece servicios tanto de Cloud como de código abierto para ayudarte a lanzar rápidamente tu sistema de gestión e identidad (IAM). Disfruta de autenticación, autorización y gestión multi-tenant todo en uno.

Recomendamos comenzar con un tenant de desarrollo gratuito en Logto Cloud. Esto te permite explorar todas las características fácilmente.

En este artículo, repasaremos los pasos para construir rápidamente la experiencia de inicio de sesión de SAML (autenticación de usuario) con Extensión de Chrome y Logto.

Requisitos previos

Una instancia de Logto en funcionamiento. Consulta la página de introducción para comenzar.
Conocimientos básicos de Extensión de Chrome.
Una cuenta de SAML utilizable.

Crear una aplicación en Logto

Logto se basa en la autenticación OpenID Connect (OIDC) y la autorización OAuth 2.0. Admite la gestión de identidad federada a través de múltiples aplicaciones, comúnmente llamada inicio de sesión único (SSO).

Para crear tu aplicación Aplicación de una sola página, simplemente sigue estos pasos:

Abre la Consola de Logto. En la sección "Comenzar", haz clic en el enlace "Ver todo" para abrir la lista de marcos de aplicaciones. Alternativamente, puedes navegar a Consola de Logto > Aplicaciones, y hacer clic en el botón "Crear aplicación".
En el modal que se abre, haz clic en la sección "Aplicación de una sola página" o filtra todos los marcos "Aplicación de una sola página" disponibles usando las casillas de filtro rápido a la izquierda. Haz clic en la tarjeta del marco "Extensión de Chrome" para comenzar a crear tu aplicación.
Ingresa el nombre de la aplicación, por ejemplo, "Librería", y haz clic en "Crear aplicación".

🎉 ¡Ta-da! Acabas de crear tu primera aplicación en Logto. Verás una página de felicitaciones que incluye una guía de integración detallada. Sigue la guía para ver cómo será la experiencia en tu aplicación.

Integrar el SDK de Extensión de Chrome

tip:

La siguiente demostración fue probada en Chrome v123.0.6312.87 (arm64). Otras versiones también deberían funcionar, siempre que admitan las APIs de chrome utilizadas en el SDK.
El proyecto de ejemplo está disponible en nuestro repositorio de GitHub.

Instalación

npm
Yarn
pnpm

npm i @logto/chrome-extension

yarn add @logto/chrome-extension

pnpm add @logto/chrome-extension

El flujo de autenticación

Suponiendo que pongas un botón de "Iniciar sesión" en el popup de tu extensión de Chrome, el flujo de autenticación se verá así:

Para otras páginas interactivas en tu extensión, solo necesitas reemplazar el participante Popup de la extensión con el nombre de la página. En este tutorial, nos centraremos en la página del popup.

Este proceso de autenticación sigue el protocolo OpenID Connect (OIDC), y Logto aplica medidas de seguridad estrictas para proteger el inicio de sesión del usuario.
Si tienes múltiples aplicaciones, puedes usar el mismo proveedor de identidad (Logto). Una vez que el usuario inicia sesión en una aplicación, Logto completará automáticamente el proceso de inicio de sesión cuando el usuario acceda a otra aplicación.

Para aprender más sobre la lógica y los beneficios del inicio de sesión basado en redirección, consulta Experiencia de inicio de sesión de Logto explicada.

Actualiza el `manifest.json`

El SDK de Logto requiere los siguientes permisos en el manifest.json:

manifest.json
{
  "permissions": ["identity", "storage"],
  "host_permissions": ["https://*.logto.app/*"]
}

permissions.identity: Requerido para la API de Identidad de Chrome, que se utiliza para iniciar y cerrar sesión.
permissions.storage: Requerido para almacenar la sesión del usuario.
host_permissions: Requerido para que el SDK de Logto se comunique con las APIs de Logto.

nota:

Si estás utilizando un dominio personalizado en Logto Cloud, necesitas actualizar los host_permissions para que coincidan con tu dominio.

Configura un script de fondo (service worker)

En el script de fondo de tu extensión de Chrome, inicializa el SDK de Logto:

service-worker.js
import LogtoClient from '@logto/chrome-extension';

export const logtoClient = new LogtoClient({
  endpoint: '<your-logto-endpoint>'
  appId: '<your-logto-app-id>',
});

Reemplaza <your-logto-endpoint> y <your-logto-app-id> con los valores reales. Puedes encontrar estos valores en la página de la aplicación que acabas de crear en la Logto Console.

Si no tienes un script de fondo, puedes seguir la guía oficial para crear uno.

info:

¿Por qué necesitamos un script de fondo?

Las páginas normales de la extensión, como el popup o la página de opciones, no pueden ejecutarse en segundo plano y pueden cerrarse durante el proceso de autenticación. Un script de fondo asegura que el proceso de autenticación se maneje adecuadamente.

Luego, necesitamos escuchar el mensaje de otras páginas de la extensión y manejar el proceso de autenticación:

service-worker.js
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  // En el código a continuación, dado que devolvemos `true` para cada acción, necesitamos llamar a `sendResponse`
  // para notificar al remitente. También puedes manejar errores aquí, o usar otras formas de notificar al remitente.

  if (message.action === 'signIn') {
    const redirectUri = chrome.identity.getRedirectURL('/callback');
    logtoClient.signIn(redirectUri).finally(sendResponse);
    return true;
  }

  if (message.action === 'signOut') {
    const redirectUri = chrome.identity.getRedirectURL();
    logtoClient.signOut(redirectUri).finally(sendResponse);
    return true;
  }

  return false;
});

Puedes notar que hay dos URIs de redirección utilizados en el código anterior. Ambos son creados por chrome.identity.getRedirectURL, que es una API integrada de Chrome para generar una URL de redirección para flujos de autenticación. Los dos URIs serán:

https://<extension-id>.chromiumapp.org/callback para iniciar sesión.
https://<extension-id>.chromiumapp.org/ para cerrar sesión.

Ten en cuenta que estos URIs no son accesibles y solo se utilizan para que Chrome desencadene acciones específicas para el proceso de autenticación.

Actualiza la configuración de la aplicación Logto

Ahora necesitamos actualizar la configuración de la aplicación Logto para permitir los URIs de redirección que acabamos de crear.

Ve a la página de la aplicación en la Logto Console.
En la sección "Redirect URIs", agrega el URI: https://<extension-id>.chromiumapp.org/callback.
En la sección "Post sign-out redirect URIs", agrega el URI: https://<extension-id>.chromiumapp.org/.
En la sección "CORS allowed origins", agrega el URI: chrome-extension://<extension-id>. El SDK en la extensión de Chrome usará este origen para comunicarse con las APIs de Logto.
Haz clic en Guardar cambios.

Recuerda reemplazar <extension-id> con tu ID de extensión real. Puedes encontrar el ID de la extensión en la página chrome://extensions.

¡Ya casi estamos! Vamos a añadir los botones de inicio y cierre de sesión y otra lógica necesaria a la página del popup.

En el archivo popup.html:

popup.html
<button id="sign-in">Iniciar sesión</button> <button id="sign-out">Cerrar sesión</button>

En el archivo popup.js (suponiendo que popup.js está incluido en el popup.html):

popup.js
document.getElementById('sign-in').addEventListener('click', async () => {
  await chrome.runtime.sendMessage({ action: 'signIn' });
  // Inicio de sesión completado (o fallido), puedes actualizar la UI aquí.
});

document.getElementById('sign-out').addEventListener('click', async () => {
  await chrome.runtime.sendMessage({ action: 'signOut' });
  // Cierre de sesión completado (o fallido), puedes actualizar la UI aquí.
});

Punto de control: Prueba el flujo de autenticación

Ahora puedes probar el flujo de autenticación en tu extensión de Chrome:

Abre el popup de la extensión.
Haz clic en el botón "Iniciar sesión".
Serás redirigido a la página de inicio de sesión de Logto.
Inicia sesión con tu cuenta de Logto.
Serás redirigido de vuelta a Chrome.

Verifica el estado de autenticación

Dado que Chrome proporciona APIs de almacenamiento unificadas, además del flujo de inicio y cierre de sesión, todos los demás métodos del SDK de Logto pueden usarse directamente en la página del popup.

En tu popup.js, puedes reutilizar la instancia de LogtoClient creada en el script de fondo, o crear una nueva con la misma configuración:

popup.js
import LogtoClient from '@logto/chrome-extension';

const logtoClient = new LogtoClient({
  endpoint: '<your-logto-endpoint>'
  appId: '<your-logto-app-id>',
});

// O reutiliza la instancia de logtoClient creada en el script de fondo
import { logtoClient } from './service-worker.js';

Luego puedes crear una función para cargar el estado de autenticación y el perfil del usuario:

popup.js
const loadAuthenticationState = async () => {
  const isAuthenticated = await logtoClient.isAuthenticated();
  // Actualiza la UI basado en el estado de autenticación

  if (isAuthenticated) {
    const user = await logtoClient.getIdTokenClaims(); // { sub: '...', email: '...', ... }
    // Actualiza la UI con el perfil del usuario
  }
};

También puedes combinar la función loadAuthenticationState con la lógica de inicio y cierre de sesión:

popup.js
document.getElementById('sign-in').addEventListener('click', async () => {
  await chrome.runtime.sendMessage({ action: 'signIn' });
  await loadAuthenticationState();
});

document.getElementById('sign-out').addEventListener('click', async () => {
  await chrome.runtime.sendMessage({ action: 'signOut' });
  await loadAuthenticationState();
});

Aquí tienes un ejemplo de la página del popup con el estado de autenticación:

Otras consideraciones

Empaquetado del service worker: Si usas un empaquetador como Webpack o Rollup, necesitas establecer explícitamente el objetivo a browser o similar para evitar el empaquetado innecesario de módulos de Node.js.
Resolución de módulos: El SDK de extensión de Chrome de Logto es un módulo solo ESM.

Consulta nuestro proyecto de ejemplo para un ejemplo completo con TypeScript, Rollup y otras configuraciones.

Añadir el conector SAML

Para habilitar un inicio de sesión rápido y mejorar la conversión de usuarios, conéctate con Extensión de Chrome como un proveedor de identidad (IdP). El conector social de Logto te ayuda a establecer esta conexión en minutos permitiendo la entrada de varios parámetros.

Para añadir un conector social, simplemente sigue estos pasos:

Navega a Console > Connectors > Social Connectors.
Haz clic en "Add social connector" y selecciona "SAML".
Sigue la guía README y completa los campos requeridos y personaliza la configuración.

nota:

Si estás siguiendo la guía del Conector en el lugar, puedes omitir la siguiente sección.

Configura Aplicación SAML estándar

Vamos a revisar las configuraciones del conector SAML.

Antes de comenzar, puedes ir a un proveedor de identidad social que soporte el protocolo SAML y crear tu propia cuenta. Okta, OneLogin, Salesforce y algunas otras plataformas soportan autenticación basada en el protocolo SAML.

Si tu IdP requiere el cifrado de la aserción SAML y la recepción de solicitudes de autenticación firmadas, debes generar tu clave privada y el certificado correspondiente usando el algoritmo RSA. Guarda la clave privada para el uso de tu SP y sube el certificado al IdP.

También necesitas configurar la URL de ACS (Assertion Consumer Service) como ${your_logto_origin}/api/authn/saml/${connector_id} para manejar la aserción SAML del IdP. Puedes encontrar tu connectorId en la página de detalles del conector SAML en la Consola de Administración de Logto.

nota:

Según el diseño actual de Logto, solo soportamos Redirect-binding para enviar solicitudes de autenticación y POST-binding para recibir aserciones SAML. Aunque esto no suena muy bien, creemos que el diseño actual puede manejar la mayoría de tus casos de uso. Si tienes algún problema, ¡no dudes en contactarnos!

Configurar el conector SAML (SP)

En esta sección, presentaremos cada atributo en detalle.

entityID `Requerido`

entityID (es decir, issuer) es el identificador de la entidad. Se utiliza para identificar tu entidad (entidad SAML SP) y hacer coincidir la equivalencia en cada solicitud/respuesta SAML.

signInEndpoint `Requerido`

El endpoint del IdP al que envías solicitudes de autenticación SAML. Por lo general, puedes encontrar este valor en la página de detalles del IdP (es decir, SSO URL o Login URL del IdP).

x509Certificate `Requerido`

El certificado x509 generado a partir de la clave privada del IdP, se espera que el IdP tenga este valor disponible.

El contenido del certificado viene con el encabezado -----BEGIN CERTIFICATE----- y el final -----END CERTIFICATE-----.

idpMetadataXml `Requerido`

El campo se utiliza para colocar contenidos de tu archivo XML de metadatos del IdP.

nota:

El analizador XML que estamos usando no soporta espacios de nombres personalizados. Si los metadatos del IdP vienen con espacio de nombres, debes eliminarlos manualmente. Para el espacio de nombres del archivo XML, consulta referencia.

assertionConsumerServiceUrl `Requerido`

La URL del servicio consumidor de aserciones (ACS) es el endpoint del SP para recibir solicitudes POST de aserciones SAML del IdP. Como mencionamos en la parte anterior, generalmente se configura en la configuración del IdP, pero algunos IdP obtienen este valor de las solicitudes de autenticación SAML, por lo que también agregamos este valor como un campo REQUERIDO. Su valor debería verse como ${your_logto_origin}/api/authn/saml/${connector_id}.

signAuthnRequest

El valor booleano que controla si la solicitud de autenticación SAML debe estar firmada, cuyo valor predeterminado es false.

encryptAssertion

encryptAssertion es un valor booleano que indica si el IdP cifrará la aserción SAML, con un valor predeterminado de false.

nota:

Los atributos signAuthnRequest y encryptAssertion deben alinearse con los parámetros correspondientes de la configuración del IdP, de lo contrario se lanzará un error para mostrar que la configuración no coincide. Todas las respuestas SAML deben estar firmadas.

requestSignatureAlgorithm

Esto debe alinearse con los algoritmos de firma del IdP para que Logto pueda verificar la firma de la aserción SAML. Su valor debe ser http://www.w3.org/2000/09/xmldsig#rsa-sha1, http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 o http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 y el valor predeterminado es http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.

messageSigningOrder

messageSigningOrder indica el orden de firma y cifrado del IdP, su valor debe ser sign-then-encrypt o encrypt-then-sign y el valor predeterminado es sign-then-encrypt.

privateKey y privateKeyPass

privateKey es un valor OPCIONAL y es requerido cuando signAuthnRequest es true.

privateKeyPass es la contraseña que has establecido al crear privateKey, requerida cuando sea necesario.

Si signAuthnRequest es true, el certificado correspondiente generado a partir de privateKey es requerido por el IdP para verificar la firma.

encPrivateKey y encPrivateKeyPass

encPrivateKey es un valor OPCIONAL y es requerido cuando encryptAssertion es true.

encPrivateKeyPass es la contraseña que has establecido al crear encPrivateKey, requerida cuando sea necesario.

Si encryptAssertion es true, el certificado correspondiente generado a partir de encPrivateKey es requerido por el IdP para cifrar la aserción SAML.

nota:

Para la generación de claves y certificados, openssl es una herramienta maravillosa. Aquí hay una línea de comando de ejemplo que podría ser útil:

openssl genrsa -passout pass:${privateKeyPassword} -out ${encryptPrivateKeyFilename}.pem 4096
openssl req -new -x509 -key ${encryptPrivateKeyFilename}.pem -out ${encryptionCertificateFilename}.cer -days 3650

Los archivos privateKey y encPrivateKey deben estar codificados en el esquema pkcs1 como cadena pem, lo que significa que los archivos de clave privada deben comenzar con -----BEGIN RSA PRIVATE KEY----- y terminar con -----END RSA PRIVATE KEY-----.

nameIDFormat

nameIDFormat es un atributo OPCIONAL que declara el formato de identificación de nombre que respondería. El valor puede ser urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName, urn:oasis:names:tc:SAML:2.0:nameid-format:persistent y urn:oasis:names:tc:SAML:2.0:nameid-format:transient, y el valor predeterminado es urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified.

timeout

timeout es la tolerancia de tiempo para la validación de tiempo, ya que el tiempo entre tu entidad SP y la entidad IdP podría ser diferente y la conexión de red también puede traer algún retraso. La unidad es en milisegundos, y el valor predeterminado es 5000 (es decir, 5s).

profileMap

Logto también proporciona un campo profileMap que los usuarios pueden personalizar el mapeo desde los perfiles de los proveedores sociales que generalmente no son estándar. Cada clave de profileMap es el nombre del campo de perfil de usuario estándar de Logto y el valor correspondiente debe ser el nombre del campo de perfil social. En la etapa actual, Logto solo se preocupa por 'id', 'name', 'avatar', 'email' y 'phone' del perfil social, solo 'id' es REQUERIDO y los demás son campos opcionales.

Tipos de configuración

Nombre	Tipo	Requerido	Valor predeterminado
signInEndpoint	string	true
x509certificate	string	true
idpMetadataXml	string	true
entityID	string	true
assertionConsumerServiceUrl	string	true
messageSigningOrder	`encrypt-then-sign` \| `sign-then-encrypt`	false	`sign-then-encrypt`
requestSignatureAlgorithm	`http://www.w3.org/2000/09/xmldsig#rsa-sha1` \| `http://www.w3.org/2001/04/xmldsig-more#rsa-sha256` \| `http://www.w3.org/2001/04/xmldsig-more#rsa-sha512`	false	`http://www.w3.org/2001/04/xmldsig-more#rsa-sha256`
signAuthnRequest	boolean	false	false
encryptAssertion	boolean	false	false
privateKey	string	false
privateKeyPass	string	false
nameIDFormat	`urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified` \| `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` \| `urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName` \| `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` \| `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`	false	`urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`
timeout	number	false	5000
profileMap	ProfileMap	false

Campos de ProfileMap	Tipo	Requerido	Valor predeterminado
id	string	false	id
name	string	false	name
avatar	string	false	avatar
email	string	false	email
phone	string	false	phone

Referencia

Guarda tu configuración

Verifica que hayas completado los valores necesarios en el área de configuración del conector Logto. Haz clic en "Guardar y listo" (o "Guardar cambios") y el conector SAML debería estar disponible ahora.

Una vez que crees un conector social con éxito, puedes habilitarlo como un botón "Continuar con SAML" en la Experiencia de inicio de sesión.

Navega a Consola > Experiencia de inicio de sesión > Registro e inicio de sesión.
(Opcional) Elige "No aplicable" para el identificador de registro si solo necesitas inicio de sesión social.
Añade el conector SAML configurado a la sección "Inicio de sesión social".

Pestaña de Experiencia de inicio de sesión

Pruebas y Validación

Regresa a tu aplicación Extensión de Chrome. Ahora deberías poder iniciar sesión con SAML. ¡Disfruta!

Lecturas adicionales

Flujos de usuario final: Logto proporciona flujos de autenticación listos para usar, incluyendo MFA y SSO empresarial, junto con potentes APIs para la implementación flexible de configuraciones de cuenta, verificación de seguridad y experiencia multi-tenant.

Autorización (Authorization): La autorización define las acciones que un usuario puede realizar o los recursos a los que puede acceder después de ser autenticado. Explora cómo proteger tu API para aplicaciones nativas y de una sola página e implementar el Control de Acceso Basado en Roles (RBAC).

Organizaciones (Organizations): Particularmente efectivo en aplicaciones SaaS multi-tenant y B2B, la función de organización permite la creación de inquilinos, gestión de miembros, RBAC a nivel de organización y aprovisionamiento justo a tiempo.

Serie IAM del cliente: Nuestros artículos de blog en serie sobre la Gestión de Identidad y Acceso del Cliente (o Consumidor), desde los conceptos básicos hasta temas avanzados y más allá.

Crear una aplicación en Logto​

Integrar el SDK de Extensión de Chrome​

Instalación​

El flujo de autenticación​

Sobre el inicio de sesión basado en redirección​

Actualiza el manifest.json​

Configura un script de fondo (service worker)​

Actualiza la configuración de la aplicación Logto​

Añade botones de inicio y cierre de sesión al popup​

Punto de control: Prueba el flujo de autenticación​

Verifica el estado de autenticación​

Otras consideraciones​

Añadir el conector SAML​

Configura Aplicación SAML estándar​

Crear cuenta de IdP social y registrar aplicación SAML (IdP)​

Configurar el conector SAML (SP)​

entityID Requerido​

signInEndpoint Requerido​

x509Certificate Requerido​

idpMetadataXml Requerido​

assertionConsumerServiceUrl Requerido​

signAuthnRequest​

encryptAssertion​

requestSignatureAlgorithm​

messageSigningOrder​

privateKey y privateKeyPass​

encPrivateKey y encPrivateKeyPass​

nameIDFormat​

timeout​

profileMap​

Tipos de configuración​

Referencia​

Guarda tu configuración​

Habilitar el conector SAML en la Experiencia de inicio de sesión​

Pruebas y Validación​

Lecturas adicionales​

Crear una aplicación en Logto

Integrar el SDK de Extensión de Chrome

Instalación

El flujo de autenticación

Sobre el inicio de sesión basado en redirección

Actualiza el `manifest.json`

Configura un script de fondo (service worker)

Actualiza la configuración de la aplicación Logto

Añade botones de inicio y cierre de sesión al popup

Punto de control: Prueba el flujo de autenticación

Verifica el estado de autenticación

Otras consideraciones

Añadir el conector SAML

Configura Aplicación SAML estándar

Crear cuenta de IdP social y registrar aplicación SAML (IdP)

Configurar el conector SAML (SP)

entityID `Requerido`

signInEndpoint `Requerido`

x509Certificate `Requerido`

idpMetadataXml `Requerido`

assertionConsumerServiceUrl `Requerido`

signAuthnRequest

encryptAssertion

requestSignatureAlgorithm

messageSigningOrder

privateKey y privateKeyPass

encPrivateKey y encPrivateKeyPass

nameIDFormat

timeout

profileMap

Tipos de configuración

Referencia

Guarda tu configuración

Habilitar el conector SAML en la Experiencia de inicio de sesión

Pruebas y Validación

Lecturas adicionales