Um logout de back-channel OIDC encerra as sessões de um usuário num único app. Ele não revoga o tenant do cliente

Um back-channel logout OIDC termina as sessões de um utilizador numa única aplicação. Não revoga o tenant do cliente

A pergunta que um MSP ouve do cliente depois de uma chamada de incidente é: “o nosso IdP enviou um back-channel logout, por isso todo o tenant do cliente ficou cortado, certo?” A resposta curta é não. Segundo a OpenID Connect Back-Channel Logout 1.0, o fornecedor de identidade envia por POST um Logout Token assinado a uma relying party, e esse token identifica um único utilizador final (issuer mais subject) e/ou uma única sessão. Sem identificador de sessão, a relying party termina todas as sessões desse utilizador nessa relying party, e nada mais. Não existe nenhum claim de tenant nem qualquer significado de “revogar todos”.

Esta FAQ responde a seis perguntas que os MSP fazem quando um sinal de logout é confundido com offboarding. O que prova um 200 OK do endpoint de logout, e o que não prova? Porque é que as integrações machine-to-machine ficam totalmente fora do percurso de logout? Porque é que terminar a sessão no IdP não termina automaticamente as sessões nas aplicações, como afirma o NIST SP 800-63C-4 (26 de agosto de 2025)? Onde se situa um sinal de revogação com âmbito de tenant ou de política, com o CAEP sobre o Shared Signals Framework, e porque é que nem isso substitui a verificação de autorização em cada pedido? E porque é que o logout não é desaprovisionamento?

A regra deste artigo é simples: o offboarding de um tenant é uma ação de administração e de autorização, nunca um efeito secundário de um logout. As fontes são os textos da OpenID, IETF, NIST e OWASP verificados a 5 de outubro de 2026. Não há construção de tokens nem qualquer afirmação de que um produto Altovar transmita ou receba estes eventos de logout ou de sinais partilhados.

Todo o tenant do cliente é revogado quando o IdP envia um back-channel logout? Nas palavras do cliente: “fizeram logout, por isso toda a gente desse cliente está fora”. A resposta é não. Um pedido de Back-Channel Logout é um POST do fornecedor de identidade para a relying party que transporta um Logout Token assinado, tal como definido na secção 2.4 da OIDC Back-Channel Logout 1.0. O token identifica um utilizador final através do issuer e do subject, e/ou uma sessão através do ID de sessão. É esse o raio de ação que a norma dá ao sinal.

Quando o ID de sessão está ausente, a relying party termina todas as sessões desse utilizador nessa relying party. A norma não vai mais longe do que isso. Continua a ser um utilizador e uma aplicação. Terminar todas as sessões de browser que a Alice tem no portal de tickets não termina as sessões do Bob no mesmo portal, nem as sessões da Alice noutro portal que nunca recebeu um Logout Token.

O Logout Token não contém nenhum claim de tenant nem significa “revogar todos”. Uma relying party que trata um logout como revogação do tenant está a inventar um comportamento que a especificação não define. A revogação de um tenant, enquanto conjunto de atos administrativos separados e não como um guia de produto, significa desativar o registo do tenant, revogar os seus grants e registos de clientes, rodar as credenciais que detém e fazer com que o ponto de decisão de políticas recuse os seus pedidos. Cada ato tem um responsável e um registo de auditoria. Nenhum deles é um logout.

Uma breve nota sobre assinaturas, sem entrar em pormenores: a especificação exige que o Logout Token seja assinado e de curta duração precisamente para que uma relying party não aja com base num logout falsificado ou reproduzido. Este artigo não descreve como um token é construído ou verificado. O que importa para o MSP é o raio de ação: um utilizador, uma aplicação, não o tenant do cliente.

O endpoint de logout devolveu 200 OK. Todos os tokens do utilizador estão mortos? Não necessariamente. Um 200 OK significa que a relying party limpou o estado das sessões que lhe foram indicadas. É um recibo dessa relying party, não uma prova de que todos os tokens desapareceram em todo o lado.

Os refresh tokens seguem uma regra mais restrita, segundo a secção 2.7 da Back-Channel Logout. Os refresh tokens associados à sessão terminada e emitidos sem offline_access DEVERIAM ser revogados; os refresh tokens de offline access normalmente NÃO DEVERIAM. É uma propriedade genérica da norma. Este artigo não a associa à configuração de nenhum fornecedor e não indica valores de inatividade ou de duração.

Com os access tokens a história é outra. Um access token autocontido (JWT) continua válido até expirar, a menos que o resource server o verifique em tempo real através de introspeção (RFC 7662) ou que o token seja revogado no authorization server (RFC 7009). A própria secção 3 do RFC 7009 nota que a revogação imediata de access tokens autocontidos exige coordenação adicional, não normalizada, entre authorization server e resource server, ou tempos de vida curtos. Um 200 OK no logout não é essa coordenação.

Uma salvaguarda sobre a introspeção, numa frase: active: true significa que o token foi emitido e não está revogado nem expirado. Não diz nada sobre se este tenant ou esta ação estão autorizados. É uma questão à parte, que este artigo não desenvolve. O OWASP Session Management Cheat Sheet acrescenta mais uma linha: o logout tem de invalidar a sessão do lado do servidor; apagar um cookie no browser não é a mesma coisa.

O logout corta as integrações machine-to-machine? Não. O Back-Channel Logout termina sessões de utilizadores finais nas relying parties. Um cliente de máquina que obtém tokens através do grant client credentials não tem sessão de utilizador nem ID de sessão, pelo que um Logout Token não o pode visar. O sinal não tem onde aterrar.

A consequência para o MSP, em palavras simples: o conector RMM, a sincronização de faturação e o cliente API do agente de backup continuam a funcionar depois de todas as pessoas do cliente terem feito logout. É o comportamento correto do protocolo, e é exatamente por isso que “fizemos logout a toda a gente” não é um registo de offboarding. As pessoas saíram das aplicações que receberam um Logout Token. As integrações não são pessoas e não receberam nenhum.

O offboarding de uma integração tem a sua própria checklist, escrita como resultados e não como cliques num produto: desativar ou rodar as credenciais do cliente, revogar os tokens que já detém e retirar o seu direito sobre o tenant no ponto de decisão. Cada um destes passos é um ato de administração e de autorização com um responsável. Nenhum resulta de um POST de logout.

Terminar a sessão no IdP termina automaticamente as sessões nas aplicações? Não. O NIST SP 800-63C-4 (Revision 4 final, página datada de 26 de agosto de 2025) afirma que terminar a sessão do subscritor no IdP “não terminará necessariamente” as sessões que esse subscritor possa ter nas RP a jusante (tradução nossa). As duas partes podem trocar eventos de fim de sessão se o protocolo de federação o suportar, ou através de sinais partilhados. “Podem” não é “vão”.

O Back-Channel Logout é um desses mecanismos e funciona em regime de best effort. A relying party tem de registar um URI de back-channel logout, o fornecedor de identidade tem de o conseguir alcançar e só volta a tentar após erros que considere recuperáveis (secção 2.5 da Back-Channel Logout). Uma aplicação que nunca se registou, ou que estava inacessível quando o IdP enviou o POST, mantém a sua sessão. Uma regra de firewall, um URI desatualizado ou um registo em falta bastam para deixar uma sessão ativa.

A secção 5 do NIST SP 800-63B-4 acrescenta uma clarificação de vocabulário: as sessões terminam por tempo limite ou por logout explícito, e o comportamento em federação é remetido para o 63C. Portanto, “a sessão no IdP expirou” e “todas as aplicações fizeram logout” são dois factos diferentes. Um ticket de MSP que os confunda vai fechar o trabalho errado.

Fazer logout a um utilizador também não remove a pertença ao tenant nem as funções. O NIST SP 800-63C-4 trata o encerramento de uma conta de subscritor na relying party (remoção de identificadores, autenticadores e atributos) como um ato separado do fim da sessão. A pertença e as funções são dados de aprovisionamento e de autorização; alterá-los é desaprovisionamento. A frase a reter: fim de sessão ≠ encerramento da conta ≠ offboarding do tenant.

Onde se situa uma revogação com âmbito de tenant, se não num Logout Token? O OpenID Shared Signals Framework 1.0, com o Continuous Access Evaluation Profile (CAEP 1.0, ambos na versão Final), define os eventos session-revoked e token-claims-change. O seu sujeito pode ser um sujeito complexo que inclua uma componente de tenant. É o mais perto que uma norma chega de uma mensagem de revogação com âmbito de tenant ou de política.

Continua a ser um sinal: quem o recebe decide o que fazer com ele. Receber um evento não é o mesmo que ter revogado o acesso. Um produto que ignora o evento, o atrasa ou o converte num simples aviso não executou a recusa. O evento é um gatilho, não a decisão.

A autorização no produto tem, ainda assim, de recusar por omissão e verificar o estado do tenant e as permissões em cada pedido, tal como o OWASP Authorization Cheat Sheet o enquadra. Um logout ou um evento CAEP desencadeia essa verificação, não a substitui. Um MSP que trata “CAEP recebido” como “acesso revogado” está a saltar o ponto de decisão.

Este artigo não diz que produtos transmitem ou recebem CAEP. Em particular, não diz que o Auris o faz. O artigo descreve apenas a norma e não afirma que algum produto Altovar suporte CAEP, SSF ou back-channel logout.

Esta não é uma FAQ sobre PAR, PKCE ou passkeys. Esses temas dizem respeito à forma como começa um login ou um pedido de autorização. Este artigo trata do que um sinal de logout termina. Iniciar um pedido e terminar uma sessão são tarefas diferentes, e misturá-las gera o ticket errado.

Também não é uma FAQ sobre group claims ou SCIM. Os dados de aprovisionamento e de funções aparecem aqui apenas para dizer que o logout não os altera. Os registos de pertença e as atribuições de funções sobrevivem a um Logout Token, a menos que um ato administrativo separado os remova.

Tão-pouco trata de DPoP ou das cerimónias de vinculação de autenticadores. A restrição ao remetente (sender constraint) e a vinculação do autenticador respondem a perguntas diferentes do raio de ação do logout.

E não trata de tokens de curta duração nem de TTL de tokens. Esses temas dizem respeito a quanto tempo vive um token. Aqui importa o raio de ação do sinal de logout (sessão ou utilizador face ao tenant), não o tempo de vida. Um access token de curta duração e um Logout Token podem coexistir na mesma stack e, mesmo assim, deixar intactos os clientes de máquina e as outras aplicações.

Este artigo não afirma que o Auris suporta back-channel logout, CAEP ou SSF, anuncia backchannel_logout_supported, respeita um backchannel_logout_uri por cliente ou transmite eventos de sinais partilhados.

A frase a repetir: um sinal de logout termina sessões; revogar o tenant de um cliente é uma decisão deliberada de administração e de autorização, verificada em cada pedido.