No Chrome 122, a API Desconectar para API Federated Credential Management (FedCM) está disponível. Com a API Desconectar, as partes confiáveis desconectam os usuários da conta do provedor de identidade sem depender de cookies de terceiros. Além disso, há algumas atualizações no tratamento do mesmo site da FedCM.
Desconectar API
Quando um usuário cria uma conta em uma parte confiável (RP, o site que usa o provedor de identidade para autenticação) por meio da federação de identidade, o provedor de identidade (IdP, o serviço que fornece informações de autenticação e conta para outras partes) geralmente registra a conexão no servidor. A conexão armazenada permite que o IdP acompanhe as RPs em que o usuário fez login e otimize a experiência. Por exemplo, para ter uma experiência melhor quando o usuário retornar à RP, a conta de usuário com o IdP é tratada como uma conta de retorno, 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 exige os cookies do IdP. Em um mundo sem cookies de terceiros, quando o usuário visita a RP, não há uma API de navegador para ela se desconectar do IdP. Como pode haver várias contas de IdP do mesmo IdP vinculadas a uma determinada RP, o fluxo de desconexão exige que você saiba qual conta está sendo desconectada.
A API Desconectar permite que o usuário desconecte a conta do IdP da 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 Federated Credential Management (FedCM). Depois que o usuário for desconectado, ele será tratado como um novo usuário na próxima vez que tentar fazer login na RP usando o IdP.
Desconectar o IdP da RP
Se um usuário tiver feito login na RP usando o IdP por FedCM, o
relacionamento será memorizado 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 do usuário que não corresponde necessariamente ao ID da conta que o endpoint da lista de contas forneceu:
// 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 na RP usando o IdP pelo FedCM.
- A API é invocada de dentro de um iframe sem política de permissões do FedCM.
- O configURL é inválido ou não inclui 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, a RP e o IdP são desconectados no navegador, e a promessa é resolvida. As contas de usuário de desconexão são especificadas na resposta do endpoint de desconexão.
Definir o arquivo de configuração do IdP
Para oferecer suporte à API Desconectar, o IdP precisa aceitar um endpoint
de desconexão e fornecer a propriedade disconnect_endpoint
e seu caminho 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
Ao invocar IdentityCredential.disconnect()
, o navegador envia uma solicitação POST
de origem cruzada 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 do cliente da parte restrita. |
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:
- Responda à solicitação com o Compartilhamento de recursos entre origens (CORS, na sigla em inglês).
- Verifique se a solicitação contém um cabeçalho HTTP
Sec-Fetch-Dest: webidentity
. - Corresponda o cabeçalho
Origin
com a origem da RP determinada peloclient_id
. Rejeite se não houver correspondência. - Encontre a conta que corresponde ao
account_hint
. - Desconecte a conta de usuário da lista de contas conectadas do RP.
- Responda ao navegador com o
account_id
do usuário identificado em um formato JSON.
Um exemplo de payload de resposta JSON é assim:
{
"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 de conta, por exemplo, "*"
.
A verificação de /.well-known/web-identity
agora é ignorada quando a RP e o IdP estão no mesmo local
Ao desenvolver um sistema FedCM, os domínios de servidor RP de teste ou preparo podem ser os
subdomínios do servidor IdP de produção. Por exemplo, o servidor do IdP de produção
está em idp.example
, e o servidor da RP de preparo e o 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 é necessariamente possível que os desenvolvedores coloquem arquivos no ambiente de produção durante o desenvolvimento, isso os impede de testar o FedCM.
A partir do Chrome 122, se os domínios da RP e 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 a configuração do 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 evitou logins por meio de solicitações do fetch()
do
mesmo site
para definir o status de login.
Por exemplo, imagine um site que permite que os usuários digitem o nome de usuário e
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 de 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 Desconectar, a FedCM agora pode desconectar a RP do IdP sem depender de cookies de terceiros. Para fazer isso, chame IdentityCredential.disconnect()
na RP. 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 /.well-known/web-identity
é ignorada quando a RP
e o IdP estão no mesmo local para fins de teste. Além disso, agora é possível definir um status
de login por meio de um cabeçalho de resposta HTTP do sub-recurso do IdP no mesmo site.