Gestión de credenciales

Obtener tu primer token es solo el comienzo. Una vez que una aplicación OAuth está en producción, sus credenciales deben almacenarse de forma segura, rotarse ocasionalmente y revocarse rápidamente si algo sale mal. Esas son exactamente las preguntas que hace una revisión de seguridad. Esta página cubre los tres puntos, además de qué puede alcanzar realmente un token filtrado y qué hacer si ocurre una filtración.

Dónde debe vivir un client secret

Guárdalo en una variable de entorno o un gestor de secretos (AWS Secrets Manager, Vault, etc.), nunca en el control de versiones, y nunca en un archivo de configuración que se commitee junto con tu código.
Nunca lo incluyas dentro de una aplicación de escritorio o un cliente basado en navegador. Cualquier cosa instalada en la máquina de un usuario o servida a un navegador puede tener su binario o bundle inspeccionado, así que cualquier secreto incluido ahí debe tratarse como público desde el momento en que se publica.
Por esto exactamente el flujo Native Application no emite ningún client secret: está pensado para integraciones de escritorio y CLI que no tienen forma de mantener uno confidencial, así que se apoya en PKCE (una prueba por solicitud vinculada al código de autorización) en su lugar. El flujo Authorization Code + redirección HTTPS personalizada también usa PKCE, y permite añadir un client secret solo para clientes confidenciales cuyo manejador de redirección corre en un servidor que tú controlas. Una implementación puramente de navegador (SPA) de ese flujo debería prescindir del secreto, por la misma razón por la que el flujo Native nunca tiene uno. Consulta Primeros pasos: Elige un flujo OAuth.
Client Credentials es un flujo servidor a servidor y siempre requiere un secreto: guárdalo con las mismas reglas que cualquier otra credencial del lado del servidor.

Rotar un client secret sin tiempo de inactividad

Regenerar un secreto desde Settings → OAuth en tu aplicación lo reemplaza por completo. No existe una ventana en la que el secreto antiguo y el nuevo sean válidos al mismo tiempo: un llamador que aún presente el secreto antiguo es rechazado desde su siguiente solicitud de token o de refresco.

Eso no significa que toda solicitud en curso falle en el instante en que rotas el secreto. Un token de acceso ya emitido sigue funcionando hasta que expira su propia TTL (aproximadamente una hora, consulta Ciclo de vida del token), sin importar qué le ocurra después al secreto que lo emitió originalmente. Solo una solicitud de token nueva o un refresco necesita el nuevo secreto.

Secuencia de cambio recomendada:

Regenera el secreto.
En el mismo cambio, actualiza cada lugar donde tu integración almacena el secreto (configuración, gestor de secretos, cada instancia o worker) antes de que a alguno le toque emitir o refrescar un token.
Confirma que las nuevas solicitudes de token tienen éxito con el nuevo secreto.

Si no puedes actualizar todas las instancias de forma atómica, planifica la rotación como un despliegue coordinado en lugar de un rollout gradual: una instancia que todavía tenga el secreto antiguo fallará por completo la próxima vez que necesite un token, no recurrirá al antiguo con elegancia.

Revocar el acceso

Hay dos formas de cortar el acceso, y ambas detienen el acceso nuevo:

Revocar una autorización concreta desde Settings → Third-party access. La aplicación deja de poder refrescar u obtener tokens mediante esa autorización, sin afectar a la aplicación para nadie más.
Eliminar la aplicación OAuth desde Settings → OAuth. Esto la revoca para todos: no se pueden emitir más tokens de acceso o de refresco para ella, y su client secret deja de funcionar de la misma forma que tras una rotación. En una aplicación que usa client credentials, también desactiva al usuario de servicio de la aplicación en la misma operación.

Revocar una autorización, eliminar la aplicación y rotar su secreto no afectan a un token de acceso ya emitido: ninguna de estas acciones fuerza su expiración. Considera ese token utilizable, con sus scopes originales, hasta que expire su propia TTL. Consulta Ciclo de vida del token para ver el panorama completo de qué afecta y qué no a un token activo.

Qué puede alcanzar un token filtrado

Un token filtrado no es una filtración de toda tu organización: está limitado dos veces, siguiendo el modelo de seguridad de tres capas:

Sus scopes de OAuth (capa 1): fijados en el token al momento de emitirlo. Quitar un scope de la aplicación más tarde no reduce un token ya emitido; eso solo entra en efecto la próxima vez que el token se refresque o se reemita.
El acceso al contenido y el rol del usuario de servicio (capas 2 y 3): qué nodos (organizaciones, divisiones, sitios) puede ver el usuario de servicio del token, y qué puede hacer con ellos. A diferencia de los scopes, esto no está fijado en el token: se evalúa contra tu configuración actual cada vez que se hace una solicitud.

La conclusión práctica: cuanto más ajustada esté la aplicación y su usuario de servicio desde el principio, menos vale un token filtrado.

Después de una filtración sospechada

Trabaja esto en orden:

Rota el client secret de inmediato (Settings → OAuth → tu aplicación). Es lo más rápido que puedes hacer, y detiene de inmediato cualquier nueva solicitud de token o de refresco con el secreto antiguo.
Elimina la aplicación OAuth si no piensas seguir usándola, o sospechas que el compromiso va más allá de un secreto. En una aplicación de client credentials, esto también desactiva a su usuario de servicio, cortando por completo la emisión de nuevos tokens.
Restringe o retira el acceso al contenido del usuario de servicio. Como el acceso a contenido y rol (capas 2-3) se verifica en tiempo real en lugar de estar fijado en el token, esto reduce de inmediato lo que puede alcanzar un token filtrado que aún sea válido, incluso antes de que expire su TTL.
Trata el token como activo durante una ventana de TTL más (aproximadamente una hora). Ninguno de los pasos anteriores fuerza la expiración de un token ya emitido.
Emite nuevas credenciales (un nuevo secreto, o una nueva aplicación) y actualiza tu integración antes de reanudar el uso normal.

¿Qué sigue?

Ciclo de vida del token para TTLs, caché y comportamiento de refresco
Primeros pasos: Modelo de seguridad para ver cómo encajan scopes, acceso al contenido y roles