Gestão de sessão OIDC

O que é a 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 verificarem a identidade do utilizador final com base na autenticação realizada pelo servidor de autorização, assim como obter informações básicas de perfil sobre o utilizador final de forma interoperável e semelhante a REST.

OIDC é projetado para ser fácil de usar e implementar, com foco na simplicidade e flexibilidade. É amplamente utilizado para single sign-on (SSO) e verificação de identidade em aplicações web, apps móveis e APIs.

Compreender o estado de autenticação e a gestão de sessão 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 Proveedor de Identidade (IdP) e a Entidade Confiável (RP) ouProveedor de Serviços (SP).

Este artigo inclui vários termos-chave.

• Proveedor de Identidade (IdP): O serviço que armazena e autentica identidades de utilizadores.
• Proveedor de Serviços (SP) ou Entidade Confiável (RP): Uma aplicação web ou serviço que fornece serviços aos utilizadores e depende do IdP para autenticação de utilizadores.
• Sessão de entrada ou Sessão de autenticação: A sessão que é estabelecida quando um utilizador faz login no IdP.
• Consentimento: As informações centralizadas de autenticação e autorização do utilizador que são geradas e geridas pelo IdP.
• Single Sign-On (SSO): Um serviço de sessão e autenticação de utilizador que permite que um utilizador use 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 compreender melhor a gestão de sessão e estado de autenticação do utilizador em OIDC, vamos rever brevemente o fluxo de autenticação OIDC para uma aplicação web:

1. O utilizador acede à aplicação web (RP).
2. O 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 nenhuma sessão existe ou a sessão expirou, o utilizador é solicitado a fazer login.
4. O utilizador interage com a página de login para ser autenticado.
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 o RP com um código de autenticação (Autorização pelo fluxo de Código).
8. O RP recebe o código de autenticação e troca-o por tokens para aceder às informações do utilizador.

O que é a gestão de sessão de login do 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é que o utilizador faça logout ou a sessão expire.

Um cookie de sessão será configurado 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 solicitações subsequentes de autenticação. Este cookie é tipicamente configurado com os sinais HttpOnly e Secure para prevenir 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, uma sessão de login do utilizador separada será estabelecida. Isso significa que o estado de autenticação do utilizador é mantido separadamente para cada RP. Se o utilizador faz logout de um RP, o utilizador ainda estará autenticado em outros RPs até que a sessão expire ou o utilizador faça logout de todos os RPs.

Sessão centralizada para múltiplos RPs#

Esta gestão de sessão centralizada também permite ao IdP manter um estado de autenticação consistente em múltiplos RPs, desde que a sessão do utilizador esteja ativa e as solicitações de autenticação venham do mesmo agente de utilizador (dispositivo/navegador). Este mecanismo permite capacidades de SSO, onde o utilizador pode aceder a múltiplos RPs sem precisar fazer login novamente.

Estado de autenticação do lado do cliente#

Em OIDC, a aplicação cliente (RP) depende dos tokens emitidos pelo IdP para verificar a identidade do utilizador e o estado de autenticação ou autorização. A "sessão de login" do 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. O tempo de vida do token de acesso pode ser de curta ou longa duração, dependendo da configuração. As aplicações clientes podem depender da validade do token de acesso para determinar o estado de autenticação do utilizador. Se o token de acesso expirar ou for limpo, o utilizador pode ser considerado "desconectado" ou "não autenticado" e precisar autenticar novamente.
• Refresh Token: Se o escopo offline_access for solicitado e concedido, a aplicação cliente pode receber um refresh token. Ele fornece um meio de estender o estado de autenticação do utilizador sem exigir que o utilizador se autentique novamente. A aplicação cliente pode usar o refresh token para obter um novo token de acesso quando o atual expirar. Enquanto o refresh token for válido, o estado de autenticação do utilizador pode ser mantido sem a necessidade de interações do utilizador.

A combinação destes tokens permite que a aplicação cliente mantenha o estado de autenticação do utilizador e aceda a recursos protegidos em nome do utilizador. A aplicação cliente precisa armazenar esses tokens de forma segura e gerir seu ciclo de vida. (Por exemplo, para aplicações SPA, os tokens podem ser armazenados no armazenamento local ou 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 centralizadas geridas pelo IdP e tokens distribuídos do lado do cliente.

Limpar tokens e sessão local no lado do cliente#

Fazer logout ou revogar o estado de autenticação de um utilizador do lado do cliente é relativamente simples. A aplicação cliente pode remover os tokens armazenados (token de ID, token de acesso e refresh token) do navegador ou memória do utilizador. Esta ação invalida efetivamente o estado de autenticação do utilizador no lado do cliente.

Para aplicações web que gerem suas próprias sessões de login do utilizador, etapas adicionais podem ser necessárias. Estas incluem limpar o cookie de sessão e quaisquer dados de sessão (como tokens emitidos pelo Proveedor de Identidade ou IdP) para garantir que o utilizador esteja totalmente desconectado.

Limpar sessão de login centralizada no IdP#

O IdP mantém uma sessão de login centralizada para cada utilizador. Enquanto esta sessão estiver ativa, o utilizador pode ser automaticamente reautenticado, mesmo se os tokens do lado do cliente forem limpos, permitindo que novos tokens sejam emitidos para a aplicação cliente sem exigir mais interação com o IdP.

Para desconectar totalmente um utilizador do IdP, a aplicação cliente (RP) pode iniciar uma solicitação de logout ao IdP. A aplicação (RP) deve redirecionar o utilizador para o endpoint de finalização de sessão do IdP para terminar a sessão de login e limpar cookies de sessão. Isto garante um logout completo em todas as aplicações (RPs) que partilham a mesma sessão centralizada. Uma vez terminada a sessão de login, sempre que o IdP receber uma solicitação de token de qualquer RP ligado que partilhe a mesma sessão, o IdP solicitará que o utilizador se autentique novamente.

Logout pelo canal traseiro OIDC#

Em alguns casos, quando um utilizador faz logout de uma aplicação (RP), pode querer também ser desconectado automaticamente de todas as outras aplicações (RPs) sem qualquer interação adicional do utilizador. Isto pode ser realizado usando o mecanismo logout pelo canal traseiro.

Quando o IdP recebe uma solicitação de logout de um RP, não só limpa a sessão de login, mas também envia uma notificação de logout pelo canal traseiro para todos os RPs que usam a mesma sessão e têm um endpoint de logout pelo canal traseiro registrado

Quando os RPs recebem a notificação de logout pelo canal traseiro, eles podem realizar as ações necessárias para limpar a sessão e os tokens do utilizador, garantindo que o utilizador esteja totalmente desconectado de todas as aplicações.