O Ano Zero das Passkeys B2B: Do Consumidor ao Enterprise
As Passkeys promovidas em conjunto por Apple, Google e Microsoft de 2022 a 2024 se espalharam inicialmente como meio de autenticação voltado ao consumidor. Porém, a partir do segundo semestre de 2025, a adoção em B2B avançou rapidamente, e 2026 pode ser chamado de "o ano zero da implantação de Passkeys B2B". Okta, Entra ID, Google Workspace e 1Password Business passaram a suportar tanto Cross-Device Passkey quanto Passkeys síncronas, amadurecendo para um design que coexiste com chaves de segurança compatíveis com FIDO2 (YubiKey 5C, Google Titan).
O principal motivo para a adoção séria de Passkeys em B2B é a resistência a phishing. Em 2024 e 2025, kits de phishing do tipo AiTM (Adversary-in-the-Middle) direcionados a empresas japonesas aumentaram drasticamente. O TOTP e o SMS OTP tradicionais são vulneráveis a ataques que roubam sessões de autenticação via proxy intermediário, e múltiplos incidentes de comprometimento de milhares de contas de SaaS domésticos em uma única noite foram registrados. As Passkeys (WebAuthn) têm resistência estrutural ao AiTM graças ao domain binding — a assinatura não é válida em sites de phishing. O fato de ser "garantido pelo protocolo" em vez de "cuidado durante a operação" se tornou a base para decisões de gestão.
O trade-off entre Passkeys síncronas (via iCloud Keychain, Google Password Manager) e Passkeys vinculadas ao dispositivo (restritas a YubiKey etc.) continua em discussão. Setores financeiro e de defesa preferem as vinculadas ao dispositivo, enquanto as síncronas são mais realistas para implantação ampla para todos os funcionários. A revisão de 2025 do NIST SP 800-63B, que reconheceu as Passkeys síncronas como AAL2, impulsionou a formulação de políticas.
Armadilhas da Implementação WebAuthn e Recuperação de Conta
A primeira armadilha é o design do RP ID (Relying Party ID). Como o RP ID é por domínio, `corp.example.jp` e `portal.example.jp` precisam de registros de Passkey separados. Para unificá-los, é necessário usar o domínio pai `example.jp` como RP ID, mas organizações que compartilham o domínio pai com sites de marketing precisam avaliar cuidadosamente o impacto.
A recuperação de conta é o maior desafio na operação com Passkeys. Negligenciar o design de recuperação faz com que mecanismos de autenticação fracos (OTP por e-mail, OTP por SMS) sejam mantidos como backup, reduzindo a força de segurança ao nível do backup remanescente. O design recomendado é em 3 camadas. Recuperação leve (novo login de outro dispositivo): resolvida automaticamente com Passkey síncrona. Recuperação intermediária (perda de todos os dispositivos): aprovação do administrador + verificação de identidade com documento. Recuperação severa (suspeita de adulteração de identidade): verificação presencial obrigatória. É também importante não deixar a recuperação severa passar pelo CS — comprometimentos reais de suporte por engenharia social ocorreram em 2024.
SCIM e Automação de Provisionamento
O provisionamento automático via SCIM 2.0 não é mais uma opção, mas um pré-requisito. Sincronizar do IdP para cada SaaS via SCIM faz com que adição de usuários, atualização de atributos e desativação se propaguem em tempo real. Os principais SaaS (Salesforce, Slack, Notion, GitHub Enterprise, Atlassian) oferecem SCIM 2.0 como padrão, e a qualidade de implementação no lado receptor melhorou significativamente em relação a 2024.
O que costuma ser negligenciado na operação com SCIM é o design do mapeamento de atributos. A tabela que mapeia departamento, cargo e tipo de emprego do lado do IdP para grupos e papéis de permissão do lado dos SaaS deve ser mantida de forma que RH e TI possam colaborar. O Okta Workflows e o Entra Lifecycle Workflows têm UIs sem código, e a abordagem de expressar em cadeias de IF é dominante. A transformação de atributos dependente de scripts se torna o padrão de não conseguir acompanhar mudanças seis meses depois. Sair da sincronização diária em CSV é uma demanda que cresce em auditorias internas em 2026.
De SAML para OIDC: Por Que Agora?
SAML foi o padrão de SSO B2B por muitos anos, mas em 2026 novos projetos adotam OIDC como primeira escolha. Três motivos. Primeiro, compatibilidade com mobile/SPA: o redirect XML do SAML é mais trabalhoso em aplicativos mobile nativos em comparação ao OIDC com PKCE. Segundo, complexidade de assinatura e criptografia: a especificação XML Signature do SAML é ampla e vulnerabilidades por diferenças de implementação (como ataques de XML Signature Wrapping) foram historicamente frequentes. Terceiro, como autenticação (ID Token) e autorização de API (Access Token) são estruturalmente separados, o design de permissões em ambientes de microsserviços fica mais claro.
Porém, a eliminação completa do SAML não é realista. SAP SuccessFactors, Workday e parte do Oracle Cloud têm SAML como único SSO. A estratégia de migração é: "novo: OIDC, SAML existente: mantido por ora, IdP consolidado como infraestrutura com suporte a ambos". A armadilha da migração é a "diferença no mapeamento de atributos" — ao migrar para o design de claims OIDC a lógica de transformação de Assertions construída ao longo dos anos de operação SAML, conflitos de nome de grupo e divergências de escopo de role ocorrem frequentemente. Antes de migrar, insira obrigatoriamente a etapa de "listar todos os atributos SAML Assertion atuais e criar uma tabela de mapeamento para claims padrão OIDC + claims customizados".
Adaptive MFA e Autenticação Step-Up
O Adaptive MFA é um mecanismo que ajusta dinamicamente a força de autenticação conforme o contexto da requisição. Na operação normal, apenas a Passkey é exigida; condições como acesso de dispositivo desconhecido, horário da madrugada ou país nunca visto antes acionam autenticação adicional. A autenticação step-up é um subconjunto: reavalia a força de autenticação da sessão atual imediatamente antes de operações de alto risco como "visualização de dados de salário", "deploy em produção" ou "exportação em massa de dados de clientes", e se insuficiente exige autenticação adicional. O método padrão é declarar via claim `acr` (Authentication Context Class Reference) do OIDC que "esta operação requer acr=phr (phishing-resistant)".
O mais difícil no design é a "tolerância a falsos positivos". Muito restritivo paralisa o trabalho; muito permissivo deixa comprometimentos passarem. Pela experiência prática, começa-se com "dispositivo conhecido + localização conhecida: apenas Passkey" e "dispositivo desconhecido: Passkey + step-up", ajustando mensalmente com base no histórico de incidentes e na taxa de falsos positivos.
Conflitos Específicos de Empresas Japonesas: Número Individual e Contas Compartilhadas
Ao promover Passkeys, SCIM e OIDC em empresas japonesas, surgem conflitos culturais ausentes da documentação de fornecedores estrangeiros. Primeiro: o tratamento do número de matrícula e do número individual (My Number). O My Number tem uso estritamente limitado pela lei de numeração, e não deve ser inserido nos claims `sub` do IdP ou no `externalId` do SCIM. Porém, na prática, sistemas de core business legados que vinculam número de matrícula e número individual ainda existem, e incidentes de vazamento inadvertido do número individual para SaaS externo via design de sincronização SCIM têm ocorrido. A tabela de mapeamento de atributos deve obrigatoriamente incluir uma lista de verificação de "atributos proibidos de exportação externa".
Segundo: o conflito com a cultura de contas compartilhadas. Em pequenas e médias empresas japonesas, contas compartilhadas por cargo como `soumu@` e `keiri@` ainda persistem. Como as Passkeys são vinculadas ao autenticador pessoal, configurar uma Passkey em uma conta compartilhada impede rastrear "quem fez login". A estratégia de migração é reestruturar o design: separar as contas compartilhadas em contas funcionais (Service Accounts) e contas pessoais, com recebimento de e-mail comercial pela conta funcional e login pela conta pessoal. Se a prioridade for a rastreabilidade dos logs de auditoria, o login compartilhado deve ser completamente eliminado. Terceiro: a coexistência de dispositivos fornecidos pela empresa e BYOD — o design de duas camadas de "dispositivos gerenciados: Passkey síncrona, BYOD: chave de hardware obrigatória" é a opção prática.
Roteiro de Migração
Apresentamos um roteiro de 12 a 18 meses. Fase 1 (0-3 meses): preparação da infraestrutura de IdP, suporte a SAML/OIDC, levantamento dos SaaS com suporte a recebimento de SCIM. Fase 2 (3-6 meses): implantação piloto de Passkey, política inicial de Adaptive MFA, automação SCIM nos 10 SaaS prioritários. Fase 3 (6-12 meses): implantação de Passkeys para toda a empresa, eliminação gradual de TOTP/SMS OTP, integração de step-up nos aplicativos. Fase 4 (12-18 meses): proibição de novos SAML, decisão de migrar SAML legado para OIDC ou descontinuá-lo, eliminação completa de contas compartilhadas. Para a explicação à alta gestão, os dois eixos mais eficazes são "valor estimado do dano em caso de AiTM" e "redução de horas de conformidade com auditoria". A infraestrutura de operação de identidade que integra RH, ZTNA e grupos de SaaS com o IdP como eixo central está se elevando de um projeto pontual para uma capability permanente da organização.