Descripción general
InsForge puede funcionar como proveedor de identidad OAuth 2.0, permitiendo que aplicaciones de terceros autentiquen usuarios mediante “Sign in with InsForge”. Esto permite que los desarrolladores que construyen sobre tu plataforma aprovechen el sistema de autenticación de InsForge sin tener que gestionar sus propias credenciales de usuario.Casos de uso
Plataformas para desarrolladores
Permite que desarrolladores externos creen integraciones con “Sign in with InsForge”, mientras mantienes el control sobre el acceso a los datos de los usuarios.
Agentes de IA y MCP
Autentica agentes de IA y herramientas LLM a través de Model Context Protocol con autorización basada en OAuth.
Aplicaciones de socios
Permite que las aplicaciones de socios autentiquen usuarios contra tu proyecto de InsForge sin compartir credenciales.
CLI y aplicaciones de escritorio
Emite tokens OAuth para herramientas de línea de comandos y aplicaciones de escritorio que necesitan acceso a la API.
Flujo de OAuth 2.0
InsForge implementa el flujo de código de autorización con PKCE (Proof Key for Code Exchange), el flujo OAuth más seguro tanto para aplicaciones web como nativas.Primeros pasos
Registra tu aplicación
Contacta a InsForge para registrar tu aplicación como un cliente OAuth. Recibirás:
- Client ID: Identificador público de tu aplicación
- Client Secret: Clave confidencial para el intercambio de tokens del lado del servidor
- Allowed Redirect URIs: URLs a las que se puede redirigir a los usuarios después de la autorización
Configura los scopes
Define los permisos que necesita tu aplicación:
| Scope | Descripción |
|---|---|
user:read | Lee la información del perfil del usuario |
organizations:read | Lista las organizaciones del usuario |
projects:read | Lee los metadatos del proyecto |
projects:write | Crea y modifica proyectos |
Endpoints
Endpoint de autorización
Redirige a los usuarios a este endpoint para iniciar el flujo de OAuth.| Parámetro | Obligatorio | Descripción |
|---|---|---|
client_id | Sí | El client ID de tu aplicación |
redirect_uri | Sí | URL a la que redirigir tras la autorización (debe estar registrada previamente) |
response_type | Sí | Debe ser code |
scope | Sí | Lista de scopes separados por espacios |
state | Sí | Cadena aleatoria para protección CSRF |
code_challenge | Sí | Code challenge de PKCE (hash SHA256 codificado en base64url) |
code_challenge_method | Sí | Debe ser S256 |
Endpoint de token
Intercambia el código de autorización por tokens de acceso y de actualización.Token de actualización
Intercambia un refresh token por un nuevo token de acceso.Endpoint de perfil de usuario
Recupera la información del perfil del usuario autenticado.Guía de implementación
Genera los parámetros de PKCE
PKCE añade una capa adicional de seguridad al garantizar que la aplicación que inició el flujo sea la misma que lo completa.- Node.js
- Python
Ejemplo completo del lado del servidor
Aquí tienes una implementación completa con Express.js. Primero, crea un archivo.env con tus credenciales:
Genera un secreto de sesión seguro usando:
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"Modo popup para SPAs
En aplicaciones de una sola página, puedes abrir el flujo de OAuth en una ventana emergente:Consideraciones de seguridad
Usa siempre PKCE
PKCE es obligatorio en todos los flujos de OAuth. Evita los ataques de interceptación del código de autorización.
Valida el state
Verifica siempre el parámetro state en los callbacks para prevenir ataques CSRF.
Almacenamiento seguro de tokens
Almacena los tokens de acceso en memoria o en cookies httpOnly seguras. Nunca expongas los tokens en URLs o en localStorage.
Usa HTTPS
Todos los endpoints de OAuth requieren HTTPS en producción. Nunca transmitas tokens por conexiones sin cifrar.
Expiración corta de los tokens
Los tokens de acceso expiran en 1 hora. Usa refresh tokens para obtener nuevos tokens de acceso sin volver a autenticarte.
Minimización de scopes
Solicita solo los scopes que tu aplicación necesita. Los usuarios tienden a aprobar más fácilmente permisos limitados.
Claims del token
Los tokens de acceso son JWTs que contienen los siguientes claims:| Claim | Descripción |
|---|---|
sub | ID del usuario (UUID) |
email | Dirección de correo electrónico del usuario |
role | Rol del usuario (authenticated) |
client_id | ID de cliente OAuth que solicitó el token |
scope | Scopes concedidos |
iat | Marca de tiempo de emisión |
exp | Marca de tiempo de expiración |
iss | Emisor (insforge) |
aud | Audiencia (insforge-api) |
Manejo de errores
Errores de autorización
Si la autorización falla, los usuarios son redirigidos a turedirect_uri con parámetros de error:
| Error | Descripción |
|---|---|
invalid_request | Parámetros faltantes o no válidos |
unauthorized_client | El cliente no está autorizado para este tipo de concesión |
access_denied | El usuario denegó la solicitud de autorización |
invalid_scope | El scope solicitado no es válido o es desconocido |
Errores de token
Los errores del endpoint de token se devuelven en formato JSON:| Error | Descripción |
|---|---|
invalid_grant | El código expiró, ya se usó, o el verifier no coincide |
invalid_client | Falló la autenticación del cliente |
invalid_request | Faltan parámetros requeridos |
Límites de tasa
Los endpoints de OAuth tienen límite de tasa para prevenir abusos:| Endpoint | Límite |
|---|---|
/authorize | 100 solicitudes por minuto por IP |
/token | 50 solicitudes por minuto por cliente |
/profile | 100 solicitudes por minuto por token |
Recursos
Repositorio de ejemplo de OAuth
Ejemplo completo y funcional que muestra cómo integrar “Sign in with InsForge” en tu aplicación.