Gestão de sessão OIDC

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

OpenID Connect (OIDC) é uma camada de identidade simples construída sobre o protocolo OAuth 2.0. Ele permite que clientes verifiquem a identidade do usuário final com base na autenticação realizada pelo servidor de autorização, bem como obtenham informações básicas de perfil sobre o usuário final de maneira interoperável e semelhante ao REST.

OIDC é projetado para ser fácil de usar e implementar, com um foco em simplicidade e flexibilidade. Ele é amplamente usado para logon único (SSO) e verificação de identidade em aplicativos web, aplicativos móveis e APIs.

Entender o status de autenticação e gestão de sessão no OIDC é crucial. Este artigo explica como as sessões OIDC e o status de autenticação do usuário são geridos no contexto das interações entre o Provedor de Identidade (IdP) e a Parte Confiável (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 identidades de usuários.
• Provedor de Serviço (SP) ou Parte Confiável (RP): Um aplicativo ou serviço web que fornece serviços aos usuários e depende do IdP para a autenticação do usuário.
• Sessão de login ou Sessão de autenticação: A sessão que é estabelecida quando um usuário faz login no IdP.
• Concessão: As informações centralizadas de autenticação e autorização de usuário que são geradas e geridas pelo IdP.
• Logon Único (SSO): Um serviço de sessão e autenticação de usuário que permite a um usuário usar um conjunto de credenciais de login (por exemplo, nome e senha) para acessar múltiplos aplicativos.

Como funciona o fluxo de autenticação OIDC#

Para entender melhor a gestão de sessão e status de autenticação de usuário OIDC, vamos revisar brevemente o fluxo de autenticação OIDC para um aplicativo web:

1. O usuário acessa o aplicativo web (RP).
2. O RP redireciona o usuário para o provedor OIDC (IdP) para autenticação.
3. O provedor OIDC verifica o status da sessão de login do usuário. Se nenhuma sessão existir ou a sessão tiver expirado, o usuário é solicitado a fazer login.
4. O usuário interage com a página de login para ser autenticado.
5. A página de login submete o resultado da interação para o provedor OIDC.
6. O provedor OIDC cria uma nova sessão de login e concessão de autenticação para o usuário.
7. O provedor OIDC redireciona o usuário de volta para o RP com um código de autenticação (fluxo de Código de Autorização).
8. O RP recebe o código de autenticação e o troca por tokens para acessar informações do usuário.

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

Uma sessão de login é estabelecida quando um usuário faz login no IdP. Esta sessão é usada para rastrear o status de autenticação do usuário no IdP. A sessão tipicamente inclui informações como a identidade do usuário, tempo de autenticação e tempo de expiração da sessão. É criada quando o usuário faz login pela primeira vez e é mantida até que o usuário faça logout ou a sessão expire.

Um cookie de sessão será configurado de forma segura no navegador do usuário para manter o estado da sessão. O cookie de sessão é usado para identificar a sessão do usuário e autenticar o usuário para solicitações subsequentes de autenticação. Este cookie é tipicamente configurado com as flags HttpOnly e Secure para prevenir acesso do lado do cliente e garantir comunicação segura.

Uma sessão para RP único#

Para cada RP ao qual o usuário acessa de diferentes dispositivos ou navegadores, uma sessão de login de usuário separada será estabelecida. Isso significa que o status de autenticação do usuário é mantido separadamente para cada RP. Se o usuário fizer logout de um RP, ele ainda será autenticado em outros RPs até que a sessão expire ou o usuário 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 através de múltiplos RPs, desde que a sessão do usuário esteja ativa e as solicitações de autenticação venham do mesmo agente de usuário (dispositivo/navegador). Este mecanismo permite capacidades de SSO, onde o usuário pode acessar múltiplos RPs sem precisar fazer login novamente.

Status de autenticação do lado do cliente#

No OIDC, a aplicação cliente (RP) depende dos tokens emitidos pelo IdP para verificar a identidade do usuário e o status de autenticação ou autorização. A "sessão de login" no lado do cliente é mantida pelos tokens emitidos pelo IdP.

• Token de ID: Um token de curta duração que contém informações do usuário e é usado para verificar a identidade do usuário autenticado.
• Token de Acesso: Um token que concede acesso a recursos protegidos em nome do usuário. A duração do token de acesso pode ser curta ou longa, dependendo da configuração. Aplicações clientes podem depender da validade do token de acesso para determinar o status de autenticação do usuário. Se o token de acesso expirar ou for limpo, o usuário pode ser considerado como "desconectado" ou "não autenticado" e precisar se reautenticar.
• Token de Atualização: Se o escopo offline_access for solicitado e concedido, a aplicação cliente pode receber um token de atualização. Ele fornece um meio de estender o status de autenticação do usuário sem exigir que o usuário se reautentique. A aplicação cliente pode usar o token de atualização para obter um novo token de acesso quando o token de acesso atual expirar. Enquanto o token de atualização for válido, o status de autenticação do usuário pode ser mantido sem a necessidade de interação do usuário.

A combinação desses tokens permite que a aplicação cliente mantenha o status de autenticação do usuário e acesse recursos protegidos em nome do usuário. A aplicação cliente precisa armazenar esses tokens de forma segura e gerenciar 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 desconexão OIDC#

O processo de desconexão no OIDC é um conceito multifacetado devido ao envolvimento de sessões de login geridas pelo IdP centralizado e tokens distribuídos no lado do cliente.

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

Desconectar ou revogar o status de autenticação do usuário no lado do cliente é relativamente simples. A aplicação cliente pode remover os tokens armazenados (token de ID, token de acesso e token de atualização) do navegador do usuário ou da memória. Esta ação efetivamente invalida o status de autenticação do usuário no lado do cliente.

Para aplicações web que gerenciam suas próprias sessões de login de usuário, etapas adicionais podem ser necessárias. Estas 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 usuário esteja completamente desconectado.

Limpar sessão de login centralizada no IdP#

O IdP mantém uma sessão de login centralizada para cada usuário. Enquanto esta sessão estiver ativa, o usuário 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 usuário do IdP, a aplicação cliente (RP) pode iniciar uma solicitação de desconexão ao IdP. A aplicação (RP) deve redirecionar o usuário para o endpoint de finalização de sessão do IdP para terminar a sessão de login e limpar cookies de sessão. Isso garante uma desconexão completa em todas as aplicações (RPs) que compartilham a mesma sessão centralizada. Assim que a sessão de login for terminada, sempre que o IdP receber uma solicitação de token de qualquer RP vinculado que compartilhe a mesma sessão, o IdP solicitará ao usuário que se reautentique.

Logout de back-channel OIDC#

Em alguns casos, quando um usuário se desconecta de uma aplicação (RP), ele também pode querer ser automaticamente desconectado de todas as outras aplicações (RPs) sem qualquer interação adicional do usuário. Isso pode ser realizado usando o mecanismo de logout de back-channel.

Quando o IdP recebe uma solicitação de desconexão de um RP, ele não apenas limpa a sessão de login, mas também envia uma notificação de logout de back-channel para todos os RPs que utilizam a mesma sessão e têm um endpoint de logout de back-channel registrado.

Quando os RPs recebem a notificação de logout de back-channel, eles podem realizar as ações necessárias para limpar a sessão e os tokens do usuário, garantindo que o usuário esteja completamente desconectado de todas as aplicações.