Logout (Sign-out)

O processo de logout no Logto (como um provedor de identidade baseado em OIDC) é um conceito multifacetado devido ao envolvimento tanto da sessão centralizada de login gerenciada pelo Logto quanto do status de autenticação distribuído gerenciado pelos aplicativos clientes.

Sessão de login

Para entender melhor o processo de logout, é importante primeiro compreender como as sessões de login do usuário e seu status de autenticação são gerenciados no Logto.

1. O usuário acessa o aplicativo web (RP).
2. O aplicativo cliente redireciona o usuário para o Logto (IdP) para autenticação (Authentication).
3. O provedor OIDC verifica o status da sessão de login do usuário. Se não existir sessão ou se a sessão tiver expirado, o usuário será solicitado a fazer login.
4. O usuário interage com a página de login para ser autenticado.
5. Após o login bem-sucedido, o Logto cria uma nova sessão para o usuário e redireciona de volta para o aplicativo cliente com um código de autorização.
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 ao cliente com um código de autenticação (Fluxo de Código de Autorização).
8. O cliente recebe o código de autenticação e o troca por tokens para acessar as informações do usuário.
9. Concede tokens ao aplicativo cliente.

Componentes

Sessão de login centralizada gerenciada pelo Logto

No fluxo acima, a sessão de login centralizada é gerenciada pelo Logto. A sessão é criada quando o usuário faz login com sucesso e é destruída quando o usuário faz logout. A sessão também é destruída quando expira.

A sessão de login do Logto é gerenciada usando cookies de sessão. O cookie de sessão é definido quando o usuário faz login. Todas as solicitações de autenticação são validadas em relação ao cookie de sessão. Se o cookie de sessão estiver presente e válido, o usuário será autenticado automaticamente e redirecionado diretamente para o aplicativo cliente com o código de autorização. Caso contrário, o usuário será solicitado a fazer login.

1. Cookie de sessão compartilhado do Logto
   Para um usuário que faz login em vários aplicativos clientes a partir do mesmo agente de usuário (por exemplo, navegador), o usuário terá um cookie de sessão compartilhado sob o domínio do Logto. Isso significa que o usuário só precisa fazer login uma vez e será autenticado automaticamente nos outros aplicativos clientes.

2. Cookie de sessão isolado do Logto
   Para um usuário que faz login em diferentes aplicativos clientes a partir de dispositivos ou navegadores diferentes, o usuário terá cookies de sessão isolados sob o domínio do Logto. Isso significa que o usuário precisa fazer login separadamente para cada aplicativo cliente.

Status de autenticação distribuído gerenciado pelos aplicativos clientes

Cada aplicativo cliente mantém seu próprio status de autenticação. Seja um aplicativo Nativo, SPA ou Web, todos têm sua própria maneira de gerenciar o status de autenticação do usuário.

Após o login bem-sucedido, o aplicativo cliente pode receber um Token de ID (ID token) e um Token de acesso (Access token). O aplicativo cliente pode usar o Token de ID para determinar a identidade do usuário e o Token de acesso para acessar os recursos do usuário. O status de autenticação do usuário é representado pelo tempo de expiração do Token de acesso.

• Aplicativos Nativos e SPA:
  O aplicativo cliente precisa armazenar e gerenciar esses tokens de forma segura para manter o status de autenticação do usuário. Por exemplo, armazenar os tokens no local storage ou session storage, e limpar os tokens quando o usuário fizer logout.
• Aplicativos Web:
  Aplicativos web, como aqueles construídos com frameworks como Next.js, geralmente gerenciam sua própria sessão para usuários autenticados juntamente com os tokens emitidos pelo Logto. Uma vez que o usuário faz login e o app web recebe os tokens do Logto, ele pode armazenar os tokens no lado do cliente como aplicativos SPA, ou pode armazenar os tokens no lado do servidor e gerenciar a sessão usando cookies ou outros mecanismos.

Mecanismos de logout

Limpar tokens e sessão local no lado do cliente

No lado do cliente, um logout simples envolve limpar a sessão local e remover os tokens (Token de ID, Token de acesso, Token de atualização) do local storage ou session storage. Isso resulta em um logout apenas do lado do cliente, onde a sessão centralizada permanece intacta. Usuários que fazem logout dessa maneira ainda podem acessar outros aplicativos sob a mesma sessão do servidor de autorização até que a sessão centralizada expire ou seja destruída ativamente.

Limpar a sessão de login no Logto

Para efetuar o logout explícito do usuário e limpar a sessão no Logto, o aplicativo cliente precisa redirecionar o usuário para o endpoint de encerramento de sessão do Logto.

Exemplo: https://{seu-dominio-logto}/oidc/session/end

O endpoint de encerramento de sessão é um endpoint padrão do OIDC que permite ao aplicativo cliente notificar o servidor de autorização de que o usuário fez logout. O endpoint irá limpar a sessão de login centralizada no Logto.

Uma vez que a sessão é limpa, qualquer solicitação de autorização subsequente exigirá que o usuário faça login novamente.

Se um post-logout redirect URI for fornecido, o usuário será redirecionado para o URI especificado após a sessão ser limpa. Caso contrário, o usuário será redirecionado para a página padrão de pós-logout hospedada pelo Logto.

Logout federado: Back-channel logout

Para um gerenciamento de logout mais consistente, o Logto suporta o back-channel logout. O back-channel logout é um mecanismo que permite ao Logto notificar todos os aplicativos clientes sob a mesma sessão de login quando o usuário faz logout.

Isso é especialmente útil em cenários onde o usuário faz logout de um aplicativo cliente e espera ser desconectado de todos os outros aplicativos clientes sob a mesma sessão de login do Logto.

Para habilitar o back-channel logout para seus aplicativos clientes, acesse a página de detalhes do aplicativo no painel do Logto e registre um URI de back-channel logout. O Logto enviará um token de logout para todos os URIs registrados quando o usuário iniciar uma solicitação de logout de qualquer aplicativo cliente.

Se seu aplicativo cliente exigir que a sessão de login seja incluída no token de logout, ative a configuração Is session required na configuração de back-channel logout. Uma reivindicação sid será incluída no token de logout para identificar a sessão de login do usuário no Logto.

1. O usuário inicia uma solicitação de logout a partir de um aplicativo cliente.
2. O Logto recebe a solicitação de encerramento de sessão, gera um token de logout e envia o token de logout para todos os URIs de back-channel logout registrados.
3. Cada aplicativo cliente recebe o token de logout e executa as ações de logout.

Ações de logout para cada aplicativo cliente ao receber o token de logout:

• Validar o token de logout.
• Limpar a sessão local e remover tokens do local storage ou session storage.

Métodos de logout nos SDKs do Logto

Se você está integrando o Logto com seu aplicativo cliente usando os SDKs do Logto:

• Para aplicativos SPA e web, o método client.signOut() irá limpar o armazenamento local de tokens e redirecionar o usuário para o endpoint de encerramento de sessão do Logto. Você pode especificar um post-logout redirect URI para redirecionar o usuário após a sessão ser limpa.
• Para aplicativos nativos (incluindo apps híbridos como React Native e Flutter), apenas o armazenamento local de tokens é limpo. Isso ocorre porque, em aplicativos nativos, usamos o webview sem sessão para lidar com o processo de login. Nenhum cookie de sessão é armazenado no navegador nativo, então não há necessidade de limpar a sessão de login no Logto. Cada solicitação de autenticação é independente e não carrega cookies de sessão.

nota:

Para aplicativos nativos que não suportam webview sem sessão ou não reconhecem as configurações emphasized (aplicativo Android usando o SDK React Native ou Flutter), você pode forçar o usuário a ser solicitado a fazer login novamente passando o parâmetro prompt=login na solicitação de autorização.

Exigir reautenticação em cada acesso

Em cenários de alta segurança — como verificar a identidade do usuário antes de ações sensíveis — você pode querer exigir que o usuário se reautentique em cada acesso. Para impor esse comportamento, inclua prompt=login em sua solicitação de autenticação.

Definir prompt=login força o Logto a sempre exibir a página de login, independentemente de o usuário ter uma sessão ativa ou ter feito login recentemente. Isso ignora o comportamento de autenticação única (SSO) e garante que o usuário seja solicitado a inserir suas credenciais a cada vez.

Se seu aplicativo solicitar o escopo offline_access (para receber um Token de atualização), a especificação OpenID Connect exige que você também inclua prompt=consent. Na maioria dos casos, para impor tanto a reautenticação quanto garantir a emissão do Token de atualização, defina:

prompt=login consent

Isso garante que o usuário seja reautenticado e consinta explicitamente com o acesso offline.

Perguntas frequentes

Não estou recebendo as notificações de back-channel logout.

• Certifique-se de que o URI de back-channel logout está corretamente registrado no painel do Logto.
• Certifique-se de que seu aplicativo cliente possui uma sessão de login ativa válida e é a mesma sessão que iniciou a solicitação de logout.

Recursos relacionados

Entendendo o back-channel logout do OIDC.