A federação de identidades de cargas de trabalho X.509 permite que uma carga de trabalho troque a identidade de um certificado de cliente TLS por um token de acesso da OpenAI de curta duração. Em seguida, a carga de trabalho chama a API da OpenAI usando tanto o token de acesso quanto um certificado de cliente aceito. Esse fluxo substitui a chave de API, não o certificado de cliente.
A federação de identidades de cargas de trabalho X.509 está disponível para a API da OpenAI. O Codex não oferece suporte a ela. Para o Codex, use um token OIDC ou um JWT-SVID do SPIFFE e siga o guia de identidade de cargas de trabalho do Codex.
Para ver detalhes das requisições e respostas de troca de tokens, consulte a referência de troca de tokens de identidade de cargas de trabalho. Para saber mais sobre permissões de TLS mútuo, requisitos de certificados, ativação, hosts mTLS e rotação, consulte o guia de TLS mútuo.
Como funciona
Uma troca de identidade de cargas de trabalho X.509 tem cinco partes:
- Sua organização envia e ativa um certificado raiz confiável nas configurações existentes de TLS mútuo.
- Um provedor de identidade de cargas de trabalho X.509 deriva atributos
openai.*do certificado de cliente verificado. Ele deve derivar um valor não vazio deopenai.subject. - Um mapeamento de conta de serviço autoriza a identidade derivada a usar uma conta de serviço da OpenAI em um projeto.
- A carga de trabalho apresenta seu certificado ao endpoint de tokens X.509 em
mtls.auth.openai.come solicita um token bearer de curta duração. O certificado vem da conexão TLS; o corpo da requisição não contém umsubject_token. - A carga de trabalho apresenta o token bearer e um certificado de cliente a uma rota da API em
mtls.api.openai.compara obter autorização na API.
O token bearer e o certificado são autorizados de forma independente na requisição à API. Um certificado, por si só, não autoriza uma chamada à API da OpenAI.
Antes de começar
Você precisa de:
- Permissão para gerenciar certificados de TLS mútuo e provedores de identidade de cargas de trabalho da sua organização.
- Um projeto e uma conta de serviço para a carga de trabalho.
- Um certificado de cliente, sua chave privada e todos os certificados intermediários necessários para formar uma cadeia até a raiz confiável.
- Um certificado raiz confiável ativo no nível da organização ou do projeto.
Mantenha as chaves privadas fora do controle de versão e restrinja o acesso a elas à carga de trabalho que as utiliza. Não registre em logs chaves privadas, o conteúdo de certificados nem os tokens de acesso retornados.
Configure a confiança em certificados de TLS mútuo
Os provedores de identidade de cargas de trabalho X.509 reutilizam a configuração existente de certificados de TLS mútuo da sua organização. Eles não enviam certificados nem mantêm um repositório separado de certificados confiáveis.
Siga o guia de TLS mútuo para revisar os requisitos de certificados, os hosts mTLS, o comportamento de ativação de certificados, os filtros CEL e a configuração do cliente. Em seguida, abra Configurações da organização > Segurança > TLS mútuo, envie o certificado confiável no formato PEM e ative-o para a organização ou para cada projeto que usará a federação de identidades de cargas de trabalho X.509.
Se a cadeia do seu certificado de cliente passar por um certificado intermediário, configure a âncora de confiança estável e apresente o certificado folha seguido dos certificados intermediários atuais durante o handshake TLS. A OpenAI usa os certificados intermediários fornecidos pela requisição e não busca os que estiverem faltando nas URLs dos certificados.
Configure um provedor X.509
Para configurar um provedor X.509:
- Abra Configurações da organização > Segurança > Provedor de identidade de cargas de trabalho e selecione Criar provedor de identidade.
- Escolha X.509 em Tipo de provedor e insira um nome e uma descrição opcional. Provedores X.509 não usam configurações de emissor, público-alvo, descoberta ou JWKS do OIDC. Não é possível alterar o tipo do provedor depois de criá-lo.
- Em Avançado, você pode adicionar uma expressão CEL em Condições de atributos para rejeitar certificados antes da resolução do mapeamento.
- Em Transformações de atributos, insira uma expressão não vazia para a transformação obrigatória
openai.subject. O painel adiciona a linhasubjectquando você seleciona X.509, além de exibir e aplicar o prefixoopenai.. Escolha um dado estável do certificado que identifique a carga de trabalho. - Se quiser, adicione transformações com outros nomes
openai.*exclusivos e selecione Criar.
Por exemplo, esta configuração usa o nome comum do certificado como sujeito canônico e disponibiliza a unidade organizacional como um atributo adicional de mapeamento:
[
{
"attribute": "openai.subject",
"expression": "assertion.subject.common_name"
},
{
"attribute": "openai.environment",
"expression": "assertion.subject.organizational_unit"
}
]
Os dados do certificado estão disponíveis em assertion.subject e assertion.subject_alt_names. Os resultados das transformações usados em mapeamentos devem ser valores escalares. Transformações adicionais devem ter nomes openai.* exclusivos.
Por exemplo, uma expressão em Condições de atributos pode restringir o provedor a certificados de produção:
assertion.subject.organizational_unit == "Production"
Crie um mapeamento de conta de serviço
- Na página de detalhes do provedor X.509, selecione Criar mapeamento.
- Selecione o projeto e a conta de serviço de destino e conceda apenas as permissões de API necessárias para a carga de trabalho.
- Nos campos Chave e Valor , exija um valor exato de
openai.subject. Os mapeamentos X.509 aceitam tanto a ausência de asserções, representada por um objeto vazio ({}), quanto asserções cujas chaves começam comopenai.. - Selecione Criar.
Por exemplo:
| Chave | Valor |
|---|---|
openai.subject | payments-service-prod |
Os mapeamentos X.509 usam atributos openai.* derivados. Eles não fazem correspondência com declarações JWT brutas, como sub, iss ou aud.
A lista de provedores exibe o ID do provedor, e os detalhes do mapeamento exibem a conta de serviço selecionada e seu ID. Anote os dois identificadores; a carga de trabalho os envia durante a troca de tokens.
Use a identidade de cargas de trabalho X.509 com um SDK
Defina as variáveis do ambiente para a cadeia de certificados, a chave privada, o provedor e a conta de serviço:
export OPENAI_MTLS_CERT_CHAIN="/path/to/client-chain.pem"
export OPENAI_MTLS_KEY="/path/to/client-key.pem"
export OPENAI_IDENTITY_PROVIDER_ID="idp_example"
export OPENAI_SERVICE_ACCOUNT_ID="svc_acct_example"
O arquivo da cadeia de certificados deve conter primeiro o certificado folha, seguido dos certificados intermediários, se houver. Não inclua dados de certificados nem um subject_token no corpo da requisição.
Configure um cliente do OpenAI SDK com esses valores. O SDK apresenta o certificado de cliente durante a troca de tokens e nas requisições à API, encaminha as requisições à API para o endpoint mTLS e renova automaticamente os tokens de acesso de curta duração.
import { readFile } from "node:fs/promises";
import OpenAI from "openai";
import { workloadIdentity } from "openai/auth/x509-transport";
const certificatePath = process.env.OPENAI_MTLS_CERT_CHAIN;
const privateKeyPath = process.env.OPENAI_MTLS_KEY;
const identityProviderId = process.env.OPENAI_IDENTITY_PROVIDER_ID;
const serviceAccountId = process.env.OPENAI_SERVICE_ACCOUNT_ID;
if (
!certificatePath ||
!privateKeyPath ||
!identityProviderId ||
!serviceAccountId
) {
throw new Error(
"Set OPENAI_MTLS_CERT_CHAIN, OPENAI_MTLS_KEY, OPENAI_IDENTITY_PROVIDER_ID, and OPENAI_SERVICE_ACCOUNT_ID"
);
}
const credential = workloadIdentity.fromX509({
certificateChain: await readFile(certificatePath, "utf8"),
privateKey: await readFile(privateKeyPath, "utf8"),
identityProviderId,
serviceAccountId,
});
try {
const client = new OpenAI({ credential });
const response = await client.responses.create({
model: "gpt-5.6-terra",
input: "Say hello from X.509 workload identity federation.",
});
console.log(response.output_text);
} finally {
await credential.close();
}Estes exemplos exigem versões do OpenAI SDK que ofereçam suporte à configuração X.509 mostrada aqui: JavaScript 7.8.0 ou posterior com a dependência de par undici instalada, Python 3.6.0 ou posterior, Go 3.54.0 ou posterior, Java 4.55.0 ou posterior e Ruby 0.83.0 ou posterior.
O exemplo em Java carrega um repositório de chaves PKCS12 para construir seu X509ExtendedKeyManager e usa o repositório de certificados confiáveis padrão da plataforma para construir seu X509TrustManager. Defina OPENAI_X509_KEYSTORE_PATH, OPENAI_X509_KEYSTORE_PASSWORD e OPENAI_X509_CERTIFICATE_ALIAS para este exemplo. Como alternativa, você pode fornecer ao SDK gerenciadores baseados em PEM ou em hardware.
Troque o certificado manualmente
Para inspecionar ou implementar diretamente o protocolo de troca de tokens, apresente o certificado ao endpoint de tokens X.509:
curl --cert "$OPENAI_MTLS_CERT_CHAIN" \
--key "$OPENAI_MTLS_KEY" \
--request POST "https://mtls.auth.openai.com/oauth/token" \
--header "Content-Type: application/json" \
--data @- <<JSON
{
"grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
"subject_token_type": "urn:openai:params:oauth:token-type:x509",
"identity_provider_id": "${OPENAI_IDENTITY_PROVIDER_ID}",
"service_account_id": "${OPENAI_SERVICE_ACCOUNT_ID}"
}
JSON
Uma troca bem-sucedida retorna um token bearer comum de curta duração:
{
"access_token": "eyJ...",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"token_type": "Bearer",
"expires_in": 3600,
"expires_at": 1789045200,
"scope": "api.model.read api.model.request"
}
A propriedade scope é retornada somente quando o mapeamento de conta de serviço correspondente tem permissões.
Os valores de expiração são ilustrativos. O prazo de validade retornado pode ser menor quando o certificado de cliente verificado expira antes. Consulte os campos da resposta de troca de tokens para saber as unidades e o significado de expires_in e expires_at.
Leia o valor de access_token da resposta bem-sucedida e armazene-o no repositório de credenciais da sua aplicação ou em uma variável do ambiente, como OPENAI_WIF_ACCESS_TOKEN. Trate-o como um segredo e não o exiba, registre em logs nem inclua em commits.
Chame a API da OpenAI manualmente
Defina OPENAI_MODEL como gpt-6-astra, o modelo padrão atual, ou como outro modelo disponível para o projeto de destino. Em seguida, envie o token bearer e um certificado de cliente aceito ao endpoint mTLS da API:
curl --request POST \
--cert "$OPENAI_MTLS_CERT_CHAIN" \
--key "$OPENAI_MTLS_KEY" \
--header "Authorization: Bearer $OPENAI_WIF_ACCESS_TOKEN" \
--header "Content-Type: application/json" \
--data "{\"model\":\"$OPENAI_MODEL\",\"input\":\"Say hello in one sentence.\"}" \
"https://mtls.api.openai.com/v1/responses"
Use o token bearer em vez de uma chave de API e continue apresentando um certificado de cliente aceito na requisição à API.
O token bearer não é vinculado criptograficamente ao certificado. Reutilizar o certificado da troca na requisição à API é a configuração mais direta, mas a requisição à API pode usar outro certificado que atenda, de forma independente, à mesma política mTLS vigente da API.
Validade e renovação do token
Um token de identidade de cargas de trabalho X.509 expira em, no máximo, uma hora e nunca permanece válido após a expiração do certificado de cliente verificado. A troca não retorna um token de atualização. Repita a troca de certificado para obter outro token de acesso.
Para trocas manuais, armazene expires_at junto com o token de acesso e agende outra troca antes do horário indicado por esse valor. Deixe uma margem para diferenças entre os relógios e para a latência das requisições. Consulte as orientações sobre renovação de tokens para ver um exemplo.
A rotação de um certificado intermediário não exige alterar o certificado raiz configurado. Apresente a nova cadeia completa nas próximas trocas e requisições à API.
Solucionar problemas na troca de tokens
A troca de tokens X.509 retorna erros OAuth genéricos e não expõe detalhes do certificado, do certificado raiz, do provedor ou do mapeamento.
| Resultado | Causas comuns |
|---|---|
HTTP 403 | A requisição usou um método ou caminho diferente de exatamente POST /oauth/token em mtls.auth.openai.com. |
invalid_subject_token | O certificado de cliente TLS está ausente ou é inválido, a cadeia apresentada não chega a um certificado raiz ativo, o certificado está fora do período de validade ou uma regra de admissão de certificados de TLS mútuo o rejeita. |
invalid_grant | O provedor ou mapeamento é inválido ou está desativado, uma expressão de Condições de atributos do provedor rejeita a identidade, nenhum certificado raiz aplicável está ativo ou nenhum mapeamento corresponde à identidade. |
| Erro do servidor | A OpenAI retornou um erro temporário do servidor. Tente novamente de acordo com sua política habitual para erros transitórios. |
Uma troca X.509 nunca recorre a um fluxo OIDC ou OAuth comum como alternativa.
Limitações
- Os provedores de identidade de cargas de trabalho X.509 não mantêm um repositório separado de certificados confiáveis.
- O token de portador não está vinculado ao certificado e não usa DPoP nem uma declaração
cnf. - A troca de certificado não autoriza o acesso à API apenas com o certificado. As requisições à API continuam exigindo o token de portador e um certificado de cliente aceito.
- A OpenAI não busca certificados intermediários ausentes em URLs AIA. Apresente a cadeia completa durante a negociação TLS.
- A OpenAI não realiza verificações de lista de revogação de certificados (CRL) ou OCSP durante esse fluxo. Planeje a resposta a incidentes com certificados com base nos controles de certificados raiz de TLS mútuo, de provedores e de mapeamentos, além do curto prazo de validade dos tokens emitidos.
- Esse fluxo não adiciona suporte a X.509-SVIDs do SPIFFE. O guia do SPIFFE continua usando JWT-SVIDs.