---
url: 'https://www.corbado.com/pt/blog/chaves-de-acesso-vinculadas-dispositivo-vs-sincronizadas'
title: 'Chaves de acesso vinculadas ao dispositivo vs. sincronizadas (SCA e chaves de acesso I)'
description: 'Explore chaves de acesso sincronizadas e vinculadas ao dispositivo, suas diferenças e o papel dos módulos de segurança de hardware (Secure Enclave, TEE, TPM).'
lang: 'pt'
author: 'Vincent Delitz'
date: '2026-05-24T16:35:30.162Z'
lastModified: '2026-10-03T06:02:44.874Z'
keywords: 'chaves de acesso vinculadas ao dispositivo, chaves de acesso sincronizadas, passkeys, dispositivo de chave de acesso'
category: 'Passkeys Strategy'
---

# Chaves de acesso vinculadas ao dispositivo vs. sincronizadas (SCA e chaves de acesso I)

## Visão geral: Autenticação forte de clientes com chaves de acesso

- Análise dos requisitos da [PSD2](https://www.corbado.com/blog/psd2-passkeys) e [SCA](https://www.corbado.com/pt/blog/psd2-passkeys)
- O que os requisitos de [SCA](https://www.corbado.com/pt/blog/psd2-passkeys) significam para as
  [chaves de acesso](https://www.corbado.com/pt/glossary/cda)
- Implicações da [PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) / [PSR](https://www.corbado.com/blog/psd3-psr-passkeys) para as
  [chaves de acesso](https://www.corbado.com/pt/glossary/cda)

## 1. Introdução: Chaves de acesso vinculadas ao dispositivo vs. sincronizadas

No nosso post anterior sobre [chaves de acesso](https://www.corbado.com/pt/glossary/cda) e
[PSD2](https://www.corbado.com/blog/psd2-passkeys), discutimos como as chaves de acesso já estão sendo usadas por
fintechs como [Revolut](https://www.corbado.com/blog/revolut-passkeys) e [Finom](https://www.corbado.com/blog/finom-passkeys) e como
elas melhoram a [segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) digital no
[setor bancário](https://www.corbado.com/passkeys-for-banking).

As chaves de acesso vêm em dois formatos principais: **chaves de acesso sincronizadas** e
**chaves de acesso vinculadas ao dispositivo**. Enquanto as chaves de acesso sincronizadas
permitem que os usuários se autentiquem de forma contínua em vários dispositivos, as
**chaves de acesso vinculadas ao dispositivo** estão estritamente ligadas a um dispositivo
de [chave de acesso](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve), como uma
[chave de segurança](https://www.corbado.com/pt/blog/melhores-fido2-chaves-de-seguranca-hardware) de hardware ou
um autenticador local.

Com esta série de quatro artigos, queremos analisar detalhadamente como os diferentes
tipos de chaves de acesso (vinculadas ao dispositivo vs. sincronizadas) cumprem os
requisitos de [SCA](https://www.corbado.com/pt/blog/psd2-passkeys) e [PSD2](https://www.corbado.com/blog/psd2-passkeys).

Esta primeira parte da série [visa](https://www.corbado.com/blog/visa-passkeys) entender a **diferença entre
chaves de acesso vinculadas ao dispositivo e sincronizadas**.

A segunda parte explica o que significa a PSD2 e a
[Autenticação](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) Forte de Clientes (SCA)
de forma compreensível, expondo também o seu desenvolvimento histórico.

A terceira parte da série mostra como os diferentes tipos de chaves de acesso cumprem a
SCA e o que isso significa para bancos, fintechs e instituições financeiras que pensam em
adotar chaves de acesso.

A quarta e última parte da série conclui o que a [PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) /
[PSR](https://www.corbado.com/blog/psd3-psr-passkeys) significará para a SCA e as chaves de acesso no futuro.

## 2. Autenticação forte de clientes, PSD2 e chaves de acesso

Após a publicação do nosso último post, recebemos muitas perguntas de acompanhamento sobre
a nossa posição em relação às chaves de acesso, especificamente em relação à SCA no âmbito
da estrutura da PSD2. Existe um interesse claro em entender não apenas a aplicação das
chaves de acesso, mas também como elas se alinham com as **Normas Técnicas Regulamentares
(RTS)**. Além disso, as partes interessadas estão curiosas sobre as possíveis
interpretações e orientações de reguladores, incluindo a **Autoridade Bancária Europeia
(EBA)**, sobre o uso de chaves de acesso.

Reconhecendo isso, pretendemos aprofundar como as chaves de acesso podem ser integradas na
diretiva PSD2, nas RTS sobre a SCA, e fornecer clareza sobre nossa posição em relação ao
uso dessa tecnologia. Também exploraremos as perguntas e respostas existentes da EBA para
esclarecer como os reguladores e a EBA podem perceber as chaves de acesso. Esta análise
não apenas abordará as distinções entre chaves de acesso sincronizadas e vinculadas ao
dispositivo, mas também suas aplicações práticas na melhoria da
[segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) e da experiência do usuário.

Ao compreender as nuances, as partes interessadas podem tomar decisões informadas que não
só cumprem os rigorosos requisitos da PSD2, mas também aproveitam a mais recente
tecnologia de [autenticação](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) para
proteger as transações digitais. A nossa discussão [visa](https://www.corbado.com/blog/visa-passkeys) iluminar
ainda mais o caminho para a integração de chaves de acesso nos processos de
[autenticação](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys), garantindo que as
medidas de [segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) acompanhem o cenário
digital em evolução.

Obviamente, toda entidade regulamentada que se enquadra na PSD2 precisa tomar suas
próprias decisões sobre como cumprir as metas regulatórias, já que cada implementação tem
suas próprias complexidades. Esta abordagem individual reconhece que, embora o quadro
regulamentar forneça um padrão uniforme, a aplicação prática destas normas variará
significativamente entre diferentes organizações devido aos seus ambientes operacionais,
capacidades tecnológicas e bases de usuários únicos.

Assim, embora os nossos insights tenham como objetivo orientar e informar, não são
prescritivos. Cada entidade deve considerar as suas circunstâncias e desafios específicos
ao integrar chaves de acesso nos seus protocolos de segurança e autenticação.

[Watch on YouTube](https://www.youtube.com/watch?v=V1Pc4Gl0xKc)

## 3. Das chaves de acesso vinculadas ao dispositivo às chaves de acesso sincronizadas

Para entender a diferenciação entre chaves de acesso vinculadas ao dispositivo e
sincronizadas, exploraremos brevemente como o ecossistema se desenvolveu.

### 3.1 O que são chaves de acesso vinculadas ao dispositivo (chaves de acesso de dispositivo único)?

Começamos olhando para a história e a evolução das chaves de acesso vinculadas ao
dispositivo antes de examinar mais a fundo seus detalhes técnicos.

![Chave de acesso vinculada ao dispositivo](https://www.corbado.com/website-assets/device_bound_passkey_effe25ab99.png)

#### 3.1.1 História das chaves de acesso vinculadas ao dispositivo

Historicamente, os mecanismos de autenticação do WebAuthn (o padrão subjacente às chaves
de acesso) estavam fortemente acoplados a dispositivos físicos: chaves de segurança (por
exemplo, YubiKeys). Antes da ampla adoção das chaves de acesso, as
[credenciais FIDO2 vinculadas a um único autenticador representavam o padrão-ouro](https://github.com/w3c/webauthn/wiki/Explainer:-broadening-the-user-base-of-WebAuthn)
em segurança. Estas credenciais estão ligadas ao dispositivo em que residem. A implicação
desta vinculação foi significativa: a credencial não podia ser transferida ou utilizada
fora do seu hardware original.

Esta abordagem, embora aumentasse a segurança ao localizar o processo de autenticação num
único dispositivo, inevitavelmente encontrou limitações práticas que afetaram a sua ampla
adoção, especialmente entre os consumidores gerais não técnicos. Os usuários eram forçados
a ter o seu dispositivo de autenticação disponível para cada tentativa de login, o que não
só limitava a mobilidade do usuário, como também levantava preocupações em cenários onde o
dispositivo era perdido, danificado ou não estava imediatamente acessível.

Além disso, também havia relutância dos consumidores em investir em hardware adicional.
Historicamente, a propriedade e a utilização de chaves de segurança dedicadas têm sido
muito baixas entre os consumidores gerais. A perspectiva de comprar hardware especializado
para fins de autenticação, apesar dos seus benefícios de segurança aprimorados, não teve
boa aceitação pela maioria dos usuários B2C, que ao mesmo tempo são geralmente os alvos de
amplas campanhas de [phishing](https://www.corbado.com/glossary/phishing) ou ataques de preenchimento de
credenciais (_credential stuffing_).

#### 3.1.2 Detalhes técnicos das chaves de acesso vinculadas ao dispositivo

As **chaves de acesso vinculadas ao dispositivo** caracterizam-se pela sua categorização
específica em credenciais detectáveis e não detectáveis, uma distinção que define
principalmente a sua capacidade de detecção. Mas o fator chave que distingue as **chaves
vinculadas ao dispositivo** está encapsulado nas propriedades da credencial WebAuthn,
particularmente através dos sinalizadores `isBackupEligible` e `isBackupSynchronized`.
Para **chaves de acesso vinculadas ao dispositivo**, ambos os campos são definidos como
zero, indicando que as credenciais não são elegíveis para backup ou sincronização entre
dispositivos. Estas características sublinham a sua ligação intrínseca ao dispositivo
físico onde foram criadas, garantindo que a credencial permanece ligada a esse hardware
específico e utilizável apenas nele.

Um exemplo notável de credenciais vinculadas ao dispositivo na prática é observado no
ecossistema Windows. As credenciais do [Windows Hello](https://www.corbado.com/glossary/windows-hello) no Windows
10 e [Windows 11](https://www.corbado.com/blog/passkeys-windows-11) permanecem vinculadas ao dispositivo — o
próprio [Windows Hello](https://www.corbado.com/glossary/windows-hello) ainda não sincroniza as chaves de acesso
entre dispositivos. No entanto, a Microsoft deu um primeiro passo significativo ao
[introduzir a funcionalidade de salvar e sincronizar chaves de acesso no Microsoft Edge](https://blogs.windows.com/msedgedev/2025/11/03/microsoft-edge-introduces-passkey-saving-and-syncing-with-microsoft-password-manager/)
(a partir do Edge 142). Essa sincronização no nível do navegador por meio do Microsoft
[Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers) permite que as chaves de acesso
sejam sincronizadas entre dispositivos Windows ao usar o Edge, de forma semelhante a como
o [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) permite a
sincronização de chaves de acesso no navegador Chrome no Windows. Isto representa um
avanço importante nos recursos de chaves de acesso do Windows, embora seja específico para
o navegador Edge, em vez do autenticador de plataforma
[Windows Hello](https://www.corbado.com/glossary/windows-hello). As chaves de acesso do Windows Hello permanecem
vinculadas ao dispositivo, mas esta integração do Edge fornece um caminho prático em
direção a chaves de acesso sincronizadas no Windows, enquanto o próprio autenticador da
plataforma pode evoluir para oferecer suporte à sincronização no futuro.

Por outro lado, o Google articulou uma postura clara em relação a chaves de acesso não
detectáveis, indicando que as chaves de acesso não detectáveis existentes poderão
permanecer não sincronizadas em implementações futuras. Essa decisão alinha-se com o
princípio mais amplo de que credenciais não detectáveis desempenham um papel crucial em
determinados contextos de segurança, permanecendo estritamente vinculadas ao dispositivo
e, por não serem detectáveis, não podem ser usadas como chaves de acesso.

Em contraste, a abordagem adotada pela Apple com o macOS e
[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) difere significativamente. Ao contrário da
estratégia fixa e vinculada ao dispositivo observada com o Windows e as chaves não
detectáveis do Google,
[o ecossistema da Apple tem uma tendência muito mais forte de permitir apenas chaves de acesso sincronizadas, especialmente no iOS](https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/),
tornando assim impossível criar uma
[chave de acesso vinculada ao dispositivo](https://www.corbado.com/pt/faq/login-segundo-dispositivo-chave-de-acesso-vinculada)
via WebAuthn.

Esta segmentação de estratégias nas principais plataformas ilustra as diversas abordagens
à gestão de credenciais WebAuthn, especialmente ao considerar o equilíbrio entre
segurança, conveniência e acessibilidade do usuário. Embora as chaves de acesso vinculadas
ao dispositivo ofereçam um elevado nível de segurança ao garantir que as credenciais não
possam ser movidas ou mal utilizadas fora do seu dispositivo pretendido, a indústria
continua a evoluir, buscando soluções que mantenham os padrões de segurança sem
comprometer a experiência e a mobilidade do usuário.

### 3.2 O que são chaves de acesso sincronizadas (chaves de acesso de vários dispositivos)?

Aqui também, damos uma olhada no desenvolvimento histórico das chaves de acesso
sincronizadas antes de analisar os detalhes técnicos. Às vezes, as chaves de acesso
sincronizadas também são chamadas de **chaves de acesso sincronizáveis**.

![Chave de acesso sincronizada](https://www.corbado.com/website-assets/synced_passkey_042125aca6.png)

#### 3.2.1 História das chaves de acesso sincronizadas

Após a publicação das especificações WebAuthn Level 2 e
[CTAP](https://www.corbado.com/blog/passkeys-explained-clearly) 2.1 em meados do final de 2021, o grupo de
trabalho WebAuthn lançou uma iniciativa significativa na indústria visando superar os
principais obstáculos que impediam a capacidade do padrão WebAuthn de substituir senhas e
aumentar a adoção. Esta iniciativa concentrou-se em duas áreas críticas: eliminar o
requisito de dispositivos de segurança de hardware adicionais e mitigar o risco associado
à perda do autenticador, mantendo ao mesmo tempo total compatibilidade com os padrões
existentes.

##### 3.2.1.1 Utilização de autenticadores de plataforma como módulos de hardware seguros

O primeiro desafio — erradicar a necessidade de novo hardware — foi resolvido através da
utilização de autenticadores de plataforma integrados encontrados em dispositivos de
consumo modernos (por exemplo, Touch ID, [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Windows
Hello).

![Módulos de segurança de hardware HSM TPM TEE Secure Enclave](https://www.corbado.com/website-assets/hardware_security_modules_hsm_tpm_tee_secure_enclave_11118d359e.png)

Os dispositivos modernos estão cada vez mais equipados com módulos de segurança
especializados, como o Trusted Execution Environment (TEE) no
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), o
[Secure Enclave](https://www.corbado.com/glossary/secure-enclave) no [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) e
macOS, e o Trusted Platform Module (TPM) nos dispositivos Windows. Estes repositórios de
chaves de segurança essenciais servem como uma base sólida para as chaves de acesso,
funcionando efetivamente como "chaves de segurança" integradas. Essa abordagem permite a
adoção generalizada de
[criptografia de chave pública](https://www.corbado.com/pt/blog/webauthn-pubkeycredparams-credentialpublickey),
um nível de segurança anteriormente alcançável apenas através de chaves de segurança de
hardware externas (por exemplo, YubiKeys), e amplamente restrito a indivíduos com
conhecimentos técnicos ou organizações de setores altamente regulamentados.

Ao aproveitar as capacidades do TEE, [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) ou TPM, os
protocolos WebAuthn são capacitados para fornecer mecanismos de autenticação de usuários
fortes e criptográficos. Agora, métodos sofisticados de autenticação tornam-se fáceis de
usar e acessíveis ao público em geral, sem a necessidade de hardware especializado
adicional.

Esta evolução é uma melhoria muito forte na abordagem à segurança digital, enfatizando o
papel crítico que as soluções de segurança centradas no usuário desempenham na promoção de
uma adoção generalizada. Organizações que combinam chaves de acesso sincronizadas com
fluxos otimizados de criação e login de chaves de acesso observam as taxas de adoção mais
altas. Ao usar recursos de segurança de dispositivos contemporâneos, o esforço da
indústria resolveu com sucesso o obstáculo inicial de remover a necessidade de hardware
externo.

Este desenvolvimento foi um passo crucial em uma nova era do ecossistema de autenticação
digital, onde a ampla aplicação da
[criptografia de chave pública](https://www.corbado.com/pt/blog/webauthn-pubkeycredparams-credentialpublickey)
torna-se diretamente aplicável a uma ampla gama de casos de uso e, ao mesmo tempo,
simplifica a autenticação para os usuários.

##### 3.2.1.2 Sincronização de chaves de acesso na nuvem

A fim de enfrentar o risco associado à perda do celular e, por extensão, das chaves de
acesso nele armazenadas, a iniciativa do setor concentrou-se em permitir a sincronização
de credenciais detectáveis na nuvem. Esta abordagem efetivamente transformou as
credenciais, que deixaram de ser estritamente vinculadas ao dispositivo para se tornarem
utilizáveis em vários dispositivos e, mais precisamente, vinculadas à conta do usuário no
seu provedor de nuvem, como o iCloud para dispositivos Apple ou o Google para dispositivos
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android).

Essa solução prática significou que mesmo que o telefone do usuário fosse perdido ou
substituído, as credenciais estabelecidas anteriormente não seriam permanentemente
perdidas. Em vez disso, essas credenciais poderiam ser recuperadas da conta de nuvem do
usuário e sincronizadas com um novo dispositivo. Essa mudança reduziu significativamente
os inconvenientes e os riscos de segurança anteriormente associados à perda de um
autenticador físico.

Ao aproveitar a sincronização em nuvem, as chaves de acesso podem agora transitar de forma
contínua entre os dispositivos de um usuário, mantendo a sua integridade e segurança
independentemente do dispositivo específico em uso. Por exemplo, quando um usuário faz
login em um site a partir de um novo dispositivo, as credenciais disponíveis em sua conta
de nuvem podem ser sugeridas automaticamente para autenticação. Se necessário, essas
credenciais podem ser transmitidas para o novo dispositivo, mantendo uma experiência de
autenticação consistente e segura em diferentes plataformas e dispositivos.

Esta transição para credenciais vinculadas a contas e sincronizadas na nuvem representa
uma abordagem pragmática da segurança digital. Ela reconhece a realidade do uso de
dispositivos modernos e a ocorrência comum de trocas de dispositivos, seja por perda, dano
ou atualização. Ao vincular credenciais à conta de nuvem do usuário – seja no iCloud da
Apple ou nos serviços de nuvem do Google – a solução não apenas mitiga o risco associado à
perda de um dispositivo, mas também melhora a capacidade do usuário de gerenciar e
recuperar a sua [identidade digital](https://www.corbado.com/pt/blog/digital-credentials-api) em vários
dispositivos.

Este desenvolvimento amplia efetivamente a aplicabilidade dos mecanismos de autenticação
forte e criptográfica do WebAuthn, tornando-os mais adaptáveis a cenários reais dos
usuários. Também garante que uma autenticação forte seja acessível e gerenciável não
apenas para aqueles com formação técnica ou para os que estão em setores altamente
regulamentados, mas para o usuário comum navegando no mundo digital com vários
dispositivos.

#### 3.2.2 Detalhes técnicos das chaves de acesso sincronizadas

As chaves de acesso sincronizadas também são conhecidas como credenciais detectáveis ou
chaves residentes. Estas distinguem-se das chaves vinculadas ao dispositivo por duas
propriedades críticas: `isBackupEligible` e `isBackedUp` possuem valores diferentes. Para
chaves de acesso sincronizadas, o sinalizador `isBackupEligible` é definido como 1,
indicando que essas credenciais são elegíveis para backup. Após a sincronização
bem-sucedida para a nuvem, o sinalizador `isBackedUp` também é definido como 1,
confirmando que a credencial foi devidamente sincronizada. É importante observar que o
status da sincronização pode mudar com o tempo, refletindo a natureza dinâmica do uso e da
gestão de dispositivos.

Quando as plataformas solicitam chaves residentes, definindo o parâmetro
"requireResidentKey" como **required** ou **preferred**, as plataformas que suportam
serviços de nuvem criam automaticamente chaves de acesso sincronizadas. Este processo
garante que os usuários possam confiar que as suas credenciais estarão acessíveis em seus
vários dispositivos. No Windows, as chaves de acesso sincronizadas estão agora disponíveis
por meio do Microsoft Edge/Microsoft
[Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers) (sincronização no nível do
navegador), enquanto as credenciais do autenticador da plataforma Windows Hello permanecem
vinculadas ao dispositivo. Gerenciadores de senhas de terceiros (por exemplo,
[Dashlane](https://www.corbado.com/blog/dashlane-passkeys), [KeePassXC](https://www.corbado.com/blog/keepassxc-passkeys),
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis)) com recursos de gestão de
chaves de acesso também fornecem sincronização em várias plataformas. Em cenários em que
chaves de acesso sincronizadas são usadas, os sinalizadores `isBackupEligible` e
`isBackedUp` são definidos como 1, indicando elegibilidade para backup e sincronização
bem-sucedida.

Além disso, embora atualmente ainda seja possível identificar o autenticador específico
onde a [chave de acesso](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) foi armazenada, a
ausência de [atestado](https://www.corbado.com/pt/glossary/attestation) para a maioria destas credenciais
significa que a sua origem não pode ser verificada criptograficamente. Este aspecto
destaca uma possível limitação na garantia da linhagem de segurança de chaves de acesso
sincronizadas unicamente por meio dos mecanismos padrão do WebAuthn.

Este desenvolvimento em chaves de acesso sincronizadas amplia essencialmente o escopo de
credenciais detectáveis ao integrá-las num framework de sincronização baseada em nuvem. Ao
tornar essas chaves elegíveis para backup e garantir a sua sincronização entre os
dispositivos de um usuário, o WebAuthn aborda dois dos principais desafios na autenticação
digital: o risco de perda de acesso devido à perda de dispositivos e o inconveniente de
gerenciar múltiplas credenciais vinculadas ao dispositivo.

### 3.3 Vínculo a dispositivo único de credenciais WebAuthn sacrificado em prol de um bem maior

A transição de chaves de acesso vinculadas ao dispositivo para sincronizadas iniciou um
diálogo crítico no grupo de trabalho WebAuthn, centrado na necessidade de medidas de
segurança avançadas, nas questões legais envolvidas e em um compromisso que fosse fácil
para o consumidor e seguro.

A [adoção de chaves de acesso](https://www.corbado.com/pt/blog/por-que-implementacoes-de-chaves-de-acesso-falham)
sincronizadas foi celebrada pela sua promessa de melhorar a conveniência e a segurança do
usuário através de recursos como sincronização na nuvem e funcionalidade contínua em
vários dispositivos. No entanto, introduziu algum desconforto entre algumas partes
dependentes (RPs - _Relying Parties_), especialmente em relação às implicações para a
segurança e conformidade em ambientes com requisitos elevados. A essência do debate foi a
exigência de um mecanismo que garantisse que mesmo as chaves de acesso sincronizadas
mantivessem uma conexão com dispositivos específicos, um conceito crucial para as partes
dependentes que lidam com transações sensíveis ou operam sob padrões regulatórios
rigorosos.

Para os RPs incapazes ou não dispostos a adotar chaves de acesso, a ausência de um método
confiável para vincular estas credenciais a dispositivos específicos em aplicações
críticas representava um desafio significativo. Um mecanismo assim foi considerado muito
importante por alguns RPs. A falta dessa capacidade de vinculação ao dispositivo, uma
expectativa que talvez não tenha sido declarada explicitamente, mas que certamente era
esperada, representou uma surpresa séria e uma quebra de confiança da sua perspectiva.

A discussão concluiu que deveria haver uma harmonização de interesses, mas primeiramente o
bem maior de disseminar as chaves de acesso deveria prevalecer. Na discussão, a
[extensão devicePubKey](https://github.com/w3c/webauthn/issues/1658) foi vista como uma
forma de resolver essas preocupações, mas depois foi substituída por
**supplementalPubKeys** que adotam uma abordagem muito mais ampla no rascunho atual do
[WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn). Infelizmente, esta abordagem também foi
descontinuada em agosto de 2024.

### 3.4 O melhor de dois mundos: Chaves de acesso e extensão supplementalPubKeys \[descontinuada a partir de agosto de 2024]

Vamos analisar como foi formado o compromisso com a extensão supplementalPubKeys e o que
isso significa tecnicamente.

#### 3.4.1 Da extensão devicePubKey para a extensão supplementalPubKeys

A discussão em torno da transição da extensão **devicePubKey** para a extensão
**supplementalPubKeys** destaca a natureza dinâmica da especificação WebAuthn.
Inicialmente, a **devicePubKey** serviu para aprimorar a segurança através de chaves
públicas vinculadas ao dispositivo, mas mais tarde foi substituída pela sugestão da
**supplementalPubKeys** no
[rascunho de trabalho do editor do WebAuthn Level 3](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension).
Esta extensão mais recente oferece uma solução mais abrangente, permitindo múltiplas
chaves para aprimorar os processos de autenticação.

O cerne do debate centrou-se em equilibrar as medidas de segurança aprimoradas com a
adoção mais ampla e a utilidade prática das chaves de acesso em diferentes dispositivos e
plataformas. A extensão **supplementalPubKeys** representa uma combinação destas
prioridades, permitindo uma autenticação mais rigorosa. Por exemplo, acomoda
regulamentações que exigem determinados padrões de autenticação, permitindo "sub-chaves"
adicionais com declarações de [atestado](https://www.corbado.com/pt/glossary/attestation). Estas chaves podem
sinalizar a conformidade com os requisitos de autenticação, potencialmente reduzindo a
necessidade de desafios de login adicionais sob certas condições (mesmo com chaves de
acesso).

[Um exemplo diretamente do rascunho do WebAuthn](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension):

“_Digamos que um pedido de login aparece num site com algum sinal de geolocalização que
não foi visto antes para a conta deste usuário, e está fora das horas normais de
utilização observadas para a conta. O risco pode ser considerado elevado o suficiente para
não permitir o pedido, mesmo com uma afirmação por uma credencial multi-dispositivo por si
só. Mas se uma assinatura de uma chave suplementar que é vinculada ao dispositivo, e que
está bem estabelecida para este usuário também pode ser apresentada, então isso pode
inclinar a balança.”_

Durante a discussão, foi sublinhado que estas destinavam-se apenas a RPs com requisitos de
segurança extremamente altos (por exemplo, no contexto do
[setor público](https://www.corbado.com/passkeys-for-public-sector)).

Ao incorporar feedback e resolver casos de uso específicos — incluindo também transações
financeiras regulamentadas e a necessidade de sinais vinculados ao dispositivo num
ambiente de credenciais para vários dispositivos — a comunidade WebAuthn visava resolver
preocupações tanto de segurança como de interoperabilidade. A extensão
**supplementalPubKeys** é, portanto, uma abordagem que procura fornecer recursos robustos
de segurança ao mesmo tempo em que oferece suporte a uma experiência de usuário perfeita e
ampla compatibilidade essencial para a adoção generalizada das chaves de acesso. Trata-se
de uma extensão completamente opcional que não interfere na implementação das chaves de
acesso observada nos últimos 2 anos.

Esta evolução em direção a uma estrutura mais inclusiva e flexível sublinha o compromisso
da comunidade WebAuthn em melhorar os métodos de autenticação na web mesmo em casos de uso
mais rigorosos.

#### 3.4.2 Detalhes técnicos da supplementalPubKeys

A extensão **supplementalPubKeys** introduzida no WebAuthn permite a utilização de pares
de chaves adicionais ao lado da credencial primária.

![Gráfico Supplemental Pub Key](https://www.corbado.com/website-assets/supplemental_pub_key_chart_b976bf5115.png)_Tirado
do [issue original do GitHub](https://github.com/w3c/webauthn/pull/1957)_

A imagem mostra o conceito de **supplementalPubKey** tirado do
[issue original do GitHub](https://github.com/w3c/webauthn/pull/1957) (pk = passkey,
pspk=provider supplemental key, dspk = device supplemental key).

Aqui está um resumo de como funciona e do seu uso pretendido:

**Propósito e funcionalidade da supplementalPubKey**

- **Uma credencial central de chave de acesso permanece:** É importante ter em mente que
  apenas uma [chave de acesso](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) central
  continua sendo o método primário de autenticação de usuário, e as chaves adicionais
  fornecem camadas extras de segurança e garantia. Esta estrutura mantém a simplicidade e
  a eficiência de utilizar uma única chave de acesso principal para autenticação em vários
  dispositivos, garantindo uma experiência contínua ao usuário. As chaves suplementares,
  por sua vez, servem para aprimorar o contexto da autenticação, oferecendo à Parte
  Dependente (RP) sinais adicionais sobre o ambiente de segurança ou conformidade com
  padrões específicos de autenticação. Estas chaves suplementares não são métodos de
  autenticação autônomos, mas sim aumentam a chave de acesso principal, reforçando a sua
  fiabilidade com evidências da integridade do dispositivo.
- **Chaves vinculadas ao dispositivo**: Estas estão ligadas especificamente a um
  dispositivo. Elas podem fornecer garantias de que um pedido de autenticação é
  proveniente de um dispositivo confiável que foi autenticado anteriormente. Elas não
  serão sincronizadas em nenhuma circunstância.
- **Chaves vinculadas ao provedor**: Estas chaves têm um escopo de "provedor", o que
  significa que podem oferecer garantias adicionais com base nas políticas do provedor de
  autenticação ou no [atestado](https://www.corbado.com/pt/glossary/attestation) específico do provedor. Por
  exemplo, um provedor pode emitir tal chave apenas depois de um usuário ter concluído um
  nível mais alto de autenticação (como
  [2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)).
- **Várias chaves públicas**: Ao contrário do seu predecessor, a extensão
  **devicePubKey**, que permitia apenas uma [chave pública](https://www.corbado.com/pt/glossary/jwks) vinculada
  ao dispositivo, as **supplementalPubKeys** permitem a inclusão de um ou dois tipos de
  chaves suplementares. Estas chaves podem servir a diferentes propósitos e escopos –
  nomeadamente, escopos vinculados ao dispositivo e vinculados ao provedor.

**Casos de uso e exemplos de supplementalPubKey**

1. **Segurança aprimorada**: Em situações em que um site (parte dependente) deve aderir a
   determinados padrões aprimorados de segurança para autenticação, as chaves
   suplementares podem ser usadas para atender a esses requisitos. Se essa chave
   suplementar foi vista e verificada pelo site antes, ela pode permitir que o usuário
   ignore desafios de login adicionais, uma vez que a continuidade do dispositivo pode ser
   confirmada por sinais anteriores.
2. **Gestão de riscos**: Para pedidos de login que parecem arriscados (por exemplo,
   provenientes de uma nova geolocalização ou em horários incomuns), a presença de uma
   chave suplementar vinculada ao dispositivo que tenha um histórico de uso com a conta do
   usuário pode reduzir o risco percebido e permitir que o pedido continue onde, de outra
   forma, poderia ter sido bloqueado.

**Aspectos técnicos da supplementalPubKey**

- **Sem ID de credencial próprio:** Chaves suplementares não são credenciais de usuário e
  não possuem os seus próprios IDs de credencial.
- **Declarações de atestado**: As chaves suplementares podem, opcionalmente, ter um
  atestado. Estes são cruciais para compreender o escopo e o nível de segurança das chaves
  suplementares. Um atestado pode indicar o nível de proteção de que desfruta uma chave
  vinculada ao hardware ou as políticas para outros tipos de chaves suplementares.
- **Implementação para partes dependentes**: As partes dependentes podem solicitar estas
  chaves suplementares como parte do processo de autenticação. Contudo, a complexidade de
  lidar com várias chaves e declarações de atestado significa que esta extensão é mais
  adequada para entidades com necessidades específicas de segurança, como bancos ou
  serviços operando sob rigorosos requisitos regulatórios.

É crucial notar que, até abril de 2024, a extensão **supplementalPubKeys** não havia sido
adotada por nenhum navegador importante, e a especificação do
[WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) ainda estava em desenvolvimento e sujeita
a alterações. Se este recurso seria incluído na versão final da especificação, e a sua
possível implementação e adoção futura, permaneciam incertos, visto que na época
encontrava-se apenas no rascunho do editor (Editor’s Draft).

#### 3.4.3 Descontinuação da supplementalPubKeys em agosto de 2024

Em agosto de 2024, a extensão **supplementalPubKeys** foi oficialmente descontinuada. O
grupo de trabalho WebAuthn decidiu remover esta funcionalidade devido a suporte
insuficiente. A descontinuação desta extensão também destaca uma nova direção. Atualmente,
a **FIDO Alliance** está trabalhando no desenvolvimento de uma abordagem diferente para
apoiar **Partes Dependentes** com altos requisitos de segurança. Espera-se que esta
solução futura aborde as lacunas deixadas pela descontinuação de **supplementalPubKeys** e
ofereça novos métodos para fortalecer os processos de autenticação em cenários onde normas
rigorosas de segurança são essenciais.

Para mais detalhes sobre a descontinuação, veja a publicação oficial
[WebAuthn GitHub pull request](https://github.com/w3c/webauthn/pull/2109).

## 4. Como a Corbado lida com as diferenças de chaves de acesso vinculadas ao dispositivo vs. sincronizadas na prática

Compreender a diferença entre as chaves de acesso vinculadas ao dispositivo e as
sincronizadas é uma coisa. Saber quais delas os seus próprios utilizadores realmente têm é
outra, e a resposta continua a mudar à medida que as plataformas e os gestores de
palavras- passe alteram o seu comportamento. O [Corbado Observe](https://www.corbado.com/observe) é a camada de
[observabilidade da autenticação](https://www.corbado.com/pt/blog/observabilidade-da-autenticacao) e deriva essa
divisão dos próprios dados das credenciais em vez do que o utilizador julga estar a usar.

### Visibilidade do tipo de chave de acesso em toda a sua base de utilizadores

A vista [Authenticator](https://www.corbado.com/glossary/authenticator) Inventory classifica cada credencial da
sua base de utilizadores como chave de acesso sincronizada,
[chave de acesso vinculada ao dispositivo](https://www.corbado.com/pt/faq/login-segundo-dispositivo-chave-de-acesso-vinculada)
ou [chave de segurança](https://www.corbado.com/pt/blog/melhores-fido2-chaves-de-seguranca-hardware) roaming. A
classificação assenta em sinais produzidos pela própria cerimónia: os transports
declarados pela credencial, o bit de backup state descodificado da asserção e o
[AAGUID](https://www.corbado.com/glossary/aaguid) cruzado com o [FIDO](https://www.corbado.com/pt/glossary/cda) Metadata Service. As
credenciais cujos sinais não se resolvem ficam marcadas como desconhecidas, e cada
classificação traz um nível de confiança, para que um registo antigo e pobre em dados não
se transforme em estatística sem que se note.

[Video: Authenticator inventory](https://www.corbado.com/videos/features/authenticator-inventory.mp4) ([See Authenticator Inventory in Corbado Observe](https://www.corbado.com/observe/authenticator-inventory))

A mesma vista contém o estado de certificação [FIDO](https://www.corbado.com/pt/glossary/cda) por modelo de
autenticador e uma tendência mensal da composição, que é o que torna visível uma população
a deslizar de credenciais vinculadas ao dispositivo para credenciais sincronizadas sem que
ninguém do seu lado tenha mudado seja o que for. A secção 3.4 explica porque é que
supplementalPubKeys foi retirada. A consequência prática é que as flags backup eligibility
e backup state são o sinal por credencial mais forte que resta, e o Observe descodifica
ambas em cada asserção.

### O que isto lhe dá para a discussão sobre a SCA

O tipo de chave de acesso é uma entrada de uma avaliação de risco, e uma avaliação precisa
de evidência por baixo. O Observe também regista a flag
[user verification](https://www.corbado.com/blog/webauthn-user-verification) de cada asserção, pelo que "foi
feita uma [biometria](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador) ou um PIN" passa a ser um
valor nos seus próprios dados em vez de uma inferência a partir das opções de cerimónia
que enviou.

Agir sobre a diferença no momento do prompt funciona sobre o ambiente, que é o que se pode
observar antes de existir uma credencial. O [Corbado Connect](https://www.corbado.com/connect) avalia web versus
aplicação nativa, [WebView](https://www.corbado.com/blog/native-app-passkeys), versão da plataforma, marca e
modelo do dispositivo e a disponibilidade de
[conditional create](https://www.corbado.com/blog/conditional-create-passkeys) quando decide se mostra um prompt
de chave de acesso, e as suas regras de rollout usam as mesmas condições para controlar
que coortes chegam sequer ao fluxo de chaves de acesso.

> **Posição da Corbado sobre a PSD2/SCA e Chaves de acesso:** As chaves de acesso (tanto
> vinculadas ao dispositivo como sincronizadas) podem ser compatíveis com a SCA. Cada
> instituição deve ser a dona da sua avaliação de risco de SCA, mas a evidência é clara:
> as chaves de acesso fornecem inerentemente dois fatores de SCA - posse (chave privada em
> módulo de segurança de hardware ou chaveiro na nuvem) + inerência (biométrica) ou
> conhecimento (PIN). O debate sobre a "posse" tem nuances, mas é solúvel - a indústria
> está caminhando para três abordagens: (1) **Chaves de acesso como são** (por exemplo,
> [Revolut](https://www.corbado.com/blog/revolut-passkeys), [Finom](https://www.corbado.com/blog/finom-passkeys)) - inerência + posse
> por meio do dispositivo com a chave privada, (2) **Chaves de acesso + vinculação de
> cookies/sessão** (por exemplo, [PayPal](https://www.corbado.com/blog/paypal-passkeys), Comdirect) - sinal de
> posse extra para interpretação conservadora, (3) **Vinculação criptográfica
> (DBSC/DPoP)** - prova de posse vinculada a hardware, garantia mais forte. Ainda não
> existe uma única interpretação "correta". Uma abordagem baseada nos resultados em
> relação à SCA é necessária - concentrando-se na resistência ao
> [phishing](https://www.corbado.com/glossary/phishing) demonstrável em vez de na categorização rígida de
> fatores. A [vinculação dinâmica](https://www.corbado.com/pt/blog/vinculacao-dinamica-passkeys-spc) (Dynamic
> linking) permanece um requisito separado para
> [pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) mesmo com chaves de acesso.

## Perguntas Frequentes

### Como as chaves de acesso vinculadas ao dispositivo aumentam a segurança?

As chaves de acesso vinculadas ao dispositivo são credenciais WebAuthn estritamente
ligadas ao dispositivo onde foram criadas. Ao contrário das chaves de acesso
sincronizadas, elas permanecem em um único dispositivo, tornando-as inerentemente mais
seguras para determinados casos de uso:

- **Sem roubo de credenciais**: A chave privada nunca sai do dispositivo, então os
  invasores não podem interceptar as credenciais.
- **Prevenção de acesso não autorizado**: A autenticação só ocorre a partir do dispositivo
  específico onde a chave de acesso foi criada.
- **Sem dependência da nuvem**: Elimina os riscos associados a violações de dados na nuvem
  ou apropriação de contas.
- **Alta conformidade de segurança**: Atende a requisitos rigorosos de autenticação
  vinculada ao dispositivo para setores regulamentados, como
  [serviços financeiros](https://www.corbado.com/passkeys-for-banking) (AAL3).

A principal desvantagem é a portabilidade limitada. Se o dispositivo for perdido, a chave
de acesso não pode ser recuperada a menos que o usuário registre uma nova em outro
dispositivo.

### Por que as chaves de acesso sincronizadas foram introduzidas e quais são seus benefícios?

As chaves de acesso sincronizadas (chaves de acesso de vários dispositivos) foram
introduzidas para resolver os desafios de usabilidade das chaves de acesso vinculadas ao
dispositivo, particularmente a falta de portabilidade e o possível bloqueio da conta em
caso de perda do dispositivo. Os principais benefícios incluem:

- **Autenticação em vários dispositivos**: Acesse contas em vários dispositivos sem
  registrar manualmente uma nova chave de acesso para cada um.
- **Nenhum risco de perda de acesso**: As credenciais têm backup na nuvem (por exemplo,
  [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain),
  [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager)), garantindo a
  recuperação em caso de perda de um dispositivo.
- **Melhoria na UX**: Elimina o atrito ao remover a necessidade de transferir ou recriar
  credenciais manualmente.
- **Sem hardware adicional necessário**: Ao contrário das chaves de segurança de hardware,
  as chaves de acesso sincronizadas usam módulos de segurança integrados ao dispositivo.
- **Segurança forte com a conveniência da nuvem**: A criptografia de ponta a ponta garante
  que a chave privada nunca saia do dispositivo em formato não criptografado.

## 5. Conclusão

Na primeira parte da nossa série de 4 partes, analisamos quais são as diferenças
históricas e técnicas das chaves de acesso vinculadas ao dispositivo e sincronizadas.
Compreender essas diferenças nos ajudará a aplicar os requisitos de PSD2 e SCA de acordo.
Além disso, analisamos o que o futuro pode nos trazer ao dar uma olhada nas mudanças mais
recentes do padrão [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) que ainda está em
evolução.

Aqui estão os links para as outras partes da nossa série:

- Parte 2 “Análise dos requisitos da PSD2 e SCA (SCA e chaves de acesso II)”
- Parte 3 "O que os requisitos de SCA significam para as chaves de acesso (SCA e chaves de
  acesso III)"
- Parte 4 "Implicações da [PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) / [PSR](https://www.corbado.com/blog/psd3-psr-passkeys)
  para as chaves de acesso (SCA e chaves de acesso IV)"