Los entornos autohospedados están en versión beta pública en planes Team y Enterprise; un Propietario los habilita activando Allow self-hosted environments en la página de administración Cloud environments. Esta página cubre la verificación de identidad de sesión; consulte el inicio rápido para la configuración y Implementar en producción para las recetas de flota.
CLAUDE_CODE_SESSION_ACCESS_TOKEN. Una sesión presenta el token como cualquier credencial de portador; por ejemplo, un script que Claude ejecuta puede llamar a su servicio con curl -H "Authorization: Bearer $CLAUDE_CODE_SESSION_ACCESS_TOKEN". Anthropic firma el token y publica las claves de verificación en un punto final JWKS público. Sus servicios obtienen esas claves, verifican la firma y leen las reclamaciones para decidir qué acceso otorgar.
El token de sesión
Antes de escribir código de verificación, sepa qué establece el token y la forma que verá su biblioteca JWT.Qué prueba el token
Un token válido establece algunos hechos y deliberadamente no otros:- Prueba: Anthropic emitió el token para una sesión específica en un entorno específico, y cómo se creó la sesión: por un usuario en su organización, o por la identidad de servicio de su organización, que es cómo comienzan las sesiones del canal Claude Tag
- No prueba: qué proceso en el host del ejecutor lo presenta. El token se encuentra en una variable de entorno dentro de la sesión, por lo que cualquier código que Claude ejecute y cualquier herramienta o servidor MCP que inicie la sesión puede leerlo y presentarlo.
- Verifique la reclamación
audcontra su ID de entorno, el valorccpool_...que se muestra con su entorno en la página de administración Cloud environments, para rechazar tokens emitidos a cualquier entorno de otra organización. - Limite las credenciales que derive del token a lo que una única sesión de codificación debería poder hacer, no a todo lo que el creador de la sesión puede hacer. Consulte Limitar credenciales derivadas.
Formato del token
El valor deCLAUDE_CODE_SESSION_ACCESS_TOKEN tiene un prefijo sk-ant-cc- seguido de un JWT estándar de tres partes:
sk-ant-si- en su lugar y están firmados por un conjunto de claves diferente, por lo que rechace cualquier valor que no comience con sk-ant-cc-.
El algoritmo de firma es ES256, que es ECDSA en la curva P-256 con SHA-256. El encabezado del token lleva un kid que identifica qué clave en el JWKS lo firmó.
Verificar el token
La verificación se ejecuta en uno de dos lugares. Los servicios en su red verifican el token criptográficamente contra las claves publicadas por Anthropic, y los scripts contenedores dentro de la sesión pueden usar el decodificador integrado del binario del ejecutor en su lugar.Verificar el token desde su servicio
Anthropic publica las claves de verificación en un punto final público y sin autenticación:Cache-Control: public, max-age=300, por lo que almacenar en caché el conjunto de claves y volver a obtenerlo cada cinco minutos es seguro.
Verifique cada token entrante contra estas comprobaciones:
1
Verificar el prefijo
Rechace el valor si no comienza con
sk-ant-cc-, luego elimine ese prefijo. El resto es un JWT compacto estándar.2
Verificar la firma
Obtenga el JWKS, seleccione la clave cuyo
kid coincida con el encabezado del token y verifique la firma ES256. Rechace los tokens cuyo encabezado alg no sea ES256. Si un token llega con un kid que no está en su conjunto de claves almacenado en caché, vuelva a obtener el JWKS una vez antes de rechazarlo: después de una rotación, los nuevos tokens se firman con una clave que su conjunto almacenado en caché aún no tiene.3
Verificar el emisor
Rechace el token si
iss no es exactamente ccr.4
Verificar la audiencia contra su entorno
La reclamación
aud es una matriz. Rechace el token a menos que contenga su ID de entorno, que tiene la forma ccpool_.... El ID de entorno se muestra en el cuadro de diálogo de detalles de su entorno en la página de administración Cloud environments, y aparece como la reclamación ccr:pool_id en cualquiera de los tokens de sesión del entorno. Esta comprobación es lo que limita el token a su entorno y rechaza los tokens emitidos a otras organizaciones.5
Verificar el rol
Rechace el token si
ccr:role no es exactamente session_worker. Otros tokens emitidos para entornos autohospedados, como secretos de entorno, tokens de ejecutor y órdenes de trabajo, se firman con el mismo conjunto de claves pero llevan roles diferentes.6
Verificar la expiración
Rechace el token si
exp está en el pasado. Anthropic emite tokens de sesión con una vida útil de cuatro horas por defecto y un máximo de ocho horas. El ejecutor actualiza el token antes de la expiración e inserta el nuevo valor en la sesión, por lo que los subprocesos que Claude inicia después de una actualización lo heredan. Una sesión puede, por lo tanto, presentar varios tokens válidos distintos a su servicio durante su vida útil.7
Leer la identidad
La identidad del usuario creador está en la reclamación
act: act.sub es su ID de usuario de Anthropic en la forma con prefijo user:<id>, y act.email, cuando la superficie creadora registró uno, es su dirección de correo electrónico. Las sesiones que crea la identidad de servicio de su organización, incluidas las sesiones del canal Claude Tag, llevan un asunto agent: en su lugar, por lo que trate una sesión como creada por el usuario solo cuando act.sub lleva el prefijo user:, en lugar de probar si las reclamaciones de identidad están ausentes. Consulte la referencia de reclamaciones para la estructura completa y las reclamaciones duplicadas planas.jose, que maneja la obtención de JWKS, almacenamiento en caché y selección de kid, y en Python con PyJWT y su cliente JWKS integrado.
- Node.js (jose)
- Python (PyJWT)
Verificar el token dentro de la sesión
Los scripts contenedores se ejecutan dentro de la sesión, antes de que Claude comience. En lugar de llamar a una biblioteca JWT, pueden ejecutar el subcomandoself-hosted-runner decode-token del binario del ejecutor. El subcomando lee el token de un argumento posicional, de CLAUDE_CODE_SESSION_ACCESS_TOKEN, o de stdin canalizado, en ese orden, luego elimina el prefijo, verifica la firma contra el punto final de JWKS, comprueba la expiración e imprime las reclamaciones como JSON. El subcomando realiza solo las comprobaciones de firma y expiración; no comprueba iss, aud o ccr:role. Cuando la decisión de autenticación de su contenedor depende de esas reclamaciones, léalas del JSON impreso y compárelas explícitamente.
Este comando extrae la identidad del creador, prefiriendo el asunto del proveedor de SSO, luego la dirección de correo electrónico, luego el asunto act.sub del creador, user:<id> o agent:<id>:
CLAUDE_RUNNER_CLAUDE_BIN; use esa ruta en lugar de un claude resuelto por PATH para que la decodificación se ejecute en el mismo binario que usa el ejecutor.
Use jq -re en lugar de jq -r para que una reclamación faltante cause una salida distinta de cero. Con solo -r, una reclamación faltante imprime la cadena literal null y sale con cero, lo que silenciosamente pasa un valor incorrecto aguas abajo. Pase --no-verify a decode-token solo para inspección sin conexión donde el punto final de JWKS es inaccesible.
Referencia de reclamaciones
La tabla a continuación enumera las reclamaciones de token de sesión relevantes para la verificación. Lea la identidad del espacio de nombresccr:* y la cadena act; las reclamaciones planas account_email, organization_uuid y account_uuid son duplicados de compatibilidad hacia atrás que pueden eliminarse. Las sesiones que crea la identidad de servicio de su organización, incluidas las sesiones del canal Claude Tag, llevan un asunto agent: en act.sub y omiten act.email, ccr:account_id, account_email y account_uuid. Las dos reclamaciones de correo electrónico también son opcionales para sesiones creadas por el usuario: Anthropic las registra en la creación de la sesión solo cuando las credenciales de la solicitud creadora llevan un correo electrónico, y una sesión enviada desde la CLI puede carecer de ambas, por lo que base la identidad en act.sub o ccr:account_id en lugar de en el correo electrónico. Los tokens también pueden llevar reclamaciones adicionales más allá de esta tabla; ignore las reclamaciones que no reconozca.
La cadena act
La reclamación act registra la ruta de delegación completa desde la identidad del usuario o servicio que creó la sesión hasta el entorno cuyo secreto admitió al ejecutor, y la identidad que creó ese secreto. El creador es el actor más externo, por lo que act.sub los identifica directamente.
Limitar credenciales derivadas
El token de sesión identifica la identidad del usuario o servicio que creó la sesión, pero no lo trate como equivalente a ese creador iniciando sesión directamente. El token se encuentra en una variable de entorno dentro de la sesión, por lo que cualquier código que Claude ejecute y cualquier herramienta o servidor MCP que inicie la sesión puede leerlo y presentarlo. La verificación también es sin conexión: un token que se verifica contra el JWKS permanece válido hasta suexp, sin importar lo que haya sucedido con la sesión desde entonces, y Anthropic no publica una fuente de revocación para tokens de sesión. Limite cualquier cosa que derive del token en consecuencia.
Cuando su servicio intercambia el token por credenciales internas, emita credenciales limitadas a lo que una sesión de codificación debería alcanzar:
- Limitar capacidades: otorgue acceso de lectura y escritura a los recursos que la sesión necesita para tareas de codificación, no a las capacidades administrativas que el creador tiene en otros lugares.
- Limitar vida útil: limite las credenciales derivadas a
expdel token, o menos. - Auditar como la sesión: registre
ccr:session_idyjtijunto con la identidad del creador para que pueda rastrear acciones hasta una sesión específica.
Variables de entorno relacionadas
La identidad del creador también aparece en variables de entorno simples en dos superficies que nunca verifican el token:- El hook
spawn-runner, en el orquestador: el hook se ejecuta antes de que exista cualquier ejecutor para una sesión en cola y recibe la identidad del creador en variables comoCLAUDE_RUNNER_ACCOUNT_EMAILyCLAUDE_RUNNER_ACCOUNT_ID. El orquestador las lee de la orden de trabajo, el token de un solo uso firmado que autoriza generar un ejecutor, sin verificar la firma de la orden de trabajo en sí; las reclamaciones se confían porque la orden de trabajo llega sobre la conexión del orquestador a Anthropic, que el secreto del entorno autentica. - Scripts contenedores, dentro de la sesión: los contenedores reciben
CCR_SESSION_ACCOUNT_EMAIL, el correo electrónico del creador preextraído del token sin verificación de firma. La variable es adecuada para etiquetado, como remolques de confirmación, no para decisiones de autenticación.
CLAUDE_CODE_SESSION_ACCESS_TOKEN cuando un servicio aguas abajo necesite prueba criptográfica independiente en lugar de confiar en el entorno del ejecutor.
Qué sigue
- Entornos autohospedados: el modelo de entorno, ejecutor y sesión; el inicio rápido y Implementar en producción contienen configuración y operaciones
- Personalizar sesiones: scripts contenedores que consumen el token y el hook
spawn-runner - Referencia: banderas CLI, variables de entorno y métricas