Autenticação hospedada

Fluxo unificado

O XID não oferece produtos separados de registro e login para usuários finais. O Hosted Auth começa pela mesma etapa de identificação e decide entre login e criação de usuário conforme a política da Organization e o estado da conta. Em seguida, um convidado ou um cadastro com credenciais e intent=sign-up cria um Tenant de nível superior com Email, Organization name e URL slug. A Email do convidado fica pendente sem reservar um endereço de conta; o novo proprietário pode ler os dados do Console e verifica essa Email antes da primeira alteração de negócio. A mesma Email em outro Tenant continua sendo uma conta separada.

As configurações padrão de bootstrap habilitam somente Magic Link por e-mail e OTP por e-mail. Senha, OTP por WhatsApp, OTP por SMS, chave de acesso, OAuth social e SSO empresarial ficam ocultos até que a política da organização e as credenciais exigidas os habilitem.

As solicitações sem senha por link mágico de e-mail e OTP fixam a intenção de cadastro, a continuação controlada pelo servidor, o cliente de aplicação e o ID da linha do convite quando o desafio é criado. A autorização de convite do Social OAuth também valida a capacidade original antes de redirecionar ao provedor externo, persiste apenas o ID da linha do convite no estado de uso único e ignora no callback as rotas de token controladas pelo cliente. A verificação não pode reescrever esses campos. As capacidades originais de convite nunca são armazenadas nesses contextos de fluxo. Quando o MFA interrompe a aceitação, o XID usa uma continuação assinada de curta duração vinculada ao Tenant, usuário, sessão e convite.

flowchart TD
  Browser --> authorize["/authorize"]
  authorize --> signIn["/sign-in"]
  signIn --> config["/auth/config"]
  config --> methods["WebAuthn / Password / OTP / SSO"]
  config --> signup["guest or intent=sign-up"]
  signup --> createOrg["/create-organization"]
  createOrg --> readOnly["Console reads"]
  readOnly --> verifyEmail["Verify Email"]
  verifyEmail --> mutations["Business mutations"]
  methods --> code["code"]
  methods --> mfa["/auth/mfa/passkey/*"]
  mfa --> code

Endpoint de configuração

GET /auth/config retorna a configuração pública da autenticação hospedada para a organização. Segredos de provedores e provedores desabilitados não são retornados ao navegador.

Política de identificador

• Organizações podem exigir identificadores de e-mail, identificadores de usuário ou ambos.
• As listas de domínios de e-mail permitidos e bloqueados são aplicadas antes da criação de usuário.
• Forçar SSO oculta métodos locais quando uma conexão empresarial é obrigatória.

Limites de WebAuthn e passkey

• Login com passkey é a autenticação AAL2 principal. Sessões com senha ou OTP podem concluir MFA por /auth/mfa/passkey/* com verificação de usuário obrigatória.
• A política da organização attestationMode seleciona atestação empresarial nenhuma, indireta ou direta durante o registro de passkey.
• Parâmetros de credencial WebAuthn anunciam ES256, RS256 e EdDSA. Passkeys sincronizáveis permanecem AAL2 mesmo após MFA.
• urn:xid:aal3 não é emitido atualmente. Os sinalizadores UV e BE/BS do WebAuthn não comprovam a chave de hardware não exportável exigida pelo NIST. As solicitações AAL3 falham explicitamente, e o mapeamento máximo atual é AAL2.