Implementação de logout e gestão de sessão OIDC: Um guia completo

O que é gestão de sessão OIDC#

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.

• Provedor de Identidade (IdP): O serviço que armazena e autentica as identidades dos utilizadores.
• Provedor de Serviço (SP) ou Parte Confiante (RP): Uma aplicação web ou serviço que fornece serviços aos utilizadores e confia no IdP para a autenticação dos utilizadores.
• Sessão de login ou Sessão de autenticação: A sessão que é estabelecida quando um utilizador faz login no IdP.
• Concessão: A informação centralizada de autenticação e autorização do utilizador que é gerada e gerida pelo IdP.
• Single Sign-On (SSO): Um serviço de sessão e autenticação de utilizadores que permite a um utilizador usar um conjunto de credenciais de login (por exemplo, nome e senha) para aceder a várias aplicações.

Como funciona o fluxo de autenticação OIDC#

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:

1. O utilizador acede à aplicação web (RP).
2. A RP redireciona o utilizador para o provedor OIDC (IdP) para autenticação.
3. O provedor OIDC verifica o estado da sessão de login do utilizador. Se não existir sessão ou a sessão tiver expirado, o utilizador é solicitado a fazer login.
4. O utilizador interage com a página de login para se autenticar.
5. A página de login submete o resultado da interação ao provedor OIDC.
6. O provedor OIDC cria uma nova sessão de login e concessão de autenticação para o utilizador.
7. O provedor OIDC redireciona o utilizador de volta para a RP com um código de autenticação (fluxo de Código de Autorização).
8. A RP recebe o código de autenticação e troca-o por tokens para aceder às informações do utilizador.

O que é gestão de sessão de login RP#

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.

Uma sessão para um único RP#

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.

Sessão centralizada para múltiplas 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.

Estado de autenticação do lado do cliente#

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.

• ID Token: Um token de curta duração que contém informações do utilizador e é usado para verificar a identidade do utilizador autenticado.
• Access Token: Um token que concede acesso a recursos protegidos em nome do utilizador. A duração do token de acesso pode ser curta ou longa, dependendo da configuração. As aplicações cliente podem confiar na validade do token de acesso para determinar o estado de autenticação do utilizador. Se o token de acesso estiver expirado ou for apagado, o utilizador pode ser considerado como "desconectado" ou "não autenticado" e precisa reautenticar-se.
• Refresh Token: Se o escopo 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.)

Mecanismos de logout OIDC#

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.

Limpar tokens e sessão local 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.

Limpar sessão centralizada de login no IdP#

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.

Logout de back-channel OIDC#

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.