3LO o Secure Service Accounts en APS: elegir la identidad correcta
Para elegir entre 3LO y Secure Service Accounts hay una pregunta que conviene resolver primero: ¿la operación debe actuar por una persona o como un servicio de la organización? En Issues Manager he elegido la primera opción porque quiero conservar los permisos de quien utiliza la aplicación. Un informe nocturno que deba continuar aunque cambie la plantilla plantea otra necesidad. Esa diferencia es más útil para decidir que comparar únicamente cómo se obtiene cada token.
La comparación oficial de Autodesk sirve de base para revisar esa elección. Aquí contrasto los dos modelos y sus consecuencias de operación; la implementación de la serie utiliza 3LO. No hemos desplegado una Secure Service Account para esta prueba.
Tabla de contenidos
La primera decisión es a quién representa la aplicación
Cuando una aplicación consulta un proyecto, la API necesita algo más que saber qué programa ha enviado la petición. También importa en qué contexto actúa: el de una persona, una identidad de servicio o la propia aplicación. Esa identidad condiciona los recursos que puede consultar y las operaciones disponibles. Por eso elegir autenticación empieza antes de copiar un ejemplo de código: hay que decidir a quién representa el acceso que estás construyendo.
En el ejemplo, la aplicación interactiva puede tener usuarios de varias empresas. Cada persona debería consultar los proyectos que le corresponden. Si todas las peticiones se hicieran con la cuenta de quien instaló el servidor, la pantalla de acceso de cada usuario daría una impresión engañosa de separación. El problema se haría visible cuando alguien encontrase información que no debería ver, o cuando todos perdiesen el servicio porque cambió la autorización de aquella cuenta inicial.
Aquí ayuda separar tres comprobaciones que suelen confundirse. La autenticación establece la identidad; los scopes expresan los ámbitos de acceso solicitados al proveedor; y los permisos sobre el recurso determinan si esa identidad puede realizar la operación concreta. Un token que admite lectura no concede acceso a todos los proyectos. Del mismo modo, pertenecer a un proyecto no implica poder modificar cualquier dato de cualquier módulo. La aplicación tiene que comprobar el contexto admitido por cada endpoint y gestionar sus respuestas.
El informe nocturno plantea otra necesidad. Su finalidad puede ser representar un proceso de la organización, con un responsable y unos proyectos expresamente autorizados, sin reproducir todo lo que puede ver una persona concreta. Esa distinción facilita decidir qué accesos necesita y quién debe mantenerlos. Una identidad de servicio tampoco debería convertirse en una cuenta con permisos ilimitados por comodidad: su utilidad consiste precisamente en poder administrarla alrededor de una función conocida.
Antes de configurar OAuth, escribe la tarea en una frase: «consultar los proyectos de esta persona» o «generar el informe de la organización». Si no está claro a quién debe representar la operación, elegir el flujo no resuelve esa decisión.
3LO encaja cuando una persona trabaja con sus permisos
Con OAuth 3-legged, la persona inicia un proceso de autorización en Autodesk y permite a la aplicación actuar en su contexto. La aplicación recibe un código de autorización, lo intercambia por tokens y utiliza el access token en las llamadas admitidas. La documentación OAuth de APS describe ese intercambio. El código y los tokens cumplen funciones distintas; ninguno debería tratarse como una contraseña que se copia de una pantalla a otra.
Pensemos en una aplicación de coordinación utilizada por una arquitecta y un consultor externo. Ambos acceden a la misma web, pero no tienen por qué pertenecer a los mismos proyectos. Cada conexión Autodesk debe quedar asociada a la persona correcta dentro de la aplicación. Cuando llega una petición, el servidor recupera esa conexión y comprueba el acceso correspondiente. Conservar esta relación evita un error habitual en prototipos: que el último usuario que conecta su cuenta determine los datos que después ve todo el mundo.
La ventaja operativa de este flujo aparece cuando se necesita una nueva autorización. Si la persona está utilizando la aplicación, la interfaz puede explicarle qué ocurre y ofrecerle volver a conectar Autodesk. Aun así, la aplicación debe conservar lo que sea razonable del trabajo en curso y distinguir una cancelación de un error temporal. Pedir un nuevo login sin explicar por qué suele generar intentos repetidos que no resuelven el problema original.
La versión login-autodesk-fastapi del ejemplo de Issues Manager permite seguir el primer recorrido: consentimiento, lectura del perfil y sesión. Las consultas de proyectos se incorporan en las entregas siguientes; el login es la base para asociarlas a esa persona.
3LO también puede sostener tareas que se ejecutan después de cerrar la pantalla mientras la autorización siga siendo válida y pueda renovarse. La cuestión es si resulta aceptable que una revocación o un fallo de renovación obligue a localizar a esa persona. Una exportación ocasional solicitada por el usuario puede tolerarlo; un informe que debe estar listo cada madrugada quizá necesita otra forma de administrar su identidad. Esa dependencia operativa es más útil para decidir que la afirmación demasiado simple de que 3LO «solo funciona con el usuario delante».
Los permisos pueden cambiar durante la vida de esa conexión. Si el consultor deja de participar en un proyecto, conservar un listado obtenido ayer no garantiza que siga pudiendo acceder hoy. La aplicación debe gestionar la denegación de la API y evitar presentar datos antiguos como una autorización vigente. Esta diferencia cobra importancia cuando se añaden cachés para acelerar consultas: guardar resultados y conservar permisos son decisiones relacionadas, pero no equivalentes.
SSA permite organizar el acceso alrededor de un servicio
Las Secure Service Accounts ofrecen una identidad destinada a integraciones desatendidas. Autodesk anunció su disponibilidad general en septiembre de 2025. En lugar de depender de un consentimiento interactivo durante cada ejecución, el servicio utiliza su mecanismo de claves y aserciones firmadas para obtener los tokens necesarios. Esa firma permite acreditar la identidad configurada; la clave privada que la hace posible pasa a ser una pieza crítica de la integración.
En el informe nocturno, la identidad puede administrarse como parte del servicio: acceso a determinados proyectos, responsable técnico, procedimiento de rotación y aviso cuando algo falla. Así, una baja laboral, un cambio de funciones o la salida de una persona no deberían obligar a reconstruir una automatización alrededor de otra cuenta personal. El objetivo es que la dependencia sea visible y gestionable por la organización, con permisos coherentes con el trabajo del proceso.
Esto requiere distinguir el alta de la identidad de su autorización sobre los recursos. Crear una cuenta de servicio y obtener un token no demuestra que pueda consultar una carpeta o intervenir en una incidencia. Hay que revisar la documentación de SSA y los requisitos de la operación concreta. La disponibilidad general del servicio no convierte todas las APIs y módulos de Autodesk en compatibles con cualquier identidad. Esa comprobación debe hacerse antes de comprometer un plazo de desarrollo.
También cambia lo que hay que proteger. En un backend con SSA, la clave privada debe permanecer fuera del código compartido, de los artículos y de los registros de ejecución. Hace falta saber dónde se custodia, quién puede utilizarla y cómo sustituirla sin improvisar una parada. La nueva identidad evita organizar cada ejecución alrededor de una persona, pero no elimina las tareas de seguridad y mantenimiento. Simplemente las lleva a un lugar donde pueden planificarse.
Renovar un token y recuperar una integración son trabajos distintos
El access token tiene una duración limitada y se utiliza para acceder a la API. En un flujo que lo permita, el refresh token ofrece un medio para obtener nuevos tokens sin repetir todo el inicio de sesión. La sesión local de la aplicación es una tercera cosa: decide cuánto tiempo mantiene a una persona conectada a esa web. Estos plazos responden a decisiones diferentes. Que la sesión local siga abierta no prueba que Autodesk siga aceptando la autorización, y renovar un token no obliga a prolongar indefinidamente la sesión de la aplicación.
Supongamos que el informe nocturno falla al pedir un token nuevo. Si el problema es una interrupción de red, puede tener sentido esperar y reintentar de forma limitada. Si la autorización fue revocada, repetir la misma operación cada minuto no la recuperará. El sistema debe distinguir ambos casos y avisar al responsable con una acción comprensible. Una integración que solo guarda «error de autenticación» obliga a investigar desde cero precisamente cuando hay menos tiempo disponible.
En una aplicación multiusuario aparece otro detalle: dos peticiones pueden intentar renovar a la vez la misma conexión. El diseño debe coordinar esa actualización y conservar correctamente los tokens que devuelva el proveedor. Además de cumplir la documentación vigente, interesa probar el comportamiento bajo concurrencia. El recorrido de una única persona pulsando un botón rara vez revela los fallos de un servidor que atiende varias solicitudes al mismo tiempo.
Con SSA cambia el modo de obtener acceso, pero siguen existiendo fallos que necesitan clasificación. Una clave mal configurada, una identidad sin permisos y una API temporalmente no disponible no deberían producir el mismo diagnóstico. Los registros pueden identificar la operación, el momento y el tipo de error sin almacenar credenciales. Para quien mantiene el servicio, esa información vale más que un historial lleno de tokens y respuestas sin contexto.
La recuperación también forma parte de la experiencia del producto. Si una persona debe volver a autorizar, la interfaz debe indicarlo sin perder la relación con su cuenta local. Si el fallo corresponde al servicio, hay que evitar que cada usuario intente arreglarlo reconectando su cuenta. Explicar quién puede resolver cada problema reduce intervenciones inútiles y permite que el soporte actúe sobre la dependencia correcta.
Cómo elegir sin confundir 2LO, PKCE y facturación
2LO y PKCE aparecen a menudo en esta conversación, pero responden a preguntas distintas. OAuth 2-legged utiliza el contexto de la aplicación sin un consentimiento interactivo de usuario, para recursos y operaciones que lo admitan. PKCE protege el intercambio del código de autorización vinculándolo a un verificador de la petición original. Por tanto, PKCE no es una identidad alternativa a 3LO, y disponer de credenciales 2LO no permite sustituir el contexto de usuario que exige un endpoint.
El tipo de cliente también importa. Un backend puede custodiar secretos que una aplicación pública de escritorio o navegador no puede mantener confidenciales de la misma manera. Copiar el flujo de un servidor en un cliente público introduce un problema aunque el intercambio llegue a funcionar. Primero se elige la identidad y se comprueba la operación; después se implementa el flujo que corresponde al tipo de aplicación, con los controles de retorno y almacenamiento adecuados.
La última fila añade una condición de producto. La guía de passthrough para ISV publicada en octubre exige que la aplicación realice al menos una llamada con 3LO y no admite aplicaciones puramente 2LO o SSA. Esto no significa que obtener un token 3LO active por sí solo la facturación al cliente: hay requisitos de alta y de contexto de consumo. El artículo sobre passthrough billing desarrolla esa decisión sin mezclarla con los permisos sobre los datos.
En Issues Manager he mantenido 3LO porque la herramienta actúa por la persona conectada. Una tarea de organización que deba sobrevivir a la salida de una persona plantea estudiar SSA y comprobar primero que las APIs y los recursos necesarios la admiten. Automatizar el horario de una tarea no cambia por sí solo la identidad que necesita.
La elección queda incompleta hasta decidir quién recupera el acceso cuando falla. Con 3LO habrá casos que requieran volver a pedir autorización a la persona; con SSA habrá que mantener las claves y los permisos del servicio. Ese trabajo de operación también forma parte de la solución.
Respuestas