Ambientes auto-hospedados estão em beta pública em planos Team e Enterprise; um Owner os habilita ativando Allow self-hosted environments na página de administração Cloud environments. Esta página aborda verificação de identidade de sessão; consulte o quickstart para configuração e Deploy to production para as receitas de frota.
CLAUDE_CODE_SESSION_ACCESS_TOKEN. Uma sessão apresenta o token como qualquer credencial de portador; por exemplo, um script que Claude executa pode chamar seu serviço com curl -H "Authorization: Bearer $CLAUDE_CODE_SESSION_ACCESS_TOKEN". Anthropic assina o token e publica as chaves de verificação em um endpoint JWKS público. Seus serviços buscam essas chaves, verificam a assinatura e leem as declarações para decidir qual acesso conceder.
O token de sessão
Antes de escrever código de verificação, saiba o que o token estabelece e a forma que sua biblioteca JWT verá.O que o token prova
Um token válido estabelece alguns fatos e deliberadamente não estabelece outros:- Prova: Anthropic emitiu o token para uma sessão específica em um ambiente específico, e como a sessão foi criada: por um usuário em sua organização, ou pela identidade de serviço de sua organização, que é como sessões de canal Claude Tag começam
- Não prova: qual processo no host do runner o apresenta. O token fica em uma variável de ambiente dentro da sessão, portanto qualquer código que Claude executa e qualquer ferramenta ou servidor MCP que a sessão inicia pode lê-lo e apresentá-lo.
- Verifique a declaração
audcontra seu ID de ambiente, o valorccpool_...mostrado com seu ambiente na página de administração Cloud environments, para rejeitar tokens emitidos para o ambiente de qualquer outra organização. - Escope as credenciais que você deriva do token para o que uma única sessão de codificação deve ser capaz de fazer, não para tudo que o criador da sessão pode fazer. Consulte Escopo de credenciais derivadas.
Formato do token
O valor deCLAUDE_CODE_SESSION_ACCESS_TOKEN tem um prefixo sk-ant-cc- seguido por um JWT padrão de três partes:
sk-ant-si- em vez disso e são assinados por um conjunto de chaves diferente, portanto rejeite qualquer valor que não comece com sk-ant-cc-.
O algoritmo de assinatura é ES256, que é ECDSA na curva P-256 com SHA-256. O cabeçalho do token carrega um kid que identifica qual chave no JWKS o assinou.
Verificar o token
A verificação é executada em um de dois lugares. Serviços em sua rede verificam o token criptograficamente contra as chaves publicadas pela Anthropic, e scripts de wrapper dentro da sessão podem usar o decodificador integrado do binário do runner.Verificar o token de seu serviço
Anthropic publica as chaves de verificação em um endpoint público e não autenticado:Cache-Control: public, max-age=300, portanto armazenar em cache o conjunto de chaves e refazer a busca a cada cinco minutos é seguro.
Verifique cada token de entrada contra estas verificações:
1
Verificar o prefixo
Rejeite o valor se não começar com
sk-ant-cc-, depois remova esse prefixo. O restante é um JWT compacto padrão.2
Verificar a assinatura
Busque o JWKS, selecione a chave cujo
kid corresponde ao cabeçalho do token e verifique a assinatura ES256. Rejeite tokens cujo cabeçalho alg não é ES256. Se um token chegar com um kid que não está em seu conjunto de chaves em cache, refaça a busca do JWKS uma vez antes de rejeitá-lo: após uma rotação, novos tokens são assinados com uma chave que seu conjunto em cache ainda não possui.3
Verificar o emissor
Rejeite o token se
iss não for exatamente ccr.4
Verificar a audiência contra seu ambiente
A declaração
aud é uma matriz. Rejeite o token a menos que contenha seu ID de ambiente, que tem a forma ccpool_.... O ID do ambiente é mostrado no diálogo de detalhes do seu ambiente na página de administração Cloud environments, e aparece como a declaração ccr:pool_id em qualquer um dos tokens de sessão do ambiente. Esta verificação é o que escopa o token para seu ambiente e rejeita tokens emitidos para outras organizações.5
Verificar a função
Rejeite o token se
ccr:role não for exatamente session_worker. Outros tokens emitidos para ambientes auto-hospedados, como segredos de ambiente, tokens de runner e ordens de trabalho, são assinados pelo mesmo conjunto de chaves, mas carregam funções diferentes.6
Verificar expiração
Rejeite o token se
exp estiver no passado. Anthropic emite tokens de sessão com um tempo de vida padrão de quatro horas e um máximo de oito horas. O runner atualiza o token antes da expiração e envia o novo valor para a sessão, portanto os subprocessos que Claude inicia após uma atualização o herdam. Uma sessão pode, portanto, apresentar vários tokens válidos distintos ao seu serviço ao longo de sua vida útil.7
Ler a identidade
A identidade do usuário criador está na declaração
act: act.sub é seu ID de usuário Anthropic no formulário prefixado user:<id>, e act.email, quando a superfície criadora registrou um, é seu endereço de email. Sessões que a identidade de serviço de sua organização cria, incluindo sessões de canal Claude Tag, carregam um assunto agent: em vez disso, portanto trate uma sessão como criada pelo usuário apenas quando act.sub carrega o prefixo user:, em vez de testar se as declarações de identidade estão ausentes. Consulte a referência de declarações para a estrutura completa e as declarações duplicadas simples.jose, que lida com busca de JWKS, armazenamento em cache e seleção de kid, e em Python com PyJWT e seu cliente JWKS integrado.
- Node.js (jose)
- Python (PyJWT)
Verificar o token dentro da sessão
Scripts de wrapper são executados dentro da sessão, antes de Claude começar. Em vez de chamar uma biblioteca JWT, eles podem executar o subcomandoself-hosted-runner decode-token do binário do runner. O subcomando lê o token de um argumento posicional, de CLAUDE_CODE_SESSION_ACCESS_TOKEN ou de stdin canalizado, nessa ordem, depois remove o prefixo, verifica a assinatura contra o endpoint JWKS, verifica expiração e imprime as declarações como JSON. O subcomando executa apenas as verificações de assinatura e expiração; não verifica iss, aud ou ccr:role. Quando a decisão de autenticação do seu wrapper depende dessas declarações, leia-as do JSON impresso e compare-as explicitamente.
Este comando extrai a identidade do criador, preferindo o assunto do provedor SSO, depois o endereço de email, depois o assunto act.sub do criador, user:<id> ou agent:<id>:
CLAUDE_RUNNER_CLAUDE_BIN; use esse caminho em vez de um claude resolvido por PATH para que a decodificação seja executada no mesmo binário que o runner usa.
Use jq -re em vez de jq -r para que uma declaração ausente cause uma saída diferente de zero. Com apenas -r, uma declaração ausente imprime a string literal null e sai com zero, o que silenciosamente passa um valor ruim para jusante. Passe --no-verify para decode-token apenas para inspeção offline onde o endpoint JWKS está inacessível.
Referência de declarações
A tabela abaixo lista as declarações de token de sessão relevantes para verificação. Leia a identidade do namespaceccr:* e da cadeia act; as declarações simples account_email, organization_uuid e account_uuid são duplicatas de compatibilidade com versões anteriores que podem ser removidas. Sessões que a identidade de serviço de sua organização cria, incluindo sessões de canal Claude Tag, carregam um assunto agent: em act.sub e omitem act.email, ccr:account_id, account_email e account_uuid. As duas declarações de email também são opcionais para sessões criadas pelo usuário: Anthropic as registra na criação da sessão apenas quando as credenciais da solicitação criadora carregam um email, e uma sessão despachada da CLI pode carecer de ambas, portanto baseie a identidade em act.sub ou ccr:account_id em vez de email. Tokens também podem carregar declarações adicionais além desta tabela; ignore declarações que você não reconheça.
A cadeia act
A declaração act registra o caminho de delegação completo da identidade do usuário ou serviço que criou a sessão até o ambiente cujo segredo admitiu o runner, e a identidade que criou esse segredo. O criador é o ator mais externo, portanto act.sub os identifica diretamente.
Escopo de credenciais derivadas
O token de sessão identifica a identidade do usuário ou serviço que criou a sessão, mas não o trate como equivalente a esse criador fazendo login diretamente. O token fica em uma variável de ambiente dentro da sessão, portanto qualquer código que Claude executa e qualquer ferramenta ou servidor MCP que a sessão inicia pode lê-lo e apresentá-lo. A verificação também é offline: um token que verifica contra o JWKS permanece válido até seuexp, seja o que for que tenha acontecido com a sessão desde então, e Anthropic não publica um feed de revogação para tokens de sessão. Vincule qualquer coisa que você derive do token de acordo.
Quando seu serviço troca o token por credenciais internas, emita credenciais escopadas para o que uma sessão de codificação deve alcançar:
- Limitar capacidades: conceda acesso de leitura e escrita aos recursos que a sessão precisa para tarefas de codificação, não às capacidades administrativas que o criador possui em outro lugar.
- Limitar tempo de vida: vincule credenciais derivadas ao
expdo token, ou mais curto. - Auditar como a sessão: registre
ccr:session_idejtijunto com a identidade do criador para que você possa rastrear ações de volta a uma sessão específica.
Variáveis de ambiente relacionadas
A identidade do criador também aparece em variáveis de ambiente simples em duas superfícies que nunca verificam o token:- O hook
spawn-runner, no orquestrador: o hook é executado antes de qualquer runner existir para uma sessão enfileirada e recebe a identidade do criador em variáveis comoCLAUDE_RUNNER_ACCOUNT_EMAILeCLAUDE_RUNNER_ACCOUNT_ID. O orquestrador as lê da ordem de trabalho, o token de uso único assinado que autoriza a geração de um runner, sem verificar a assinatura da ordem de trabalho em si; as declarações são confiáveis porque a ordem de trabalho chega pela conexão do orquestrador com Anthropic, que o segredo do ambiente autentica. - Scripts de wrapper, dentro da sessão: wrappers recebem
CCR_SESSION_ACCOUNT_EMAIL, o email do criador pré-extraído do token sem verificação de assinatura. A variável é adequada para rotulagem, como trailers de commit, não para decisões de autenticação.
CLAUDE_CODE_SESSION_ACCESS_TOKEN quando um serviço downstream precisa de prova criptográfica independente em vez de confiar no ambiente do runner.
Próximas etapas
- Ambientes auto-hospedados: o ambiente, runner e modelo de sessão; o quickstart e Deploy to production contêm configuração e operações
- Personalizar sessões: scripts de wrapper que consomem o token e o hook
spawn-runner - Referência: sinalizadores CLI, variáveis de ambiente e métricas