Saltar para o conteúdo principal
A funcionalidade Authentication é nova. Execute todas as importações primeiro numa aplicação sandbox e só depois importe para a sua aplicação de produção.
Uma importação transfere pessoas de outra plataforma de identidade para a Didit Authentication. A palavra-passe, o e-mail verificado, as ligações de início de sessão social, a aplicação de autenticação e as funções nas organizações são transferidos com elas. Nada muda para elas até a sua aplicação as autenticar com a Didit. As importações usam a API de gestão de Authentication da sua aplicação, com uma sessão de consola que tenha write:authentication (ou read:authentication para as listar). Nunca utilizam um token de utilizador final nem uma chave de API de verificação. Nos exemplos, MANAGEMENT_BASE é:

Duas formas de importar

Importar um ficheiro

1. Carregar

Cada opção keep_* é true, salvo se enviar false. A chamada devolve 202 com uma tarefa. Uma aplicação mantém no máximo 5 ficheiros carregados em simultâneo.

2. Verificar a simulação

Cada carregamento inicia uma simulação. Esta verifica todas as pessoas e não grava nada. Consulte periodicamente GET import-jobs/{id}/: Uma simulação falhada lista os seus erros. Corrija o ficheiro e carregue-o novamente.

3. Iniciar a importação

POST import-jobs/{id}/start/ importa o que a simulação verificou e devolve 202.
  • As pessoas são importadas em lotes de 1000. Cada lote é gravado de forma independente.
  • Apenas uma importação é executada de cada vez por aplicação (caso contrário, devolve import_running).
  • Uma importação interrompida retoma a partir do último lote gravado.
  • As pessoas já importadas são ignoradas, por isso pode executar novamente o mesmo ficheiro.
  • A pessoa que iniciou a importação recebe um e-mail quando esta termina ou para.
O ficheiro carregado é guardado encriptado. É eliminado quando a importação termina, quando a sua simulação falha, ou 24 horas após uma simulação que nunca foi importada.

Importar em lotes

Envie até 1000 pessoas por pedido, com uma idempotency_key de até 100 caracteres.
  • Uma simulação devolve 200 com o resultado e não grava nada.
  • Com dry_run: false, uma importação bem-sucedida devolve 201. Um lote com qualquer erro devolve 400 e não importa ninguém.
  • Repetir um pedido já gravado com a mesma chave devolve o resultado registado. A mesma chave com conteúdo diferente devolve 400 {"idempotency_key": "different_payload"}.
  • Os parâmetros do Firebase vão num objeto firebase: {signer_key, salt_separator, rounds, mem_cost}.
  • GET imports/ lista os lotes gravados.

Formato do ficheiro

JSON

Uma matriz de pessoas, ou um objeto cujo users contém essa matriz.

CSV

As mesmas colunas de valor único, mais google_id, apple_id, github_id, microsoft_id, microsoft_tenant_id, organization_slug, organization_name e organization_role. Uma pessoa em várias organizações ocupa uma linha por organização.
Campos ou colunas desconhecidos são erros e nunca são ignorados.

Duplicados e contas existentes

  • As linhas com o mesmo e-mail tornam-se uma só pessoa. Uma linha idêntica é contada como duplicado. Uma linha com mais ligações, organizações ou uma aplicação de autenticação é fundida com a pessoa.
  • Dois hashes de palavras-passe diferentes, dois segredos de autenticação diferentes ou duas funções diferentes nas organizações para a mesma pessoa são erros. Também é erro um external_id ou um identificador de fornecedor reivindicado por duas pessoas.
  • Se já existir uma conta com esse e-mail e uma importação anterior a tiver criado, a pessoa é ignorada (already_imported). Se a pessoa se tiver registado por conta própria, é um erro identity_conflict. Uma importação nunca altera uma conta existente.

Palavras-passe

Os parâmetros do Firebase são guardados encriptados, apenas para esta aplicação. Qualquer outro formato, ou um custo acima destes limites, significa que a pessoa precisa de uma nova palavra-passe. Depois do primeiro início de sessão bem-sucedido de uma pessoa, a Didit volta a guardar a palavra-passe dela no seu próprio formato.

Pessoas sem palavra-passe utilizável

Quando uma pessoa não tem hash, ou tem um hash não suportado, uma tentativa de início de sessão com palavra-passe recebe a resposta normal de palavra-passe incorreta. A Didit também lhe envia por e-mail uma ligação para definir uma nova palavra-passe (válida durante 30 minutos, no máximo uma vez por dia). Isto acontece apenas quando o e-mail da pessoa está verificado, a conta não está bloqueada e o início de sessão com palavra-passe está ativado. No resultado, reset_required conta as pessoas sem palavra-passe utilizável. reset_emails conta, entre elas, as que têm um e-mail verificado: só estas podem ser contactadas desta forma. As pessoas com um e-mail não verificado não podem iniciar sessão com palavra-passe. Podem continuar a iniciar sessão com um código enviado por e-mail, se ativar esse método.

Ligações sociais, aplicações de autenticação e organizações

  • Ligações sociais são mantidas para os fornecedores que a sua aplicação já configurou, com o ID de cliente atual. Um início de sessão posterior não precisa então de prova de e-mail. Os identificadores do Google e do GitHub são globais. Os identificadores da Apple são por equipa de programadores e os da Microsoft são por registo de aplicação, pelo que essas ligações só correspondem se a sua plataforma antiga usava a mesma equipa ou o mesmo registo. As ligações a fornecedores que não configurou são contadas como social_unavailable e não são importadas.
  • Aplicações de autenticação (segredos TOTP: SHA-1, 6 dígitos, 30 segundos) são guardadas encriptadas. As pessoas importadas têm de as usar como segundo fator. Não recebem códigos de recuperação.
  • Organizações que ainda não existem são criadas a partir do respetivo slug.
  • Chaves de acesso não podem ser importadas. Pertencem ao seu antigo domínio de início de sessão, pelo que as pessoas adicionam uma nova chave de acesso depois de iniciarem sessão com a Didit.

Resultados

Cada simulação, lote e tarefa devolve o mesmo result: As respostas nunca contêm hashes de palavras-passe, salts, segredos de aplicações de autenticação nem valores de campos.

Antes de fazer a transição

Teste na sua aplicação de sandbox:
  • o início de sessão com cada formato de palavra-passe que importar,
  • o e-mail para definir uma nova palavra-passe de uma pessoa sem hash utilizável,
  • o início de sessão social e os códigos das aplicações de autenticação das pessoas importadas,
  • a execução do mesmo ficheiro duas vezes.
Depois, verifique se o vendor_data de cada pessoa corresponde ao valor que usa para as suas verificações e transações.
Última modificação em 7 de novembro de 2026