Implementação de logout e gestão de sessão OIDC: Um guia completo
Explore a autenticação OIDC e a gestão de sessões em profundidade. Aprenda a implementar o logout iniciado pelo RP, IdP e back-channel em OIDC para um manuseamento seguro da sessão.
Explore a autenticação OIDC e a gestão de sessões em profundidade. Aprenda a implementar o logout iniciado pelo RP, IdP e back-channel em OIDC para um manuseamento seguro da sessão.
OpenID Connect (OIDC) é uma camada de identidade simples construída sobre o protocolo OAuth 2.0. Permite aos clientes verificar a identidade do utilizador final com base na autenticação realizada pelo servidor de autorização, bem como obter informações de perfil básicas sobre o utilizador final de uma forma interoperável e semelhante a REST.
OIDC é projetado para ser fácil de usar e implementar, com foco na simplicidade e flexibilidade. É amplamente utilizada para single sign-on (SSO) e verificação de identidade em aplicações web, aplicações móveis e APIs.
Compreender o estado de autenticação e a gestão de sessões em OIDC é crucial. Este artigo explica como as sessões OIDC e o estado de autenticação do utilizador são geridos no contexto das interações entre o Provedor de Identidade (IdP) e a Parte Confiante (RP) ou Provedor de Serviço (SP).
Este artigo inclui vários termos-chave.
Para entender melhor a gestão de sessão OIDC e o estado de autenticação do utilizador, vamos rever brevemente o fluxo de autenticação OIDC para uma aplicação web:
Uma sessão de login é estabelecida quando um utilizador faz login no IdP. Esta sessão é usada para rastrear o estado de autenticação do utilizador no IdP. A sessão geralmente inclui informações como a identidade do utilizador, tempo de autenticação e tempo de expiração da sessão. É criada quando o utilizador faz login pela primeira vez e é mantida até o utilizador fazer logout ou a sessão expirar.
Um cookie de sessão será definido de forma segura no navegador do utilizador para manter o estado da sessão. O cookie de sessão é usado para identificar a sessão do utilizador e autenticar o utilizador para pedidos de autenticação subsequentes. Este cookie é normalmente definido com as flags HttpOnly e Secure para evitar acesso do lado do cliente e garantir comunicação segura.
Para cada RP que o utilizador acede a partir de dispositivos ou navegadores diferentes, será estabelecida uma sessão de login do utilizador separada. Isso significa que o estado de autenticação do utilizador é mantido separadamente para cada RP. Se o utilizador fizer logout de um RP, ainda estará autenticado em outros RPs até a sessão expirar ou o utilizador fizer logout de todos os RPs.
Esta gestão centralizada de sessões também permite que o IdP mantenha um estado de autenticação consistente em múltiplas RPs enquanto a sessão do utilizador estiver ativa e os pedidos de autenticação vierem do mesmo agente do utilizador (dispositivo/navegador). Este mecanismo possibilita capacidades de SSO, onde o utilizador pode aceder a múltiplas RPs sem precisar logar novamente.
Em OIDC, a aplicação cliente (RP) confia nos tokens emitidos pelo IdP para verificar a identidade do utilizador e o estado de autenticação ou autorização. A "sessão de login" no lado do cliente é mantida pelos tokens emitidos pelo IdP.
offline_access for solicitado e concedido, a aplicação cliente pode receber um refresh token. Ele oferece um meio de estender o estado de autenticação do utilizador sem exigir que o utilizador se reautentique. A aplicação cliente pode usar o refresh token para obter um novo access token quando o access token atual expirar. Enquanto o refresh token for válido, o estado de autenticação do utilizador pode ser mantido sem a necessidade de interação do utilizador.A combinação desses tokens permite que a aplicação cliente mantenha o estado de autenticação do utilizador e acesse recursos protegidos em nome do utilizador. A aplicação cliente precisa armazenar com segurança esses tokens e gerir o seu ciclo de vida. (Por exemplo, para aplicações SPA, os tokens podem ser armazenados no armazenamento local ou armazenamento de sessão do navegador. Para aplicações web, os tokens podem ser armazenados nos dados de sessão do lado do servidor ou cookies.)
O processo de logout em OIDC é um conceito multifacetado devido ao envolvimento de sessões de login geridas centralmente pelo IdP e tokens existentes do lado do cliente.
Para desconectar ou revogar o estado de autenticação do utilizador no lado do cliente é relativamente direto. A aplicação cliente pode remover os tokens armazenados (ID token, access token e refresh token) do navegador ou memória do usuário. Esta ação invalida efetivamente o estado de autenticação do usuário no lado do cliente.
Para aplicações web que gerem suas próprias sessões de login de utilizador, passos adicionais podem ser necessários. Estes incluem limpar o cookie de sessão e quaisquer dados de sessão (como tokens emitidos pelo Provedor de Identidade, ou IdP) para garantir que o utilizador esteja completamente desconectado.
O IdP mantém uma sessão centralizada de login para cada utilizador. Enquanto esta sessão estiver ativa, o utilizador pode ser automaticamente reautenticado mesmo que os tokens do lado do cliente tenham sido limpos, permitindo que novos tokens sejam emitidos para a aplicação cliente sem exigir mais interação com o IdP.
Para desconectar completamente um utilizador do IdP, a aplicação cliente (RP) pode iniciar um pedido de desconexão ao IdP. A aplicação (RP) deve redirecionar o utilizador para o endpoint de término de sessão do IdP para terminar a sessão de login e pode limpar os cookies de sessão. Isso garante uma desconexão completa em todas as aplicações (RPs) que partilham a mesma sessão centralizada. Assim que a sessão de login for terminada, sempre que o IdP receber um pedido de token de quaisquer RPs ligadas que partilhem a mesma sessão, o IdP solicitará que o utilizador se reautentique.
Em alguns casos, quando um utilizador se desconecta de uma aplicação (RP), pode querer ser automaticamente desconectado de todas as outras aplicações (RPs) sem qualquer interação adicional do utilizador. Isso pode ser conseguido usando o mecanismo de logout de back-channel.
Quando o IdP recebe um pedido de desconexão de um RP, não só limpa a sessão de login como também envia uma notificação de logout de back-channel para todos os RPs que usam a mesma sessão e têm um endpoint de logout de back-channel registado.
Quando os RPs recebem a notificação de logout de back-channel, podem realizar as ações necessárias para limpar a sessão e os tokens do utilizador, garantindo que o utilizador esteja completamente desconectado de todas as aplicações.