Atualizações do FedCM: Desconectar API e duas atualizações

Eiji Kitamura

No Chrome 122, a API Disconnect para a API Federated Credential Management (FedCM) está disponível. A API Disconnect permite que as partes confiáveis desconectem os usuários da conta do provedor de identidade sem depender de cookies de terceiros. Além disso, há algumas atualizações no processamento no mesmo site do FedCM.

API Disconnect

Quando um usuário cria uma conta em uma parte confiável (RP, na sigla em inglês, que é o site que usa o provedor de identidade para autenticação) por meio da federação de identidade, o provedor de identidade (IdP, na sigla em inglês, que é o serviço que fornece informações de autenticação e conta para outras partes) normalmente registra a conexão no servidor. A conexão armazenada permite que o IdP acompanhe os RPs em que o usuário fez login e otimiza a experiência dele. Por exemplo, para ter uma experiência melhor quando o usuário retornar ao RP, a conta de usuário com o IdP é tratada como uma conta de retorno, o que permite recursos como a reautorização automática e botões personalizados que mostram a conta usada.

Às vezes, os IdPs oferecem uma API para desconectar a conta de um RP. No entanto, um fluxo de desconexão é autenticado e requer os cookies do IdP. Em um mundo sem cookies de terceiros, quando o usuário visita o RP, não há uma API de navegador para o RP se desconectar do IdP. Como pode haver várias contas de IdP do mesmo IdP vinculadas a um determinado RP, o fluxo de desconexão precisa saber qual conta está sendo desconectada.

A API Disconnect permite que o usuário desconecte a conta do IdP do RP no navegador e no servidor do IdP, sinalizando-a para o endpoint especificado. O usuário precisa ter passado pela federação de identidade usando a API FedCM. Depois que o usuário é desconectado, ele é tratado como um novo usuário na próxima vez que tentar fazer login no RP usando o IdP.

Desconecte o IdP do RP

Se um usuário já tiver feito login no RP usando o IdP por FedCM, a relação será memorizada pelo navegador localmente como a lista de contas conectadas. O RP pode iniciar uma desconexão invocando a função IdentityCredential.disconnect(). Essa função pode ser chamada em um frame RP de nível superior. O RP precisa transmitir um configURL, o clientId que ele usa no IdP e um accountHint para que o IdP seja desconectado. Uma dica de conta pode ser uma string arbitrária, desde que o endpoint de desconexão possa identificar a conta. Por exemplo, um endereço de e-mail ou ID de usuário que não necessariamente corresponde ao ID da conta fornecido pelo endpoint da lista de contas:

// Disconnect an IdP account "account456" from the RP "https://idp.com/". This is invoked on the RP domain.
IdentityCredential.disconnect({
  configURL: "https://idp.com/config.json",
  clientId: "rp123",
  accountHint: "account456"
});

IdentityCredential.disconnect() retorna um Promise. Essa promessa pode gerar uma exceção pelos seguintes motivos:

  • O usuário não fez login no RP usando o IdP por FedCM.
  • A API é invocada em um iframe sem a política de permissões do FedCM.
  • O configURL é inválido ou não tem o endpoint de desconexão.
  • A verificação da Política de Segurança de Conteúdo (CSP) falha.
  • Há uma solicitação de desconexão pendente.
  • O usuário desativou o FedCM nas configurações do navegador.

Quando o endpoint de desconexão do IdP retorna uma resposta, o RP e o IdP são desconectados no navegador, e a promessa é resolvida. As contas de usuário que estão sendo desconectadas são especificadas na resposta do endpoint de desconexão.

Configurar o arquivo de configuração do IdP

Para oferecer suporte à API Disconnect, o provedor de identidade precisa oferecer suporte a um endpoint de desconexão e fornecer a propriedade disconnect_endpoint e o caminho dela no arquivo de configuração do provedor de identidade.

{
  "accounts_endpoint": "/accounts",
  "id_assertion_endpoint": "/assertion",
  ...
  "disconnect_endpoint: "/disconnect"
}

Desconecte a conta no endpoint de desconexão

Ao invocar IdentityCredential.disconnect(), o navegador envia uma solicitação POST entre origens diferentes com cookies e um tipo de conteúdo application/x-www-form-urlencoded para esse endpoint de desconexão com as seguintes informações:

Propriedade Descrição
account_hint Uma dica para a conta do IdP.
client_id O identificador de cliente do RP. 
POST /disconnect HTTP/1.1
Host: idp.example
Origin: rp.example
Content-Type: application/x-www-form-urlencoded
Cookie: 0x123
Sec-Fetch-Dest: webidentity

account_hint=account456&client_id=rp123

Ao receber a solicitação, o servidor do IdP precisa:

  1. Responda à solicitação com o CORS (Compartilhamento de recursos entre origens).
  2. Verifique se a solicitação contém um cabeçalho HTTP Sec-Fetch-Dest: webidentity.
  3. Correlacione o cabeçalho Origin com a origem do RP determinada pelo client_id. Rejeite se não forem correspondentes.
  4. Encontre a conta que corresponde ao account_hint.
  5. Desconecte a conta do usuário da lista de contas conectadas do RP.
  6. Responda ao navegador com o account_id do usuário identificado em formato JSON.

Um exemplo de payload JSON de resposta é parecido com este:

{
  "account_id": "account456"
}

Se o IdP quiser que o navegador desconecte todas as contas associadas ao RP, transmita uma string que não corresponda a nenhum ID de conta, por exemplo, "*".

A verificação de /.well-known/web-identity agora é ignorada quando o RP e o IdP estão no mesmo site.

Ao desenvolver um sistema FedCM, os domínios de servidor RP de teste ou de pré-produção podem ser os subdomínios do servidor de IdP de produção. Por exemplo, o servidor do IdP de produção está em idp.example, e o servidor de RP e o servidor do IdP de preparo estão em staging.idp.example. No entanto, como o arquivo conhecido precisa ser colocado na raiz do eTLD+1 do servidor do IdP, ele precisa estar em idp.example/.well-known/web-identity e ser o servidor de produção. Como não é possível que os desenvolvedores coloquem arquivos no ambiente de produção durante o desenvolvimento, isso impede que eles testem o FedCM.

A partir do Chrome 122, se o domínio do RP e do IdP forem iguais, o Chrome vai pular a verificação do arquivo conhecido. Dessa forma, os desenvolvedores poderão testar nesse cenário.

Os recursos secundários agora podem definir o status de login do mesmo site

Anteriormente, o Chrome só permitia definir o status de login (por exemplo, usando o cabeçalho Set-Login: logged-in) quando a solicitação era da mesma origem com todos os ancestrais. Isso impedia que os logins fossem feitos pelas solicitações do mesmo site fetch() que definem o status de login.

Por exemplo, pense em um site que permite que os usuários insiram o nome de usuário e a senha em idp.example, mas as credenciais são postadas em login.idp.example com fetch(). Não foi possível registrar o status de login no navegador usando a API Login Status porque os dois domínios são de origem cruzada e estão no mesmo site.

Com essa mudança, relaxamos o requisito de que a API de status de login precisa estar no mesmo site com todos os ancestrais e permitimos que o exemplo acima defina o status de login de login.idp.example usando um cabeçalho HTTP (Set-Login: logged-in).

Resumo

Ao usar a API Disconnect, o FedCM agora pode desconectar o RP do IdP sem depender de cookies de terceiros. Para fazer isso, chame IdentityCredential.disconnect() no RP. Com essa função, o navegador envia uma solicitação para o endpoint de desconexão do IdP para que ele possa encerrar a conexão no servidor e, em seguida, no navegador.

A verificação /.well-known/web-identity é ignorada quando o RP e o IdP estão no mesmo site, para fins de teste. Além disso, agora é possível definir um status de login usando um cabeçalho de resposta HTTP do subrecurso do IdP do mesmo site.