Logout único para aplicativos OIDC

Editar online

Com o logout único (SLO), os usuários podem sair de todas as aplicações de logon único simultaneamente. Esse recurso aumenta a segurança ao impedir o acesso não autorizado a qualquer sessão inativa, especialmente quando um dispositivo é compartilhado com outras pessoas.

Ao implementar as funções de logout único (SLO), existem três tipos de sessões.
Sessão de inscrição
Embora o aplicativo utilize o Protocolo de Operações ( OpenID, OP) para autenticar usuários, ele pode rastrear o usuário que efetuou login no aplicativo. Normalmente, um aplicativo rastreia as sessões por meio de um cookie do navegador. O aplicativo é responsável por encerrar a sessão ao fazer o logout.
Servidor de autorização: Provedor de OpenID s (OP) - Sessão
Um servidor de autorização também mantém uma sessão do usuário e a armazena em um cookie. Um servidor de autorização encerra a sessão do usuário durante o logout, juntamente com as autorizações e os tokens relacionados à sessão do usuário.
Identidade, Origem, Sessão
Os usuários podem fazer login usando uma sessão de usuário proveniente de uma fonte de identidade. Ao sair da conta, o usuário também pode querer encerrar essa sessão.
Observação: o logout único não suporta o logout de uma sessão do provedor de identidade. Além disso, não é possível fazer o logout de aplicativos do tipo “ SAML ”. Embora SAML tenha um endpoint semelhante para realizar o logout iniciado pelo IdP-initiated e pelo SP, ele não está integrado ao logout único do OIDC.

Existem dois mecanismos para que um servidor de autorização (OP) notifique o aplicativo de que um logout foi acionado: o canal frontal e o canal traseiro. Em ambos os mecanismos, o aplicativo registra um ponto de extremidade de logout que o servidor de autorização chama. Este endpoint encapsula o código que o aplicativo utiliza para limpar sua sessão. Chamar o endpoint de logout do aplicativo não é confiável, pois IBM® Verify não tem a obrigação de tentar novamente nem de garantir que o aplicativo encerre sua sessão com sucesso. O logout pelo canal secundário é o mecanismo preferido.

Sair do canal principal
O logout no canal frontal, ou logout no lado do cliente, é um método de logout único (SLO) no qual o cliente (geralmente um navegador da Web) se comunica diretamente com o servidor para invalidar a sessão do usuário. Isso geralmente é feito enviando uma solicitação ao servidor para excluir o cookie de sessão ou o token. Em seguida, o servidor responde para confirmar o logout. Esse método é simples e funciona bem em cenários com um único domínio. No entanto, pode não ser adequado para ambientes complexos, com vários domínios ou vários protocolos, devido a possíveis problemas relacionados à comunicação entre domínios e à segurança. Quando você utiliza o mecanismo de canal frontal, o servidor de autorização (OP) exibe <iframe src="frontchannel_logout_uri"> em uma página para acionar uma HTTP GET chamada ao endpoint de logout do aplicativo. O aplicativo pode solicitar ao servidor de autorização que envie o ID da sessão (sid) e as informações do emissor (iss) como parâmetros de consulta adicionais. Se o cliente do aplicativo for criado por meio do registro dinâmico de clientes, defina frontchannel_logout_session_required os metadados do cliente como verdadeiro. IBM VerifyPor exemplo, ao configurar um aplicativ OpenID e na interface de usuário de administração, a configuração fica disponível na guia “Login ”. Role a página até a seção “Configurações de logout único” e marque a caixa de seleção “Sessão obrigatória ”. O aplicativo pode usar essas informações para validar a solicitação e determinar de quais sessões deve encerrar o acesso. Se o sid não corresponder à sessão atual ou recente com o servidor de autorização (OP), o aplicativo poderá ignorar a solicitação de logout.
Nota: O OIDC Front-channel Logout recomenda o uso de um iframe para chamar o endpoint de logout do canal frontal. iframeOs navegadores modernos bloqueiam, por padrão, o envio de cookies de terceiros. Se o domínio do aplicativo for diferente do domínio do servidor de autorização, ele não receberá nenhum cookie, o que pode impedir que o aplicativo faça o logout do usuário corretamente. O usuário precisaria configurar seu navegador para permitir cookies de terceiros para o domínio do servidor de autorização.
Sair do canal secundário
O logout por canal secundário, ou logout do lado do servidor, é um método de logout único (SLO) no qual o provedor de identidade ( IdP ) se comunica diretamente com o provedor de serviços (SP) para invalidar a sessão do usuário. Isso geralmente é feito por meio de um canal seguro estabelecido entre o servidor de autenticação ( IdP ) e o provedor de serviços (SP) durante o processo de autenticação inicial. Ao utilizar o mecanismo de canal secundário, o servidor de autorização (n) realiza uma solicitação POST com o parâmetro ` HTTP ` para o endpoint de logout do aplicativo por meio de uma API de canal secundário direta. O servidor de autorização emite um token JWT de logout que contém as seguintes informações.
Nome da reclamação Uso Descrição
iss Obrigatório Identificador do emissor.
sub Opcional Assunto identificador. Deve estar presente quando sid não estiver presente.
aud Obrigatório Público ou públicos.
iat Obrigatório Emitido na ocasião.
exp Obrigatório Prazo de validade.
jti Obrigatório Identificador único do token.
events Obrigatório http://schemas.openid.net/event/backchannel-logoutObjeto JSON que contém o nome do membro.
sid Opcional Identificador da sessão. Deve estar presente quando sub não estiver presente.
O servidor de autorização (OP) utiliza a mesma configuração para assinar, criptografar ou realizar ambas as operações no token JWT de logout, assim como no token de identificação.
end_session_endpointEm um cenário de logout iniciado pela parte dependente da aplicação (RP), a aplicação aciona o logout redirecionando para o end-point de autorização do servidor de autorização, que está publicado no end-point de descoberta do servidor de autorização. O aplicativo pode enviar os seguintes parâmetros de solicitação.
Nome do Parâmetro Uso Descrição
id_token_hint Recomendado O token de identificação emitido pelo servidor de autorização como uma indicação da sessão autenticada do usuário na aplicação.
logout_hint Opcional Uma indicação ao servidor de autorização sobre o usuário que está saindo da sessão.
ID de cliente Opcional O identificador do cliente do aplicativo.
post_logout_redirect_uri Opcional O URI para o qual o aplicativo solicita que o agente do usuário seja redirecionado após o logout ser realizado.
state Opcional Um valor opaco utilizado pelo aplicativo para manter o estado entre a solicitação de logout e a chamada de retorno ao ponto post_logout_redirect_uri de extremidade.
ui_locales Opcional Os idiomas e alfabetos preferidos do usuário para a interface do usuário.
Quando o id_token_hint não for especificado ou o token de identificação não pertencer ao usuário atualmente conectado, o servidor de autorização perguntará ao usuário se deseja encerrar a sessão no servidor de autorização. Em seguida, da mesma forma que no cenário de logout iniciado pelo OP, o servidor de autorização identifica a lista de aplicativos que foram conectados com a mesma sessão do servidor de autorização (OP). Ele notifica os aplicativos utilizando um dos mecanismos de logout do canal. Então, se o usuário der o consentimento, o servidor de autorização encerra sua própria sessão. Se o post_logout_redirect_uri for especificado e puder ser validado com base na configuração do cliente, ao final do processo de logout, será realizado o redirecionamento para esse URI. Caso contrário, o servidor de autorização exibe o relatório resumido de logout.
Dica: Se você estiver criando um endpoint de logout para um aplicativo personalizado,
Para sair do canal principal
Verify espera que o endpoint de logout do aplicativo responda em até 3 segundos.
Para sair do canal secundário
  • Verify espera que o endpoint retorne um código de status 2xx em caso de sucesso e 400 em caso de erros.
  • Verify espera que o endpoint de logout do aplicativo responda em até 3 segundos.
  • Para uma validação mais rápida do token de logout JWT, o endpoint de logout do aplicativo armazena em cache o Verify endpoint JWKS.