WS-Trust

O que é WS-Trust, em termos simples?

WS-Trust é um conjunto de regras técnicas que diz como dois sistemas podem estabelecer confiança entre si antes de trocar informações por serviços web do tipo SOAP. Em vez de cada sistema verificar diretamente a identidade de todos os outros, existe um intermediário confiável que emite uma espécie de crachá digital, chamado token de segurança.

A especificação é mantida pela OASIS, organização que publica padrões abertos, e funciona como uma extensão do WS-Security, que trata de proteger as mensagens SOAP com assinatura e criptografia.

Como funciona o WS-Trust?

O ponto central é o Security Token Service, ou STS, um serviço especializado em emitir tokens. O sistema que quer acessar um recurso envia ao STS uma mensagem chamada RequestSecurityToken, apresentando alguma prova de identidade, como usuário e senha, um certificado digital ou outro token já existente.

Se a prova for aceita, o STS responde com uma RequestSecurityTokenResponse contendo o token, que pode estar em formatos como SAML. O sistema então anexa esse token às mensagens enviadas ao serviço de destino, que confia no STS e, por isso, aceita o token sem precisar conferir as credenciais originais.

Além da emissão, a especificação prevê operações para renovar um token prestes a expirar, validar se um token ainda é legítimo e cancelá-lo quando não for mais necessário.

Para que serve o WS-Trust?

Ele serve principalmente para federação de identidade: permitir que uma organização reconheça usuários ou sistemas autenticados por outra, sem compartilhar senhas. Também ajuda a centralizar a autenticação, já que vários serviços passam a confiar em um único emissor de tokens.

Outro uso comum é a troca de credenciais, quando um sistema possui um tipo de token e precisa de outro formato para falar com um serviço diferente. O STS faz essa conversão de forma controlada.

O WS-Trust é usado na emissão de documentos fiscais?

Na integração com os serviços oficiais de NF-e, NFC-e, CT-e e MDF-e, a autenticação costuma se apoiar em conexão HTTPS com certificado digital do emitente e na assinatura digital do XML, e não em um fluxo WS-Trust. Os requisitos exatos dependem de cada serviço e, no caso da NFS-e, podem variar conforme o município ou o padrão adotado.

O WS-Trust aparece com mais frequência em ambientes corporativos baseados em SOAP, como integrações entre ERPs legados, serviços internos de grandes empresas ou plataformas de identidade federada. Uma equipe pode encontrá-lo ao integrar o sistema fiscal com outras partes da infraestrutura da empresa.

Qual a diferença entre WS-Trust e autenticação com JWT ou Bearer token?

O WS-Trust pertence ao mundo SOAP e XML, com mensagens mais longas e estruturadas. Já o uso de JWT e Bearer token é típico de APIs REST, que trocam dados em JSON e enviam o token em um cabeçalho HTTP de forma mais leve.

A ideia de fundo é parecida: um emissor confiável entrega um token que comprova identidade e permissões. A diferença está no formato, no protocolo e na complexidade. Por isso, APIs fiscais modernas tendem a usar API Key, Bearer token ou JWT, enquanto o WS-Trust permanece comum em integrações SOAP mais antigas ou muito formais.

Exemplos de WS-Trust

• Uma empresa com ERP legado baseado em SOAP usa um STS interno compatível com WS-Trust para emitir tokens que liberam o acesso do módulo financeiro ao serviço de cadastro de clientes.
• Um grupo empresarial com várias filiais adota WS-Trust para que usuários autenticados no diretório da matriz acessem serviços web das filiais sem precisar de novas senhas.
• Um integrador recebe um token SAML do STS de um parceiro via WS-Trust e o anexa às mensagens SOAP enviadas ao sistema desse parceiro para consultar pedidos antes de solicitar a emissão das notas fiscais por uma API REST.
• Uma equipe de TI configura a renovação automática de tokens WS-Trust para evitar que integrações noturnas entre sistemas internos falhem por expiração de credencial.