No Chrome 122, a API Desconectar da API de gerenciamento de credenciais federadas (FedCM, na sigla em inglês) 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.
Desconectar API
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 retorna mais tarde à RP, a conta de usuário com o IdP é tratada como uma conta recorrente, o que permite recursos como reautenticação automática e botões personalizados que mostram a conta usada.
Às vezes, os IdPs oferecem uma API para desconectar a conta de uma parte restrita. 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 Desconectar permite que o usuário desconecte a conta do IdP da RP no navegador, bem como no servidor do IdP, sinalizando-a para o endpoint especificado. O usuário precisa passar pela federação de identidade usando a API Federated Credential Management (FedCM). Depois que o usuário é desconectado, ele é tratado como um novo usuário na próxima vez que tentar fazer login na RP usando o IdP.
Desconecte o IdP do RP
Se um usuário já tiver feito login na RP usando o IdP por meio do FedCM, a
relação será memorizada pelo navegador localmente como a lista de contas
conectadas. A 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. A RP precisa transmitir um configURL, o clientId usado
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 de dentro de um iframe sem a política de permissões do FedCM.
- O configURL é inválido ou está faltando o endpoint de desconexão.
- A verificação da Política de Segurança de Conteúdo (CSP) falha.
- Há um pedido 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 Desconectar, o IdP 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 IdP.
{
"accounts_endpoint": "/accounts",
"id_assertion_endpoint": "/assertion",
...
"disconnect_endpoint: "/disconnect"
}
Desconectar a conta no endpoint de desconexão
Invocando IdentityCredential.disconnect(), o navegador envia uma solicitação POST
entre origens com cookies e um tipo de conteúdo de
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 fazer o seguinte:
- Responda à solicitação com o CORS (Compartilhamento de recursos entre origens).
- Verifique se a solicitação contém um cabeçalho HTTP
Sec-Fetch-Dest: webidentity. - Combine o cabeçalho
Origincom a origem da RP determinada porclient_id. Recuse se não houver correspondência. - Encontre a conta que corresponde a
account_hint. - Desconecte a conta do usuário da lista de contas conectadas do RP.
- Responda ao navegador com o
account_iddo 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 à
RP, transmita uma string que não corresponda a nenhum ID da conta, por exemplo, "*".
A verificação de /.well-known/web-identity agora é ignorada quando a parte restrita e o IdP são do mesmo site
Ao desenvolver um sistema FedCM, os testes ou a preparação de domínios de servidor RP podem ser os
subdomínios do servidor do IdP de produção. Por exemplo, o servidor IdP de produção
está em idp.example e o servidor de RP de preparo e o servidor de 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
os desenvolvedores não necessariamente podem colocar arquivos no ambiente de
produção durante o desenvolvimento, isso os impede de testar o FedCM.
A partir do Chrome 122, se o domínio RP e o domínio do IdP forem os mesmos, o Chrome ignorará a verificação do arquivo conhecido. Dessa forma, os desenvolvedores poderão testar nesse cenário.
Os sub-recursos agora podem definir o status de login no 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 evitava logins por meio das solicitações fetch() do
mesmo site
que configuravam 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 gravar o status de login no navegador usando a API Login Status
porque os dois domínios são de origem cruzada e do mesmo site.
Com essa mudança, flexibilizamos o requisito para que a API Login Status seja
o
mesmo site
com todos os ancestrais e tornamos o exemplo acima possível definir
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() na parte restrita. Com essa função, o navegador
envia uma solicitação ao endpoint de desconexão do IdP para que o IdP possa encerrar a
conexão no servidor e, em seguida, no navegador.
Anunciamos que a verificação de /.well-known/web-identity é ignorada quando a RP
e o IdP são o 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.