Pular para o conteúdo principal

WebAuthn, OpenID Connect e OAuth

WebAuthn, OpenID Connect e OAuth resolvem problemas diferentes na camada de acesso da UbID:

  • WebAuthn e FIDO2 fornecem autenticação forte de chave pública e passkeys.
  • OpenID Connect estabelece sessão autenticada interoperável e comunica claims de identidade sobre essa sessão.
  • OAuth concede a um cliente autorização limitada para chamar uma API protegida.

Nenhum desses protocolos é formato de credencial verificável, método DID ou política de verificação de credenciais.

WebAuthn e passkeys​

WebAuthn permite que uma parte confiante registre e use credenciais de chave pública criadas por um autenticador. A chave privada permanece sob controle do autenticador, enquanto a parte confiante armazena material público de verificação.

A autenticação é limitada à parte confiante e mediada pelo navegador ou plataforma. Isso reduz a exposição a phishing de senhas e comprometimento de senhas no servidor.

Um deployment de passkeys ainda deve governar:

  • cadastro e vínculo com a conta;
  • ciclo de vida do autenticador e do dispositivo;
  • requisitos de presença ou verificação do usuário;
  • política de sincronização quando aplicável;
  • tratamento de perda de dispositivo e recuperação;
  • recadastro e remoção de credenciais;
  • requisitos step-up para operações sensíveis;
  • caminhos de fallback e sua evidência.

WebAuthn comprova o controle de um autenticador cadastrado. Não comprova que a identidade civil do usuário foi estabelecida corretamente nem que uma credencial apresentada depois deve ser aceita.

Sessões OpenID Connect​

OpenID Connect adiciona uma camada de identidade ao OAuth. Um OpenID Provider autentica o usuário e retorna a um cliente um ID Token e claims relacionados.

Na UbID, OIDC pode apoiar federação corporativa e sessões de aplicações enquanto confiança em credenciais permanece domínio separado. Um login OIDC bem-sucedido não comprova automaticamente posse de determinada credencial verificável nem autoriza toda operação de identidade.

O design da sessão deve tratar validação do issuer, audiência, nonce, state, validação de redirects, duração de tokens, logout, reautenticação e contexto de assurance.

Autorização OAuth​

OAuth permite que um cliente obtenha um access token para um recurso protegido sob um grant de autorização definido. O token deve ser limitado por audiência, scope, recurso, duração, cliente e política.

A UbID segue os princípios atuais de segurança OAuth, incluindo fluxos authorization code, PKCE para clientes públicos, correspondência exata de redirects, proteção contra replay de código e token, privilégios limitados, autenticação segura de cliente quando apropriada e rejeição de padrões deprecados.

Um access token não é senha de usuário, credencial ou prova universal de identidade. Resource servers devem validá-lo para a API e operação pretendidas.

Uso complementar na UbID​

Uma interação típica pode usar as três camadas:

  1. WebAuthn autentica o usuário na Wallet ou portal.
  2. OpenID Connect estabelece sessão de aplicação.
  3. OAuth autoriza um cliente a chamar uma API de credenciais ou confiança.
  4. Um protocolo separado emite ou apresenta evidência verificável.
  5. Um verificador aplica política de credencial e transação.

Manter essas camadas separadas facilita revisar responsabilidades e evidência.

Considerações de segurança e privacidade​

  • Não usar claims de autenticação como substituto de política de autorização.
  • Não conceder scopes amplos de API apenas porque o usuário se autenticou fortemente.
  • Não expor tokens no histórico do navegador, logs, referrers ou origens não relacionadas.
  • Não inferir a identidade de uma pessoa somente da attestation do autenticador.
  • Não tornar fallback mais fácil de abusar do que autenticação normal.
  • Não correlacionar usuários entre partes confiantes por identificadores evitáveis.
  • Exigir autorização recente ou step-up para operações de alto impacto.

Posição da UbID​

Passkeys e política de autenticação server-side fazem parte da baseline implementada da UbID. OIDC e OAuth fornecem contratos de referência para federação, sessão e autorização de APIs. Fluxos exatos, requisitos de assurance, provedores de identidade, scopes e políticas de fallback dependem do deployment.

Limite da documentação pública​

O portal público não publica origens registradas, redirect URIs, client secrets, audiências de tokens, scopes privados, configuração de sessões, allow-lists de autenticadores, sequências de fallback nem metadados de produção de federação.

Padrões-fonte​

Consulte Autenticação e segurança de dispositivos e UbID Access.