Novidades das chaves-senha

Olá! Meu nome é Andrew. Sou engineer da equipe Authentication Experience. Nossa preocupação é tornar o processo de início de sessão simples, rápido e seguro.

As senhas são a causa raiz de muitos problemas relacionados ao início de sessão e à segurança de contas. O setor tem trabalhado para resolver esses problemas na origem, eliminando o uso de senhas em contas online e adotando as chaves-senha. As chaves-senha resolvem os problemas de segurança e usabilidade das senhas, eliminando o phishing e oferecendo uma ótima experiência de início de sessão.

Agora que você está assistindo a este vídeo, faz parte da equipe que está tornando isso possível. Estamos trabalhando nesse objetivo importante e abrangente de substituir senhas por chaves-senha.

A jornada das chaves-senha é uma transição em todo o setor para uma autenticação protegida apenas por fatores não suscetíveis a phishing. Isso envolve passar por etapas. Antes das chaves-senha, contas usavam apenas fatores suscetíveis a phishing, como senhas ou códigos enviados por SMS e e-mail.

A jornada começou com a adição de métodos não suscetíveis a phishing, como as chaves-senha. É aqui que grande parte do setor está hoje. O objetivo é que todas as contas não usem fatores suscetíveis a phishing, e as chaves-senha são o caminho para isso. Há um grande impulso em todo o setor, com adoção crescente pelos usuários e suporte cada vez maior dos serviços. Em 2025, a FIDO Alliance, organização por trás das chave-senha, realizou um estudo e descobriu que 69% das pessoas pesquisadas têm pelo menos uma chave-senha.

O Google publicou que quem usa chaves-senha tem quatro vezes mais sucesso para entrar na conta do que quem usa senhas. E o TikTok observou uma taxa de 97% de sucesso no início de seesão para quem usa chaves-senha. Esse nível de sucesso no início de sessão com chaves-senha é comum no setor e raro com senhas.

Essa adoção crescente e bem-sucedida mostra um progresso claro na jornada das chaves-senha. iOS, iPadOS, macOS e visionOS 26 aprimoram as chaves-senha com novidades que facilitam ainda mais a descoberta, a criação e o uso das chaves-senha em apps e sites. Apresentarei cinco atualizações. Primeiro, a nova API para criação de contas. É o jeito mais rápido e fácil de criar uma conta, oferecendo uma chave-senha desde o início.

Depois, falarei sobre manter as chaves-senha atualizadas e sincronizar as alterações da conta com gerenciadores de credenciais.

Em seguida, atualizações automáticas das chaves-senha, oferecendo um jeito fácil de adicionar chaves a contas que usam senhas. Depois, endpoints para gerenciar e mostrar a adoção de chaves-senha nos gerenciadores de credenciais.

Por fim, importação e exportação de chaves-senha, um avanço importante que oferece mais flexibilidade e controle para os usuários.

Primeiro, a nova API para criação de contas. Ao contrário dos cadastros tradicionais com senha, configurar uma chave-senha não é um processo longo ou complexo. Um cadastro simples parece fácil e sem esforço. As chaves-senha não dependem de alguém criar uma senha complexa e tentar lembrá-la. As chaves-senha tornam o início de sessão rápido e fácil, além de serem resistentes a phishing. Com a API de criação de contas e as novas versões do OS, o cadastro fica rápido, seguro e agradável. Vou demostrar o app Shiny no meu iPhone. Ele promete uma foto fofa por dia.

Como com qualquer novo usuário, o primeiro passo é se cadastrar. Esta é a forma tradicional antes de usar a API de criação de contas. Vou começar criando uma conta com meu e-mail.

Recebo a solicitação para preencher um formulário, começando pelo e-mail. Por sorte, o preenchimento automático me ajuda aqui. Pronto, e-mail preenchido. Agora vou preencher meu nome e sobrenome.

E, claro, a temida senha. Vou considerar o melhor cenário e usar a senha forte sugerida.

Depois de tudo isso, toco para continuar e estou cadastrado. Aí está a foto fofa. Que adorável. Agora vou tentar de novo, mas usando a API de criação de contas. Da mesma forma, vou criar uma conta com meu e-mail.

Em vez do formulário com várias etapas, o sistema exibe uma página mostrando o que o Shiny está solicitando. Neste caso, meu nome, um e-mail e uma chave-senha que será salva no app Senhas. E o melhor, tudo preenchido para mim. Este é o novo fluxo simplificado, viabilizado pela API de criação de contas. As informações podem ser editadas. Quando toco em um campo, aparece um seletor com sugestões, que posso escolher ou digitar. Estou feliz com as opções padrão. Toco para continuar, o FaceID me autentica, e pronto. Estou cadastrado e dentro do Shiny. Mais rápido, simples e seguro.

E o início de sessão é igualmente fácil.

Se eu abrir o Shiny no iPad pela primeira vez, recebo um aviso de início de sessão. O app verifica as credenciais ao ser aberto. A chave-senha que criei antes está disponível em todos os dispositivos. Toco para continuar, Face ID e pronto. Fácil! Essa experiência está disponível em apps para iOS, iPadOS, macOS e visionOS e funciona com o app Senhas e gerenciadores de credenciais de terceiros.

Agora, vou mostrar a implementação por trás dessa experiência de cadastro.

Aqui está uma função que mostra os passos principais para a criação de conta. Comece inicializando o novo provedor de criação de contas. Com esse provedor, crie uma solicitação de registro de chave-senha. Aqui, os detalhes principais são definidos. O primeiro parâmetro é acceptedContactIdentifiers. Ele informa ao sistema quais tipos de identificadores de conta seu app aceita. O app recebe só o identificador escolhido para criar a conta, que também é usado como rótulo do nome de usuário da chave-senha. shouldRequestName determina se o nome do usuário deve ser solicitado. Você só deve defini-lo como true se for necessário para a criação da conta. Os três próximos se referem à chave-senha que será criada. Eles seguem o padrão de registro de chave-senha, então forneça os mesmos dados para essa solicitação.

A entidade para registrar a chave-senha, geralmente um nome de domínio, um desafio de uso único que será assinado pela chave-senha criada, e o ID do usuário, um identificador único e estável que você gera para a conta. Em seguida, obtenha uma instância de ASAuthorizationController. Em uma visualização SwiftUI, acesse-a usando o wrapper de propriedade @Environment. Em seguida, execute a solicitação. Quando alguém completa com sucesso o fluxo de cadastro, você recebe ASAuthorizationResult. Extraia-o para ter acesso ao identificador de contato, ao nome, se solicitado, e ao objeto da chave-senha. Crie uma conta no seu servidor e inicie a sessão do usuário.

Isso é o essencial para a adoção. Se algo der errado, o método perform lança um erro que você pode tratar para garantir uma boa experiência em todas as situações. Além dos erros padrão de AuthenticationServices, há três erros que você deve tratar, especialmente relevantes para esta API. O primeiro é deviceNotConfiguredForPasskeyCreation. Isso significa que o dispositivo não está pronto para criar uma chave-senha, por exemplo, se não tiver uma senha configurada. Você pode exibir seu formulário padrão de cadastro, sabendo que o usuário não está apto a criar uma chave-senha. Ao tocar no botão para usar e-mail ou número de telefone no Shiny, esse erro é tratado exibindo um formulário de cadastro personalizado. O próximo é cancelado. Esse erro ocorre se alguém fechar a página de cadastro sem preenchê-la. Nesse caso, você pode exibir seu formulário padrão de cadastro. Quando a página do sistema é fechada no Shiny, esse erro é tratado exibindo um formulário de cadastro personalizado. E o último é preferSignInWithApple. Você só receberá esse erro se seu app for compatível com Iniciar sessão com a Apple. Ele foi criado para ajudar a evitar a criação de contas duplicadas. Se uma pessoa iniciar o fluxo de criação de conta, mas já tiver uma conta no seu serviço usando Iniciar sessão com a Apple, o sistema avisará mostrando um alerta como este. Há uma opção: usar a conta existente de Iniciar sessão com a Apple ou continuar criando uma conta. Se a conta existente for usada, esse erro será gerado. Ao receber esse erro, a melhor prática é iniciar uma solicitação para Iniciar sessão com a Apple, que exibirá a página Iniciar sessão com a Apple. Isso respeita a escolha dela, permitindo que ela entre na conta existente sem toques extras. Isso é tudo sobre erros. Outra boa prática é oferecer as contas existentes ao iniciar o app, ajudando as pessoas a voltarem a iníciar sessão no seu app. Na demo do iPad, recebi a solicitação para iniciar sessão com minha chave-senha, sem pensar se eu tinha uma conta ou como iniciei de sessão da última vez. Isso ocorreu porque o Shiny usou uma solicitação de início de sessão com a opção preferImmediatelyAvailableCredentials definida. Se alguém tiver credenciais de conta disponíveis no dispositivo, seja uma chave-senha, uma senha de gerenciador de credenciais ou uma conta com Iniciar sessão com a Apple, elas serão oferecidas para iniciar a sessão. Se não houver nenhuma credencial disponível, nenhuma interface é exibida, mantendo sua tela de início de sessão sem interrupções. Para saber como adotar isso, confira o vídeo "Conhecer as chaves-senha" da WWDC22.

Essa é a API de criação de contas, um recurso novo que torna o cadastro fácil e seguro.

Após criar a conta, manter a chave-senha atualizada nos gerenciadores garante uma boa experiência. Isso me leva ao próximo tema: manter as chaves-senha atualizadas. As contas não são estáticas. As pessoas atualizam suas informações, como nomes de usuário ou e-mails, e podem revogar chaves-senha. Se os gerenciadores de credenciais exibirem informações desatualizadas durante o início de sessão, isso pode causar confusão e atrasar ou impedir o acesso ao serviço. Uma nova coleção de APIs permite que apps e sites informem mudanças nas contas aos gerenciadores de credenciais. Usar essas APIs Signal mantém as informações corretas e garante inícios de sessão rápidos e confiáveis.

Veja como isso funciona no Shiny. Imagine que me formei na universidade e quero trocar minha conta de e-mail estudantil pelo meu e-mail pessoal.

Acesso as configurações do app, toco em e-mail e digito meu novo e-mail.

Salvo as alterações.

Logo em seguida, meu gerenciador de credenciais, o app Senhas, me notifica que o nome de usuário foi alterado.

Se eu tocar nele, o app Senhas faz minha autenticação e exibe os detalhes da conta.

O nome de usuário reflete o novo e-mail pessoal. O gerenciador de credenciais corresponde ao que está no back-end do app. Muito legal, né! Isso é possível graças a uma nova API disponível para apps e Web. Para apps, a nova classe ASCredentialUpdater oferece métodos para reportar alterações específicas nas credenciais. Para a Web, métodos equivalentes fazem parte do padrão WebAuthn, com suporte no Safari 19 e em outros navegadores.

O primeiro sinal é para a alteração do nome de usuário. Como na demonstração, se alguém atualizar o nome de usuário, e-mail ou qualquer rótulo exibido para a conta, use o método reportPublicKeyCredentialUpdate para informar o gerenciador de credenciais. Isso garante que o rótulo exibido no início de sessão esteja sempre atualizado, evitando confusões. Lembrete: os nomes de usuário nas chaves-senha são apenas rótulos locais. Eles não são retornados ao servidor durante a autenticação.

Na Web, use o método signalCurrentUserDetails em PublicKeyCredential para fazer a mesma coisa.

Agora, revogar uma chave-senha. Muitos apps e sites têm páginas de gerenciamento de chaves-senha em que é possível revogar ou criar uma chave. Ao revogar uma chave-senha, chame o método reportAllAcceptedPublicKeyCredentials com os IDs das credenciais válidas. Ao fazer isso, os gerenciadores de credenciais excluem as chaves-senha que não estão na lista que você forneceu. Isso evita que chaves-senha inválidas sejam oferecidas no início de sessão. Também é possível usar esse método regularmente para verificar a integridade da conta. Se algo mudar, isso ajuda a manter os gerenciadores de credenciais atualizados.

Na Web, você pode fazer o mesmo usando o método signalAllAcceptedCredentials.

No final, as contas mais seguras são as que não têm senha. As contas criadas com a nova API de criação nunca têm senha, garantindo segurança desde o primeiro dia.

Para contas existentes, você pode informar aos gerenciadores de credenciais quando a senha não é mais necessária. A API reportUnusedPasswordCredential indica que a conta deu o passo final na jornada das chaves-senha, ficando sem senha.

E todos os gerenciadores de credenciais podem participar da manipulação desses sinais. Há uma nova API para ouvir sinais de atualização e manter credenciais atualizadas. Para saber mais, consulte a documentação de desenvolvedor dos métodos report em ASCredentialProviderViewController. Essas novas APIs ajudam a manter a precisão das credenciais. Agora, vou falar sobre como incentivar a adoção das chaves-senha, especialmente para quem ainda usa senhas. Atualizações automáticas das chaves-senha oferecem um jeito fácil de adicionar chaves-senha a contas que usam senhas. Seu app ou site pode criar uma chave-senha após o início de sessão com senha, sem dificuldade. Vou mostrar. De volta ao Shiny, imagine que ainda uso senha e quero iniciar sessão. Preencho meu nome de usuário e senha, toco em iniciar sessão e pronto. Como o Shiny adotou atualizações automáticas de chaves-senha, veja o que acontece agora. Recebi uma notificação de que uma chave-senha foi criada. Sem telas de venda ou interrupções, apenas uma transição suave que desbloqueia uma experiência de início de sessão mais simples e segura. É importante destacar que a senha que acabei de usar ainda funciona. O processo inclui a chave-senha como uma opção segura de iniciar sessão. Em código, isso é uma atualização automática para chave-senha. Após o início de sessão com senha, você tem acesso aos dados da conta. Comece verificando se a conta já não tem uma chave-senha. Se não, crie uma solicitação de registro de chave-senha. Definir requestStyle como conditional ativa a atualização automática da chave-senha. Com isso definido, após você realizar a solicitação, o sistema e o gerenciador de credenciais executam verificações em segundo plano. Isso inclui verificar se um gerenciador de credenciais está disponível, se a senha dessa conta foi usada e se o dispositivo está configurado para chaves-senha. Se todas as condições forem atendidas, o sistema criará uma chave-senha, exibirá uma notificação, e seu app receberá o objeto da chave-senha para salvar, tudo isso sem interromper ou bloquear o usuário. Se uma pré-condição não for atendida, a chamada falhará silenciosamente. O sistema não exibirá nenhuma interface e não é necessário tratamento de erro específico. Seu app deve tentar atualizar a cada início de sessão com senha, se o usuário ainda não tiver uma chave-senha.

Também existe uma API da Web equivalente. Para aprender sobre atualizações automáticas de chaves-senha, confira o vídeo da WWDC24 "Simplificar o início de sessão com atualizações da chave-senha e gerenciadores de credenciais". As atualizações automáticas oferecem um caminho ideal sem obstáculos.

Para complementar isso, adotar o URL padrão para endpoints de gerenciamento de chaves-senha permite links diretos dos gerenciadores de credenciais às páginas de gerenciamento. É uma ótima forma de destacar a adoção das chaves-senha. Vou mostrar. Aqui, estou no app Senhas, revisando uma entrada salva do Shiny que ainda usa senha. Repare na nova seção que me avisa que há uma atualização para chave-senha disponível. Ao tocar no botão Adicionar chave-senha, o site é aberto na página indicada para o cadastro da chave-senha.

Implementar esse padrão cria um link direto dos gerenciadores de credenciais para suas páginas de cadastro de chaves-senha. Isso oferece mais uma forma para as pessoas atualizarem suas contas pelo gerenciador de credenciais. E, por ser baseado em um padrão, isso funciona em todos os gerenciadores de credenciais participantes.

Para dar suporte a isso, pesquise a resposta JSON no caminho well-known/passkey-endpoints em seu servidor. A resposta deve vir diretamente desse caminho, sem redirecionamento.

Retorne essa resposta com o código de status 200 OK e o cabeçalho Content-Type definido como application/json.

O conteúdo da resposta é um dicionário JSON que aponta para as páginas relevantes no seu site.

Enroll é o URL em que o usuário adiciona uma chave-senha à conta. É para esse URL que o botão Adicionar chave-senha no app Senhas direciona. Manage é o URL em que o usuário gerencia suas chaves-senha existentes, semelhante a uma página de alteração de senha. É onde o usuário pode revogar chaves-senha existentes ou adicionar novas.

Todos os campos são opcionais, mas o ideal é incluir ambos. É importante que esses URLs lidem corretamente com usuários que chegam sem uma sessão autenticada. Se for necessário iniciar sessão, primeiro autentique o usuário e depois redirecione para o URL solicitado.

Além disso, essa página deve ser acessível e entregue a todos os agentes do usuário. Não são só os navegadores que fazem essa solicitação. Apps como gerenciadores de credenciais também o fazem. Ao implementar o URL conhecido para endpoints de gerenciamento de chaves-senha, você fornece aos gerenciadores de credenciais uma dica para a adoção de chaves-senha para seu serviço.

Agora, vou falar sobre importação e exportação de chaves-senha.

As pessoas são donas de suas credenciais e devem ter a flexibilidade de gerenciá-las onde quiserem. Por isso, fico feliz em informar que chaves-senha agora podem ser transferidas com segurança entre gerenciadores de credenciais participantes no iOS, iPadOS, macOS e visionOS 26. Isso dá às pessoas mais controle sobre seus dados e a escolha do gerenciador de credenciais que desejam usar.

Esse novo processo é diferente e mais seguro que os métodos tradicionais de exportação de credenciais, que envolvem exportar arquivos CSV ou JSON não criptografados e depois importá-los manualmente em outro app. O processo de transferência é iniciado pelo usuário, ocorre entre gerenciadores de credenciais participantes e é protegido por autenticação local, como o Face ID. Essa transferência usa um esquema de dados desenvolvido em colaboração com os membros da FIDO Alliance. Ele padroniza o formato dos dados para chaves-senha, senhas, códigos de verificação e outros tipos de dados. O sistema oferece um mecanismo seguro para transferir os dados entre apps. Nenhum arquivo não seguro é criado no disco, eliminando o risco de vazamento de credenciais por arquivos exportados. É uma forma moderna e segura de transferir credenciais.

Apps e sites não precisam fazer nada para dar suporte à transferência de credenciais, pois o processo ocorre entre os gerenciadores de credenciais. As chaves-senha existentes permanecem inalteradas e continuarão funcionando. Para apps gerenciadores de credenciais que desejam dar suporte à transferência de credenciais, consulte a documentação de desenvolvedor de ASCredentialExportManager e ASCredentialImportManager.

As chaves-senha continuam evoluindo, oferecendo segurança reforçada com experiências mais simples. As novas versões do OS tornam sua criação, uso e descoberta ainda mais fáceis. Estamos nessa jornada rumo a um futuro sem senhas, e a adoção desses recursos é fundamental para tornar isso realidade para todo mundo. Para você continuar oferecendo a melhor experiência de autenticação, aqui estão os próximos passos. Primeiro, adote a API de criação de contas para um cadastro seguro e rápido. Mantenha as chaves-senha atualizadas usando a API Signal para informar os gerenciadores de credenciais sobre mudanças na conta, como nomes de usuário atualizados ou remoção de chaves. Depois, ative as atualizações automáticas de chaves-senha para uma transição mais fluida a partir das senhas. Por fim, torne as atualizações de chaves-senha acessíveis pelos gerenciadores de credenciais, disponibilizando os endpoints de gerenciamento de chaves no seu site. Essas são as novidades nas chaves-senha. Agradeço sua participação.