No Chrome 122, a API Desconectar da Credencial federada A API Management (FedCM) está disponível. A A API Desconectar permite que as partes confiáveis desconectem os usuários dos do provedor de identidade sem depender de cookies de terceiros. Além disso, há há algumas atualizações no tratamento de mesmo site do FedCM.
Desconectar API
Quando um usuário cria uma conta em uma parte confiável (RP, na sigla em inglês), o site que usa o provedor de identidade para autenticação) por meio da federação de identidade, do Identity provedor de identidade (IdP, na sigla em inglês): o serviço que fornece informações de autenticação a outras partes) geralmente registra a conexão no servidor. Os dados de rede permite que o IdP monitore as partes interessadas em que o usuário fez login e otimizar a experiência. Por exemplo, para ter uma experiência melhor quando o usuário retorna à parte restrita mais tarde, a conta de usuário com o IdP é tratada como um conta recorrente, o que permite recursos como a reautenticação automática e botões personalizados mostrando a conta usada.
Às vezes, os IdPs oferecem uma API para desconectar a conta de uma parte restrita. No entanto, um O fluxo de desconexão é autenticado e exige os cookies do IdP. Em um mundo sem cookies de terceiros, quando o usuário visita a parte restrita, não há navegador API para a parte restrita se desconectar do IdP. Como pode haver vários IdPs contas do mesmo IdP vinculadas a uma determinada parte restrita, o fluxo de desconexão exige saber qual conta está sendo desconectada.
A conexão API também permite que o usuário desconecte a conta do IdP da parte restrita no navegador. no servidor do IdP, sinalizando-o para o endpoint especificado. O usuário precisa passar pela federação de identidade usando a credencial federada API Management (FedCM). Quando o usuário é desconectado, ele é tratado como um novo na próxima vez que ele tentar fazer login na parte restrita usando o IdP.
Desconectar o IdP da parte restrita
Se um usuário já tiver feito login na parte restrita usando o IdP pelo FedCM, o
é memorizada pelo navegador localmente como a lista de redes
contas de serviço. A parte restrita pode iniciar uma desconexão invocando o
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 o IdP ser desconectado. Uma conta
A dica pode ser uma string arbitrária, desde que o endpoint de desconexão possa identificar
da conta, por exemplo, um endereço de e-mail ou ID de usuário que não necessariamente
correspondem 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
pelos seguintes motivos:
- O usuário não fez login na parte restrita usando o IdP no FedCM.
- A API é invocada de dentro de um iframe sem a política de permissões do FedCM.
- O configURL é inválido ou o endpoint de desconexão não foi informado.
- 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 um resposta, a parte restrita e o IdP são desconectados na navegador e a promessa é resolvida. As contas de usuário desconectadas especificado na resposta do erro endpoint do Google Cloud.
Definir o arquivo de configuração do IdP
Para oferecer suporte à API Desconectar, o IdP deve permitir uma desconexão
endpoint e forneça a propriedade disconnect_endpoint
e seu caminho no IdP
arquivo de configuração.
{
"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 mensagem
Solicitação POST
com cookies e um tipo de conteúdo de
application/x-www-form-urlencoded
a este endpoint de desconexão com o
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 fazer o seguinte:
- Responda à solicitação com o CORS (Cross-Origin Resource, na sigla em inglês) compartilhamento).
- Verifique se a solicitação contém um cabeçalho HTTP
Sec-Fetch-Dest: webidentity
. - Combine o cabeçalho
Origin
com a origem da RP determinada porclient_id
. Rejeite se não forem correspondentes. - Encontre a conta que corresponde a
account_hint
. - Desconecte a conta de usuário da lista de contas conectadas da parte restrita.
- Responder ao navegador com o
account_id
do usuário identificado em um JSON .
Um exemplo de payload JSON de resposta é semelhante ao seguinte:
{
"account_id": "account456"
}
Se o IdP quiser que o navegador desconecte todas as contas associadas a
para a parte restrita, 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, testar ou organizar domínios de servidor RP pode ser
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 servidor do IdP de teste
estão em staging.idp.example
. No entanto, como o arquivo mais conhecido precisa ser colocado
na raiz do eTLD+1 do servidor do IdP, ele precisa estar
idp.example/.well-known/web-identity
e é o servidor de produção. Como
os desenvolvedores talvez não coloquem arquivos no diretório
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 pula a verificação do arquivo conhecido. Dessa forma, os desenvolvedores podem testar para esse caso.
Os sub-recursos agora podem definir o status de login do mesmo site
Antes, o Chrome só permitia a configuração do login
status (por
exemplo, usando o cabeçalho Set-Login: logged-in
) quando a solicitação é a
mesma origem
com todos os ancestrais. Isso impedia logins por meio da
mesmo site
Solicitações fetch()
para definir o status de login.
Por exemplo, pense em um site que permite que os usuários digitem o nome de usuário e
senha em idp.example
, mas as credenciais foram postadas em login.idp.example
com fetch()
. Gravar o status de login no navegador usando o status de login
Não foi possível usar a API 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
as
mesmo site
com todos os ancestrais e possibilita que o exemplo acima defina
Status de login de login.idp.example
usando um cabeçalho HTTP (Set-Login:
logged-in
).
Resumo
Ao usar a API Desconectar, o FedCM agora pode desconectar a parte restrita do IdP
sem depender de cookies de terceiros. Para 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 ele possa encerrar a
no servidor e no navegador.
Anunciamos que a verificação de /.well-known/web-identity
é ignorada quando a parte restrita
e o IdP sejam o mesmo site para fins de teste. Além disso, a configuração de um login
o status com um cabeçalho de resposta HTTP do sub-recurso do IdP do mesmo site agora é
sempre que possível.