Notas preliminares: este flujo está en una fase temprana de desarrollo y los detalles que aparecen a continuación pueden
cambiar.
Requisitos previos
- Lista de permitidos de callback. Todos los
callback_urlque uses deben estar en la lista de permitidos de Devin para tu integración. Cognition se encarga de configurarlo; envíanos las URL exactas con antelación. Cualquier URL que no esté en la lista será rechazada. - Outposts habilitado. La cuenta del cliente debe tener Outposts habilitado.
- Autorización de Admin. Para autorizar una conexión, se necesita un Admin de Devin con permisos de enterprise-settings y de gestión de usuario de servicio. El socio nunca necesita un token de Devin: el Admin lo autoriza desde su propia sesión del navegador.
Resumen del flujo
1. Genera un verificador y un desafío de PKCE
- Genera un
code_verifieraleatorio y de alta entropía: de 43 a 128 caracteres del alfabeto no reservado[A-Za-z0-9-._~](p. ej.,base64url(random 32 bytes)sin relleno). - Deriva el
code_challengecomo el valor base64url sin relleno del SHA-256 del verificador (PKCE “S256”):
code_verifier en el servidor (asociado con el estado que uses para correlacionar la devolución de llamada cuando se produzca). Nunca envíes el verificador al navegador: solo el desafío sale de tu backend.
2. Redirige al Admin a la página de conexión
Si el Admin no ha iniciado sesión, la página de conexión guarda estos parámetros y le pide que primero inicie sesión; luego, reanuda el proceso.
3. Admin confirma
outpost_image, si se proporciona). Cuando el Admin hace clic en Connect, Devin valida los permisos, la lista de permitidos del callback y que el nombre del outpost esté disponible, almacena un código cifrado de un solo uso (TTL de 10 minutos) y redirige de nuevo a tu app con el código de un solo uso.
Todavía no existe ningún outpost ni ningún usuario de servicio; solo se crean cuando se canjea el código (paso 5). Un código sin canjear simplemente caduca.
4. Devin redirige el código a tu URL de callback
callback_url con el código adjunto:
5. Intercambia el código entre servidores
code_verifier que almacenaste en el paso 1 y canjea el código en el endpoint de token. Esta es una solicitud de token codificada como formulario, al estilo de OAuth:
6. Recibir las credenciales
Cache-Control: no-store — no las almacenes en caché.
7. Ejecuta workers de outpost
access_token y api_base_url de forma segura y usa el token como credencial bearer para ejecutar workers de outpost en el outpost.
Manejo de errores
400:
invalid_grant como definitivo: descarta el code_verifier almacenado y reinicia el flujo desde el paso 1.
Notas de seguridad
- El token nunca pasa por el navegador. Solo se retransmite el código de un solo uso mediante la redirección; el token del usuario de servicio se devuelve únicamente en el intercambio entre servidores.
- PKCE vincula el código con tu backend. El código es inútil sin el
code_verifier, que solo está en tu backend, así que interceptar la redirección (o el código) no basta para canjearlo. - Los códigos son de un solo uso y caducan pronto. El canje consume el código de forma atómica; además, caduca a los 10 minutos.
- Las URL de callback están en la lista de permitidos. Devin solo retransmite un código a una
callback_urlque Cognition haya aprobado previamente para tu integración. - Verifica que el código corresponda al usuario solicitante. Confirma que el código devuelto a tu callback pertenece al mismo usuario que solicitó originalmente la conexión. Esto evita que un atacante engañe a un usuario para que, sin darse cuenta, vincule Devin a un sandbox controlado por el atacante.
- Mantén
outpost_namerazonable. El Admin puede anularlo; el nombre que pases es solo una sugerencia.

