Por dentro do Authrim
A cadeia de logout
A pessoa entra uma vez, mas várias sessões são criadas pelo caminho. Sair da conta depende de encerrar as sessões certas em cada sistema envolvido.
Um login, três chaves
Imagine adicionar “Entrar com o Google” ao seu serviço. Para o usuário, é um único clique.
Por trás desse clique, cada sistema no caminho cria e mantém sua própria sessão. O Google tem uma. O Authrim tem outra. Sua aplicação também. São três.
Uma sessão que permanece ativa pode permitir que a pessoa continue usando o serviço ou entre novamente sem digitar a senha.
Sair não é apenas exibir “Você saiu da conta”.
É definir o alcance da saída e encerrar as sessões dentro dele.
Revogar tokens é outra operação
As “chaves” aqui são sessões. Tokens de acesso e de atualização são outro mecanismo. Encerrar uma sessão não invalida necessariamente os tokens já emitidos. Para interromper o uso de um token, é preciso revogá-lo, uma operação separada.
No OIDC, encerrar sessões, revogar tokens e desativar uma conta no provedor de origem são três coisas diferentes. Este artigo trata das sessões. Para saber quando um token deixa de funcionar, veja introspecção e revogação de tokens.
O Authrim fica no meio
O provedor de origem oferece a autenticação, enquanto sua aplicação a solicita. O papel do Authrim muda conforme o lado com que ele se comunica.
A saída costuma parar no meio do caminho
O login percorre o caminho entre os sistemas. A saída precisa ser comunicada explicitamente aos próximos.
Encerrar a sessão no provedor de origem não remove automaticamente as sessões no Authrim e na aplicação. É preciso comunicar o encerramento, e cada destinatário deve encerrar a sessão correspondente. O próximo diagrama mostra a cadeia com os métodos e as configurações necessários.
Como o problema aparece no dia a dia
| Situação | Efeito de uma cadeia interrompida |
|---|---|
| Desligamento de funcionário | O acesso é revogado, mas a aplicação continua aberta no notebook e os dados internos permanecem visíveis até a manhã seguinte. |
| Terminais compartilhados | Em uma loja, hospital ou central de atendimento, a pessoa anterior saiu. Mesmo assim, outra aba ainda mostra o painel dela. |
| Dispositivo perdido | A pessoa escolheu “Sair de todos os dispositivos”. Só a sessão que estava usando foi encerrada. |
| Resposta a incidentes | A conta comprometida é bloqueada, mas a sessão do invasor continua válida até expirar. |
| Auditoria | “Demonstre que a saída chega a todos os sistemas.” Não há evidência para apresentar. |
Em nenhum desses casos falta um botão de sair. A tela até muda. Mas o alcance é menor do que se imaginava, e é isso que dificulta perceber o problema.
O caminho pelo navegador perde confiabilidade
Há duas formas de avisar as aplicações. Uma delas encontra cada vez mais limitações.
A certificação do Authrim cobre o recebimento pelo back-channel. Receber uma notificação e encaminhá-la são capacidades que precisam ser verificadas separadamente.
Verificar quem recebe e quem envia
O Authrim atua como Relying Party (RP), solicitando autenticação ao provedor de origem, e como OpenID Provider (OP), oferecendo autenticação às aplicações. Encaminhar a saída exige conformidade com as especificações nos dois papéis.
- Como RP: validar a notificação de saída do provedor de origem e encerrar a sessão correspondente no Authrim.
- Como OP: enviar notificações para que as aplicações conectadas encerrem as sessões correspondentes.
As certificações dos perfis de logout OP e RP fornecem evidências para esses dois papéis. O Authrim tem perfis certificados nos dois lados pelo processo de autocertificação da OpenID Foundation, com seus testes oficiais de conformidade.
A certificação significa que a versão submetida à avaliação passou nos testes de conformidade dos perfis declarados. Ela não garante o encerramento imediato de todas as sessões nas aplicações e na rede de um cliente.
O provedor de origem e cada aplicação precisam oferecer os métodos necessários, com endpoints de notificação e mapeamento de sessões configurados. Desativar uma conta de origem não dispara necessariamente uma notificação de saída. Falhas de entrega, novas tentativas e visibilidade dos erros também precisam ser verificadas na configuração em uso.
As versões e os perfis certificados estão na lista Certified OpenID Relying Parties & Logout Profiles da OpenID Foundation. O processo de certificação explica o alcance dessa avaliação.
Depois de sair, onde ainda existe uma sessão ativa?
Essa é a pergunta ao entregar um terminal compartilhado à próxima pessoa ou encerrar o acesso de um ex-funcionário. O Authrim recebe e envia notificações para conectar o encerramento das sessões entre o provedor de origem e as aplicações. A certificação fornece evidências sobre a implementação; testar os sistemas conectados mostra se a saída alcança o escopo desejado.