1 de 99

Portuguese (Brazil)

Introdução

Aqui você encontrará as informações técnicas das APIs REST da plataforma Unico IDCloud

Visão Geral

Bem-vindo à documentação das APIs REST da plataforma Unico IDCloud! Nesta página, você encontrará tudo o que precisa saber para melhorar a segurança e a qualidade dos seus aplicativos usando nossa REST API.

SOBRE O IDCLOUD

Unico IDCloud

Conheça tudo sobre nossa plataforma de verificação de identidade Unico IDCloud

O que é a plataforma Unico IDCloud?

IDCloud é a única plataforma de verificação de identidade que combina segurança com precisão garantida. Com ela, é possível validar a identidade de usuários de maneira simples e intuitiva, utilizando apenas uma selfie, garantindo fluidez e proteção nos seus processos de verificação.

Meios de Integração

Nesta seção, você conhecerá mais sobre os meios de integração da plataforma Unico IDCloud

by Unico

Para empresas que desejam contar com um parceiro para gerenciar a experiência do usuário com melhores práticas e privacidade, além de contar com a facilidade na orquestração de fluxos com as capacidades da Unico e com a atualização automática de tecnologias, como os SDKs.

Com o by Unico, você terá um time de especialistas em segurança e melhores práticas de UX design para garantir a melhor conversão possível em sua operação. Pode ser utilizada de forma responsiva tanto no Desktop quanto no Mobile. Oferendo as seguintes possibilidades de uso:

Canal

Redirect

Open.window()

iFrame

Webview

Mensagens

Desktop

Webmobile

App mobile

Para o fluxo de mensagens, é possível enviar notificações pelos canais de: WhatsApp e/ou SMS.

Confira como é a experiência do usuário final com o by Unico na Mensageria, Webview e iFrame, respectivamente, nas abas abaixo:

by Client

Para empresas que desejam controlar a experiência dos usuários com frontend próprio, bem como a construção dos fluxos com as capacidades da Unico no backend junto às demais tecnologias e recursos utilizados para autenticação.

Com o by Client você tem a liberdade que precisa para criar e gerenciar a jornada do usuário final como preferir, aproveitando as capacidades da plataforma Unico IDCloud como julgar necessário.

Capacidades e Meios de Integração

Nesta seção, você encontrará quais capacidades estão disponíveis em cada meio de integração da plataforma Unico IDCloud

Para atender os mais variados casos de uso da sua operação, as capacidades do IDCloud possuem diferentes disponibilidades de acordo com os meios de integração. Abaixo confira a tabela com todas as possibilidades de utilização, separadas por meio de integração:

Em cada meio de integração é possível combinar diversas capacidades entre si. Para saber mais sobre os fluxos possíveis em cada meio de integração, acesse os respectivos menus abaixo:
Para ambos os meios de integração também é possível obter o retorno de similaridade da Serpro.

INTEGRAÇÃO

Guia de início rápido

Nesta seção, você encontrará um overview de como se integrar com a plataforma Unico IDCloud

Visão geral da integração

Se autentique

Defina quais capacidades você irá utilizar

Quais capacidades você precisa na sua operação? Verificação de Identidade? Prova de vida?

Defina qual será seu meio de integração

Crie um processo

Consulte o resultado do processo

Com o processo concluído, consulte o resultado do processo no meio de integração que você optou utilizar.

Pronto. Com o resultado em mãos, tome a decisão de aprovar ou não o cadastro usuário.

Autenticação

Nesta seção, você encontrará toda a especificação técnica sobre a forma de autenticação para utilização das APIs REST da plataforma IDCloud

Para utilizar a plataforma IDCloud é necessário se autenticar via token de acesso, utilizando o sistema de autenticação conhecido como OAuth2.

O sistema de autenticação OAuth2 da unico suporta a interação server-to-server entre uma aplicação web e os serviços da unico.

Para este cenário, você precisará de uma conta de serviço, que é uma conta impessoal que pertence à sua aplicação e não a um usuário individual. Sua aplicação chama as APIs da unico em nome da conta de serviço, portanto usuários não estão diretamente envolvidos. Este cenário é chamado “two-legged OAuth”, ou “2LO”. Tipicamente, uma aplicação utiliza uma conta de serviço quando a aplicação chama as APIs da unico para trabalhar com seus próprios dados ao invés dos dados do usuário.

Este é o passo zero para iniciar sua implementação, portanto não pule esta etapa.

Criando uma Conta de Serviço

Nesta seção, você encontrará como realizar a criação de uma conta de serviço para se autenticar na plataforma Unico IDCloud

Para utilizar interações server-to-server, é preciso solicitar a criação da conta de serviço com o gerente de projetos responsável pela sua empresa enviando os seguintes dados: nome da empresa, nome da aplicação, nome, e-mail e celular do responsável pela aplicação na empresa. É preciso criar contas diferentes para os ambientes de Homologação e Produção.

Após o recebimento desses dados, será criada uma conta de serviço responsável por autenticar a sua aplicação e enviaremos um e-mail para que seja gerado o par de chaves para a conta.

Uma credencial de conta de serviço inclui um nome único de conta, um identificador da empresa (Tenant ID) e ao menos um par de chaves (pública e privada). Ao final da geração das chaves, você recebe apenas a chave privada (arquivo .key.pem), bem como o payload que deve ser utilizado para montar o JWT. Este payload terá o seguinte formato:

Caso precise da chave pública para configurar em seu sistema, contate o gerente de projetos responsável por sua conta. Também é possível gerar uma chave pública através do comando openssl a seguir:

Preparando para fazer uma requisição autenticada à API

Nesta seção, você encontrará como realizar o processo de autenticação na plataforma Unico IDCloud

Após a criação e configuração de uma conta de serviço, sua aplicação precisa completar as seguintes etapas:

Criar um JSON Web Token (JWT), que inclui cabeçalho, payload e assinatura;
Requisitar um token de acesso (AccessToken) da plataforma de autenticação OAuth2;
Tratar a resposta JSON que a plataforma de autenticação retornará.

Se na resposta estiver incluso um token de acesso, você poderá usá-lo para fazer requisições às APIs dos produtos da unico para os quais a conta de serviço possui permissão de acesso. (Se na resposta não estiver incluso um token de acesso, seu JWT e requisição de obtenção do token podem estar incorretos ou a conta de serviço pode não ter as permissões necessárias para acessar os recursos solicitados.)

O token de acesso gerado na requisição mencionada acima tem validade padrão de 3600 segundos, podendo variar de acordo com a configuração de segurança estabelecida para sua empresa. Quando o token de acesso expirar, sua aplicação deverá gerar um novo JWT, fazer a assinatura e requisitar um novo token de acesso na plataforma de autenticação.

1 - Criando o JWT

Um JWT é composto por três partes: um cabeçalho, um payload e uma assinatura. O cabeçalho e o payload são objetos JSON. Esses objetos JSON são serializados em UTF-8 e então codificados usando codificação Base64url¹. Esta codificação provê resliência contra alterações de codificação em casos de repetidas operações de codificação. O cabeçalho, o payload e a assinatura são concatenadas com um caractere de ponto final ..

Um JWT é composto da seguinte forma:

{Cabeçalho em Base64url}.{Payload em Base64url}.{Assinatura em Base64url}

O texto base para a assinatura é composto pela seguinte forma:

{Cabeçalho em Base64url}.{Payload em Base64url}

1.1 - Formando o cabeçalho JWT

O cabeçalho consiste em dois campos que indicam o algorítimo de assinatura e o formato do token. Ambos os campos são obrigatórios e cada campo possui apenas um valor. Contas de serviço dependem do algorítimo RSA SHA-256 e do formato de token JWT. Como resultado, a representação JSON do cabeçalho se dá da seguinte forma:

{"alg":"RS256","typ":"JWT"}

A representação em Base64url se dá da seguinte forma:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

1.2 - Formando o payload JWT

O payload JWT contém informações sobre o JWT, incluindo as permissões sendo requisitadas (scopes), a conta solicitando acesso, o emissor, o momento em que o token foi emitido e o tempo de vida do token. A maioria dos campos são obrigatórios. Assim como o cabeçalho JWT, o payload é um objeto JSON e é usado na composição da assinatura.

1.3 - Campos Obrigatórios

Os campos obrigatórios no JWT são mostrados na tabela abaixo. Eles podem aparecer em qualquer ordem dentro do payload.

Nome

Descrição

iss

O identificador da conta de serviço na empresa.

scope

Uma lista delimitada por espaços ou pelo sinal de positivo + das permissões que a aplicação está requisitando. Se todas as permissões da conta forem necessárias, utilizar o sinal de asterisco * para tal.

aud

Casos recorrentes que NÃO funcionam:

exp

O tempo de expiração do token, especificado em segundos desde 00:00:00 UTC, 1 de Janeiro de 1970. Este valor tem um tempo máximo de 1 hora após o momento da emissão do JWT. Este valor deve ser numérico.

Casos recorrentes que NÃO funcionam:

Uso de aspas na delimitação do valor. Ex.: “1524161193” é uma string e não funcionará. Já 1524161193 é um número e funcionará.

iat

O momento da emissão do JWT, especificado em segundos desde 00:00:00 UTC, 1 de Janeiro de 1970. Este valor deve ser numérico.

Uso de aspas na delimitação do valor. Ex.: “1524161193” é uma string e não funcionará. Já 1524161193 é um número e funcionará.

Entenda como funciona a conversão para os campos de emissão (iat) e expiração (exp) do jwt, e veja também exemplos de utilização dos valores dos campos aqui. Além disso, o campo “iat” deve ser o horário atual no formato exigido e o “exp” deve respeitar a conta abaixo:

exp = iat + 3600

A representação dos campos JSON obrigatórios no payload do JWT se dá da seguinte forma:

{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, // Este é apenas um exemplo. Utilize aqui o valor atual gerado.
  "iat": 1626293376 // Este é apenas um exemplo. Utilize aqui o valor atual gerado.
}

1.4 - Calculando a assinatura

A especificação JSON Web Signature (JWS)² é a mecânica que guia o cálculo da assinatura para um JWT. O conteúdo de entrada para o cálculo da assinatura é o byte array do seguinte conteúdo:

{Cabeçalho em Base64url}.{Payload em Base64url}

O mesmo algoritmo sinalizado no cabeçalho do JWT precisa ser utilizado para o cálculo da assinatura. O único algorítimo de assinatura suportado pela plataforma de autenticação OAuth2 é o RSA usando SHA-256. Ele é expressado como RS256 no campo alg do cabeçaho do JWT.

Assine a representação UTF-8 do conteúdo de entrada utilizando SHA256withRSA (também conhecido como RSASSA-PKCS1-V1_5-SIGN com o hash SHA-256) com a chave privada que foi criada e associada à conta de serviço (arquivo .key.pem gerado pela solicitação recebida por e-mail). O conteúdo de saída será um byte array.

A assinatura precisará ser então codificada em Base64url. O cabeçalho, o payload e a assinatura deverão ser concatenadas com o caractere de ponto final .. O resultado é o JWT. Ele deve ser da seguinte forma:

{Cabeçalho em Base64url}.{Payload em Base64url}.{Assinatura em Base64url}

A seguir está um exemplo de token JWT antes da codificação em Base64url:

{"alg":"RS256","typ":"JWT"}.
{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, // Este é apenas um exemplo. Utilize aqui o valor atual gerado.
  "iat": 1626293376 // Este é apenas um exemplo. Utilize aqui o valor atual gerado.
}.
[byte array da assinatura]

Abaixo está um exemplo do JWT que foi assinado e está pronto para transmissão:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY291bnRf
bmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb
3BlIjoiKiIsImV4cCI6MTYyNjI5Njk3NiwiaWF0IjoxNjI2MjkzMzc2fQ.JsymP3NZdgCSqeNlgsOM2
-AQ7M450NxFnZnnaKSu4Q8g12QGEIvvM4EhCokUHfwk5s7pOpm2UD_Ng3Hb5g_wgrjfiVSLWH5Q2wYg1AvfLqo
YSoJWaMHm9KL0kpv32XdDD8TZVR-MVd2VBHmCMVbV6gvk8buUoK1HZDN7g84PaY3bfgcB3RKU-
H55lR8yyJjZxToIv17-wfla2G99uaMEFNGX0ZSE7ETn5Z8-WypmFrNAK0TM58upzvfVI6_-
gY4cj4iQvmRbuvxsAaGiHA2xd0RVm2Mrx-gQtdPqtbZPuQcH7k64Z_EOQBgiGTgVjucyHD6zBijr_P-
2mhIxuecNSw

Após a geração do JWT assinado, uma aplicação pode utilizá-lo para requisitar um token de acesso (Access Token). A requisição do token de acesso é uma requisição POST HTTPS e o corpo deve ser URL encoded. A URL é a mostrada abaixo:

https://identityhomolog.acesso.io/oauth2/token

Os parâmetros abaixo são obrigatórios na requisição POST HTTPS:

Nome

Descrição

grant_type

Utilize o seguinte texto, URL-encoded se necessário: urn:ietf:params:oauth:grant-type:jwt-bearer

assertion

O JWT, incluindo a assinatura.

POST /oauth2/token HTTP/1.1
Host: identityhomolog.acesso.io
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-
bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY
291bnRfbmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsInN1YiI6InVzZXJfaWRlbnRpZmllciIs
ImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb3BlIjoiKiIsImV4cCI
6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.TjH-mTtwP6tBB93O1sDPaAA6yUF7N2-HZDlpIPz
bf_dxO8A6KZuRWG8ZnICrxX56qj0HREiMlYy27XJgxowrUa0JHvbqc8HJkT7-6Mh7J67UnubZKG1-hi
6jDtkC9BIXBcOhtkNUfZvZetXjLzsRsSDkqxdMtzYZwkRlocvaxL5QXiQhweeEwK_Ux81Adh3z0EIhT
yl7CKJLJ69PuHS7s9IdrjUl79owipp4LF1FvtMhoe7YIL69ohPgFqSv_-Y9qpPdW6be3OEAyKlOM08S
ZBbHBwW4XMvw3uZjTY1sgJ4cBoxrftDpjYOw34oPOKxirqc5-90uOCYe1O1hRtG45w

Se o JWT e a requisição do token de acesso foram formados apropriadamente e a conta de serviço tem as permissões necessárias, então a resposta da plataforma de autenticação retorna um objeto JSON contendo um token de acesso. Segue um exemplo de resposta da plataforma:

{
  "access_token": "<access_token>",
  "token_type": "Bearer",
  "expires_in": "3600"
}

A duração do token de acesso é variável. Sua duração é especificada no campo “expires_in”, retornado juntamente com o token de acesso. Deve-se utilizar o mesmo token de acesso durante a sua validade para todas as chamdas às APIs dos produtos.

Não solicite um novo token de acesso até que a validade do token atual esteja chegando ao fim. Sugerimos uma margem de 600 segundos (10 minutos). Para isso execute o cálculo:

token decodificado:
new Date(token.exp - 600)

Sendo que token.exp é o timestamp da expiração do token.

Por padrão, o token enviado para a empresa tem duração de 1h, mas pode ser alterado. A sugestão é sempre usar o expires_in como base e subtrair 600s dele para pedir um novo token.

Exemplos:

Cenário padrão:
expires_in: 3600 (1h) - Geração do token as 14h42

Solicitar um novo token somente as 15h32 ou seja, 14:42 + (3600 - 600)

Cenário com a duração alterada:
expires_in: 7200 (2h) - Geração do token as 14h42

Solicitar um novo token somente as 16h32 ou seja, 14:42 + (7200 - 600)

Um novo token de acesso pode ser solicitado quando faltar 10 minutos pra expirar.

Não utilize um tempo fixo para a obtenção de um novo token, pois o tempo de duração do token recebido pode ser menor que o tempo estabelecido, o que ocasionará falha na utilização dos serviços.

¹ De acordo com o RFC 4648 de codificação BaseN, o formato Base64url é similar ao formato Base64, com exceção do caracter = que deve ser omitido, e dos caracteres + e / que devem ser substituídospor - e _, respectivamente.

Recursos adicionais

Nesta seção, você encontrará recursos adicionais relacionados à autenticação

Exemplo em Javascript

Nesta seção, você encontrará um exemplo de implementação da autenticação da plataforma Unico IDCloud em Javascript

Erros de autenticação

Nesta seção, você encontrará os possíveis erros que podem acontecer ao tentar de autenticar na plataforma Unico IDCloud

Os erros retornados na requisição podem ser identificados através dos códigos abaixo e possuem a seguinte estrutura:

{
  "error": "server_error",
  "error_description": "Falha na autenticação x.x.x"
}

Nome

Descrição

1.0.1

Verifique se o ID informado na formação do "iss" é o ID do tenant correto, fornecido na geração da chave privada¹.

1.0.14

Verifique com o responsável pelo projeto se a aplicação utilizada está ativa.

1.1.1

Parâmetro "scope" não foi informado no payload do token jwt utilizado na requisição.

1.2.4

O token jwt utilizado na requisição está expirado. Verifique o valor informado no campo "exp" do payload.

1.2.5

O token jwt utilizado na requisição não pode ser validado. Verifique os parâmetros informados e tenha certeza de tê-lo assinado da forma correta.

1.2.6

A chave privada utilizada na assinatura do token jwt utilizado na requisição não é mais aceitável. Solicite novas credenciais para a conta utilizada.

1.2.7

O token jwt utilizado na requisição não é mais aceitável, pois já foi utilizado anteriormente. Gere um novo token para fazer uma nova requisição.

1.2.11

A conta utilizada não está ativa.

1.2.14

A conta utilizada não possui as permissões necessárias.

1.2.18

A conta utilizada foi temporariamente bloqueada por ter excedido a quantidade de tentativas inválidas de autenticação.

1.2.19

A conta utilizada não está autorizada a impersonar outra conta de usuário (remova o parâmetro "sub" do payload).

1.2.20 1.2.21

Falha na decodificação do token jwt utilizado na requisição. Utilize um novo token inserindo somente os campos especificados nas seções "Campos obrigatórios" e "Campos adicionais", obedecendo à nomenclatura, semântica e tipo de cada campo.

1.2.22

O token jwt utilizado na requisição possui campos adicionais no payload que não são permitidos. Utilize um novo token inserindo somente os campos especificados nas seções "Campos obrigatórios" e "Campos adicionais", obedecendo à nomenclatura, semântica e tipo de cada campo.

1.3.1

A conta utilizada possui restrições de IP de origem.

1.3.2

A conta utilizada possui restrições de data/hora de acesso.

Postman Collection

Nesta seção, você encontrará a collection do Postman com a REST API para realizar a autenticação na plataforma Unico IDCloud

Faça download do arquivo abaixo, importe no Postman e substitua o valor dos parâmetros "service_account", "tenant_id" e "secret_key" para testar a chamada.

Integração by Unico

Nesta seção, você encontrará todas as especificações técnicas das APIs REST da plataforma Unico IDCloud, utilizando o meio de integração by Unico

Visão Geral

Nesta seção, você encontrará todas as especificações técnicas das APIs REST do by Unico

Introdução

O by Unico é um canal que oferece uma infraestrutura de soluções de validação de identidade da plataforma IDCloud.

Tem por objetivo, simplificar o uso das capacidades da plataforma IDCloud oferecendo uma solução que pode ser integrada ao seu back-end e front-end e que aumenta a segurança das transações.

Canal

Redirect

Open.window()

iFrame

Webview

Mensagens

Desktop

Webmobile

App mobile

Para o fluxo de mensagens, é possível enviar notificações pelos canais de: WhatsApp e/ou SMS.

Dispositivos compatíveis

Web

Compatível com todos os dispositivos com câmera frontal, seja em laptops ou mobile, respeitando a lista de navegadores oficialmente suportados abaixo:

Demais navegadores não são suportados.

Fluxos possíveis

Para isso, você irá mudar apenas o parâmetro flow no payload da REST API, e com isso terá diversas possibilidades de jornadas de verificação. Verifique abaixo a tabela relacionando os flows disponíveis e suas respectivas capacidades:

Flow

Prova de vida

Verificação de Identidade

Alerta de comportamento

Reaproveitamento e captura de documentos

Assinatura eletrônica

Validação (1:1)

Retorno de similaridade da Serpro

idlive

idlivetrust

idtrust

idunicodocs

idunicosign

idunicodocssign

idunicoserprodocssign

idtrustdocs

idtrustsign

idtrustdocssign

idtoken

idtokentrust

idtokensign

Caso utilize a capacidade Reaproveitamento e Captura de documentos, considere que é possível utilizar os seguintes documentos:

RG, CNH, CIN e Passaporte brasileiro.

Fluxos depreciados

Fluxos com Score de risco

Flow

Capacidades

idcheck

Prova de vida + Verificação de Identidade + Score de risco

iddocs

Prova de vida + Verificação de Identidade + Score de risco + Reaproveitamento e captura de documentos

idsign

Prova de vida + Verificação de Identidade + Score de risco + Assinatura eletrônica

iddocssign

Prova de vida + Verificação de Identidade + Score de risco + Reaproveitamento e captura de documentos + Assinatura eletrônica

idchecktrust

Prova de vida + Verificação de Identidade + Score de risco + Alerta de comportamento

idchecktrustdocs

Prova de vida + Verificação de Identidade + Score de risco + Alerta de comportamento + Reaproveitamento e captura de documentos

idchecktrustsign

Prova de vida + Verificação de Identidade + Score de risco + Alerta de comportamento + Assinatura eletrônica

idchecktrustdocssign

Prova de vida + Verificação de Identidade + Score de risco + Alerta de comportamento + Reaproveitamento e captura de documentos + Assinatura eletrônica

idcheckserpro

Prova de vida + Verificação de Identidade + Score de risco + Retorno de similaridade da Serpro

idcheckserprodocs

Prova de vida + Verificação de Identidade + Score de risco + Retorno de similaridade da Serpro + Reaproveitamento e captura de documentos

idcheckserprodocssign

Prova de vida + Verificação de Identidade + Score de risco + Retorno de similaridade da Serpro + Reaproveitamento e captura de documentos + Assinatura eletrônica

creditoconsignado

Prova de vida + Verificação de Identidade + Score de risco + Retorno de similaridade da Serpro + Assinatura eletrônica

Este fluxo funciona na forma de uma condicional:

Se o retorno de similaridade da Serpro for positivo, solicitamos a assinatura eletrônica;
Se o retorno de similaridade da Serpro for negativo, pedimos os documentos do usuário para realizar o facematch:
- Se o resultado do facematch for positivo, solicitamos a assinatura eletrônica;
- Se o resultado do facematch for negativo, finalizamos a jornada sem pedir a assinatura eletrônica.

A capacidade Score de risco está sendo descontinuada e só poderá ser utilizada em casos excepcionais.

Como integrar

Se autentique

Primeiramente você deve possuir uma conta de serviço e realizar a autenticação OAuth2 para obter um access-token válido.

Crie um processo

Com o access-token obtido no passo anterior, realize uma requisição do tipo POST no endpoint client/v1/process(aqui você informará o "flow" que deseja utilizar).

Defina onde será a jornada do seu usuário

Nesta etapa você irá definir onde será a jornada do seu usuário.

Consulte o resultado do processo

Com o access-token obtido no passo 1, realize uma requisição do tipo GET no endpoint client/v1/process/{id}(aqui você informará o "id" do processo que foi criado no passo 2), consulte o resultado do processo e tome a decisão de aprovar ou não o usuário.

API

Nesta seção, você encontrará tudo relacionado as APIs REST do meio de integração by Unico

API Reference

Nesta seção, você encontrará todas as APIs REST disponíveis para utilização do meio de integração by Unico

Criação do Processo

Nesta seção, você encontrará como criar um processo no by Unico através da API REST

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Criação de Processos no by Unico. Perceba que, para utilizar as capacidades da plataforma IDCloud neste meio de integração, basta alterar o valor do parâmetro "flow" no momento de criar o processo e a Unico será a responsável por orquestrar todas as capacidades que deseja utilizar.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Endpoints:

Criação do Processo

Os processos devem ser criados exclusivamente em uma comunicação backend-to-backend, devido à nossa política de CORS, que impede a criação de processos em uma comunicação frontend-to-backend.

A obrigatoriedade de parâmetros na criação do processo pode mudar a depender dos flows utilizados. Ex:

Em flows que possuem Assinatura eletrônica, é obrigatório o envio do objeto payload e todas as suas propriedades;
Em flows que possuem Validação (1:1), é obrigatório o envio da propriedade bioTokenId.

Dicas:

Consultar Resultado do Processo

Nesta seção, você encontrará como obter o resultado de um processo no by Unico através da API REST

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Consulta do Resultado de Processos no by Unico.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Endpoints:

Consulta do Resultado do Processo

Os processos devem ser criados exclusivamente em uma comunicação backend-to-backend, devido à nossa política de CORS, que impede a criação de processos em uma comunicação frontend-to-backend.

O conteúdo retornado no parâmetro process.services.documents.doc.data, referente à tecnologia de OCR Extração, pode ser consultado abaixo:

Caso não consigamos extrair algum campo do documento, ele não é listado no retorno da API.

Dicas:

Para implementar suas regras de negócio, sempre valide o retorno das capacidades analisando os parâmetros do response na seguinte ordem:
- state = PROCESS_STATE_FINISHED E result = PROCESS_RESULT_OK;
  - ENTÃO, pode realizar a tomada de decisão analisando os retornos do parâmetro authenticationInfo.
  - Caso receba o state = PROCESS_STATE_FINISHED E result = PROCESS_RESULT_ERROR, interprete que houve algum erro no processamento da biometria e tente novamente.
Para melhorar a performance da sua operação, você pode utilizar nossos Webhooks e só consultar o resultado de processos que estiverem nos status finalizados;

Obter Selfie do Usuário

Nesta seção, você encontrará como obter a selfie de um processo no by Unico através da API REST

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Obtenção da Selfie do Usuário no by Unico. Este endpoint fornecerá a selfie, com marca d'água, do usuário final em processos concluídos, permitindo que você a utilize como suporte em casos de contestação por parte do usuário.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Endpoints:

Obtenção da Selfie do Usuário

Os processos devem ser criados exclusivamente em uma comunicação backend-to-backend, devido à nossa política de CORS, que impede a criação de processos em uma comunicação frontend-to-backend.

Pontos importantes:

A liberação da permissão para obter a selfie do usuário dependerá de avaliação interna da Unico. Entenda com o responsável do seu projeto se poderá consumir este serviço;
Só é possível recuperar a selfie com a marca d'água.

Obter Conjunto Probatório

Nesta seção, você encontrará como obter o conjunto probatório de um processo no by Unico através da API REST

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Obtenção do Conjunto Probatório no by Unico. Este endpoint fornecerá o conjunto probatório da transação biométrica finalizada, permitindo que você o armazene para possíveis contestações futuras por parte do usuário final.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Endpoints:

Obtenção do Conjunto Probatório

Os processos devem ser criados exclusivamente em uma comunicação backend-to-backend, devido à nossa política de CORS, que impede a criação de processos em uma comunicação frontend-to-backend.

O conjunto probatório só está disponível para os processos finalizados.

Especificação do conjunto probatório

Nesta seção, você encontrará todas as especificações do conjunto probatório do by Unico

O conjunto probatório é um documento em .pdf contendo evidências de autenticação de um usuário que realizou a validação de identidade no by Unico.

A seguir, veja como este documento é representado, bem como a especificação de seus campos de retorno:

Campos do Conjunto Probatório (clique em cada um para saber mais)

Usuário

Foto com marca d'água;
Nome - indica o nome da pessoa autenticada. Esse dado é obtido através do parâmetro person.friendly_name do CreateProcess;
CPF do titular - indica o CPF da pessoa autenticada. Esse dado é obtido através do parâmetro person.dui_value do CreateProcess;
Canal de contato - indica o canal de comunicação com a pessoa autenticada. Esse dado é obtido através do parâmetro person.notifications do CreateProcess.

Processo

Fluxo executado - indica qual fluxo foi executado. Esse dado é obtido através do parâmetro flow do CreateProcess;
Identificador do processo - indica o id do processo. Esse dado é obtido através do parâmetro procees.id no retorno do CreateProcess;
URL - indica a URL de autenticação do processo;
Criação - indica a data da criação do processo. Esse dado é obtido através do parâmetro createdAt no retorno do CreateProcess;
Finalização - indica a data de finalização do processo. Esse dado é obtido através do parâmetro finishedAt no retorno do CreateProcess;
Estado - indica o status do processo. Esse dado é obtido através do parâmetro state no retorno do CreateProces;
Empresa - indica a empresa.

Validações

Tipo de validação - indica o tipo de validação da autenticação do processo;
Identidade - indica resultado da Verificação de Identidade;
Detecção de vida - indica resultado da Prova de vida.

Dados de navegação

Sistema operacional e navegador - indica os dados do dispositivo;
Endereço do IP - indica o IP do dispositivo.

Evidências de uso dos módulos nos flows iddocs, idsign e iddocssign

Quando o processo envolve os fluxos de IDDocs e Sign, o conjunto probatório também retorna dados desses fluxos como:

Documentos:

Tipo de documento - identifica o documento compartilhado pela pessoa. Ex: CNH / RG;
Modulo de coleta - caso Sim, identifica se houve a captura de um documento;
Documento validado - caso Sim, identifica que o documento compartilhado/reutilizado foi validado.

Assinatura:

Dados do Envelope - indica os documentos e seus assinantes;
ID do envelope - UUID que identifica o envelope no Unico Sign

Essas evidências podem ser utilizadas para garantir a autenticidade do processo.

O conjunto probatório só está disponível para os processos finalizados.

Obter Documento Assinado

Nesta seção, você encontrará como obter o documento assinado de um processo no by Unico através da API REST

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Obtenção do Documento Assinado no by Unico. Este endpoint fornecerá o documento assinado do usuário final em fluxos que possuem a capacidade Assinatura Eletrônica.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Endpoints:

Obtenção do Documento Assinado

Exemplo de um documento gerado:

Caso o retorno do documento assinado via by Unico apresente atraso no processamento, recomendamos aguardar pelo menos um minuto após a conclusão do processo antes de realizar a consulta. Adicionalmente, é importante configurar uma política de tentativa automática (retry) para os casos em que o documento assinado ainda não esteja disponível, como realizar até 10 tentativas com intervalos de 1 a 5 minutos entre elas.

Obter Conjunto Probatório do Documento Assinado

Nesta seção, você encontrará como obter o conjunto probatório do Sign de um processo no by Unico através da API REST

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Obtenção do Conjunto Probatório do Documento Assinado no by Unico. Este endpoint fornecerá o conjunto probatório da assinatura do usuário final em fluxos que possuem a capacidade Assinatura Eletrônica.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Endpoints:

UAT: https://signhom.acesso.io;
Produção: https://sign.acesso.io.

Obtenção do Conjunto Probatório do Documento Assinado

Exemplo de um documento gerado:

Erros

Nesta seção, você encontrará a visão geral sobre os erros que pode receber nos endpoints da plataforma Unico IDCloud

Introdução

A plataforma IDCloud utiliza códigos de resposta HTTP convencionais para indicar o sucesso ou falha de uma solicitação de API.

Como regra geral:

Códigos no intervalo 2xx indicam sucesso na requisição;
Códigos no intervalo 4xx indicam parâmetros incorretos ou incompletos (por exemplo, um parâmetro obrigatório foi omitido ou uma operação falhou com terceiros, etc.);
Códigos no intervalo 5xx indicam que houve um erro nos servidores da plataforma Unico IDCloud.

A plataforma Unico IDCloud também gera uma mensagem de erro e um código de erro formatado em JSON:

Erros possíveis

Neste tópico, você encontrará os possíveis erros dos endpoints, separados por seu HTTP response.

Criar Processo

Não será fornecido nenhum código de erro detalhado para esta situação, apenas o código de status HTTP.

Consultar Resultado do Processo

Obter Selfie do Usuário

Obter Conjunto Probatório

Obter Documento Assinado

Obter Conjunto Probatório do Documento Assinado

Controlando a experiência

Nesta seção, você entrará os componentes de experiência que podem ser utilizados com o by Unico

Redirecionando o usuário

Nesta seção, você encontrará como informações redirecionar um usuário em suas aplicações na experiência do by Unico

Aqui você encontrará as 3 formas de gerenciar a experiência do usuário em suas aplicações:

Também é possível utilizar o link gerado pelo by Unico em frameworks híbridos. Para isso, você pode criar uma bridge entre o framework utilizado com o nativo e seguir como sugerimos na documentação ou utilizar de alguma biblioteca que disponibilize essas opções de integração.

A integração da WebView na sua aplicação é de total responsabilidade do cliente, uma vez que esta funcionalidade não é oferecida como parte das bibliotecas ou SDKs da Unico. Por conta disso, não oferecemos suporte técnico para dúvidas ou problemas relacionados à implementação da WebView em seu aplicativo. Para obter orientações sobre a configuração, recomendamos consultar a documentação oficial da tecnologia utilizada em seu projeto (por exemplo, React Native, Flutter, etc).

Recursos adicionais

Nesta seção, você encontrará os recursos adicionais relacionados ao meio de integração by Unico

API

Nesta seção, você encontrará todas as APIs REST disponíveis para utilização do meio de integração by Client

Recursos adicionais

Nesta seção, você encontrará os recursos adicionais relacionados ao meio de integração by Client

SDK

Nesta seção, você encontrará todas as especificações técnicas dos SDK's disponíveis da plataforma Unico IDCloud

Integração SDKs

Nesta seção, você encontrará todas as informações necessárias pra implementar os SDKs da plataforma Unico IDCloud

SDK Android

Nesta seção, você encontrará todas as informações necessárias pra implementar o SDK Android da plataforma Unico IDCloud

SDK iOS

Nesta seção, você encontrará todas as informações necessárias pra implementar o SDK iOS da plataforma Unico IDCloud

SDK Flutter

Nesta seção, você encontrará todas as informações necessárias pra implementar o SDK Flutter da plataforma Unico IDCloud

SDK Web

Nesta seção, você encontrará todas as informações necessárias pra implementar o SDK Web da plataforma Unico IDCloud

Recursos adicionais

Nesta seção, você encontrará os recursos adicionais relacionados à SDK

help & faq

Preparando para fazer uma requisição autenticada à API

Nesta seção, você encontrará como realizar o processo de autenticação na plataforma Unico IDCloud

Após a criação e configuração de uma conta de serviço, sua aplicação precisa completar as seguintes etapas:

Criar um JSON Web Token (JWT), que inclui cabeçalho, payload e assinatura;
Requisitar um token de acesso (AccessToken) da plataforma de autenticação OAuth2;
Tratar a resposta JSON que a plataforma de autenticação retornará.

1 - Criando o JWT

Um JWT é composto da seguinte forma:

{Cabeçalho em Base64url}.{Payload em Base64url}.{Assinatura em Base64url}

O texto base para a assinatura é composto pela seguinte forma:

{Cabeçalho em Base64url}.{Payload em Base64url}

1.1 - Formando o cabeçalho JWT

{"alg":"RS256","typ":"JWT"}

A representação em Base64url se dá da seguinte forma:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

1.2 - Formando o payload JWT

1.3 - Campos Obrigatórios

Os campos obrigatórios no JWT são mostrados na tabela abaixo. Eles podem aparecer em qualquer ordem dentro do payload.

Nome

Descrição

iss

O identificador da conta de serviço na empresa.

scope

aud

Endereço da plataforma de autenticação que faz a emissão de tokens de acesso. Este valor deverá ser sempre e exatamente .

Casos recorrentes que NÃO funcionam:

Inserção de uma barra ao final do endereço: ;
Uso do protocolo HTTP ao invés de HTTPS: .

exp

Casos recorrentes que NÃO funcionam:

Uso de aspas na delimitação do valor. Ex.: “1524161193” é uma string e não funcionará. Já 1524161193 é um número e funcionará.

iat

O momento da emissão do JWT, especificado em segundos desde 00:00:00 UTC, 1 de Janeiro de 1970. Este valor deve ser numérico.

Uso de aspas na delimitação do valor. Ex.: “1524161193” é uma string e não funcionará. Já 1524161193 é um número e funcionará.

exp = iat + 3600

A representação dos campos JSON obrigatórios no payload do JWT se dá da seguinte forma:

{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, // Este é apenas um exemplo. Utilize aqui o valor atual gerado.
  "iat": 1626293376 // Este é apenas um exemplo. Utilize aqui o valor atual gerado.
}

1.4 - Calculando a assinatura

{Cabeçalho em Base64url}.{Payload em Base64url}

{Cabeçalho em Base64url}.{Payload em Base64url}.{Assinatura em Base64url}

A seguir está um exemplo de token JWT antes da codificação em Base64url:

{"alg":"RS256","typ":"JWT"}.
{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, // Este é apenas um exemplo. Utilize aqui o valor atual gerado.
  "iat": 1626293376 // Este é apenas um exemplo. Utilize aqui o valor atual gerado.
}.
[byte array da assinatura]

Abaixo está um exemplo do JWT que foi assinado e está pronto para transmissão:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY291bnRf
bmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb
3BlIjoiKiIsImV4cCI6MTYyNjI5Njk3NiwiaWF0IjoxNjI2MjkzMzc2fQ.JsymP3NZdgCSqeNlgsOM2
-AQ7M450NxFnZnnaKSu4Q8g12QGEIvvM4EhCokUHfwk5s7pOpm2UD_Ng3Hb5g_wgrjfiVSLWH5Q2wYg1AvfLqo
YSoJWaMHm9KL0kpv32XdDD8TZVR-MVd2VBHmCMVbV6gvk8buUoK1HZDN7g84PaY3bfgcB3RKU-
H55lR8yyJjZxToIv17-wfla2G99uaMEFNGX0ZSE7ETn5Z8-WypmFrNAK0TM58upzvfVI6_-
gY4cj4iQvmRbuvxsAaGiHA2xd0RVm2Mrx-gQtdPqtbZPuQcH7k64Z_EOQBgiGTgVjucyHD6zBijr_P-
2mhIxuecNSw

Também é possível utilizar bibliotecas previamente estabelecidas para realizar a criação do JWT. Como referência, é possível encontrar uma lista de bibliotecas no site .

2 - Fazendo a requisição de um token de acesso

https://identityhomolog.acesso.io/oauth2/token

Os parâmetros abaixo são obrigatórios na requisição POST HTTPS:

Nome

Descrição

grant_type

Utilize o seguinte texto, URL-encoded se necessário: urn:ietf:params:oauth:grant-type:jwt-bearer

assertion

O JWT, incluindo a assinatura.

POST /oauth2/token HTTP/1.1
Host: identityhomolog.acesso.io
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-
bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY
291bnRfbmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsInN1YiI6InVzZXJfaWRlbnRpZmllciIs
ImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb3BlIjoiKiIsImV4cCI
6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.TjH-mTtwP6tBB93O1sDPaAA6yUF7N2-HZDlpIPz
bf_dxO8A6KZuRWG8ZnICrxX56qj0HREiMlYy27XJgxowrUa0JHvbqc8HJkT7-6Mh7J67UnubZKG1-hi
6jDtkC9BIXBcOhtkNUfZvZetXjLzsRsSDkqxdMtzYZwkRlocvaxL5QXiQhweeEwK_Ux81Adh3z0EIhT
yl7CKJLJ69PuHS7s9IdrjUl79owipp4LF1FvtMhoe7YIL69ohPgFqSv_-Y9qpPdW6be3OEAyKlOM08S
ZBbHBwW4XMvw3uZjTY1sgJ4cBoxrftDpjYOw34oPOKxirqc5-90uOCYe1O1hRtG45w

3 - Tratando a resposta da plataforma de autenticação

{
  "access_token": "<access_token>",
  "token_type": "Bearer",
  "expires_in": "3600"
}

O token de acesso retornado no campo “acess_token” do objeto JSON também é um token JWT que deverá ser utilizado nas APIs dos Produtos da unico. Caso retorne um erro na requisição, é possível consultar o tipo do erro na tabela de erros clicando .

4 - Duração do token de acesso

Não solicite um novo token de acesso até que a validade do token atual esteja chegando ao fim. Sugerimos uma margem de 600 segundos (10 minutos). Para isso execute o cálculo:

token decodificado:
new Date(token.exp - 600)

Sendo que token.exp é o timestamp da expiração do token.

Por padrão, o token enviado para a empresa tem duração de 1h, mas pode ser alterado. A sugestão é sempre usar o expires_in como base e subtrair 600s dele para pedir um novo token.

Exemplos:

Cenário padrão:
expires_in: 3600 (1h) - Geração do token as 14h42

Solicitar um novo token somente as 15h32 ou seja, 14:42 + (3600 - 600)

Cenário com a duração alterada:
expires_in: 7200 (2h) - Geração do token as 14h42

Solicitar um novo token somente as 16h32 ou seja, 14:42 + (7200 - 600)

Um novo token de acesso pode ser solicitado quando faltar 10 minutos pra expirar.

¹ De acordo com o RFC 4648 de codificação BaseN, o formato Base64url é similar ao formato Base64, com exceção do caracter = que deve ser omitido, e dos caracteres + e / que devem ser substituídospor - e _, respectivamente.
² JSON Web Signature: .

Dúvidas?

Não encontrou algo ou ainda precisa de ajuda? Se já é um cliente ou parceiro, pode entrar em contato através da .

Release notes

Nesta seção, você encontrará todas as atualizações do SDK Android

Mantenha seu SDK Android sempre atualizado com a última versão disponível.

Guia de atualização para versão 5.x.x

A atualização major que esta sendo implementada a partir da versão 5.x.x deveria ter sido realizada no lançamento da versão 4.4.0. Esta alteração está relacionada à ofuscação de código e exige ajustes nas regras do ProGuard e do DexGuard para clientes que utilizam a biblioteca da GuardSquare.

Atualização do SDK e server de Liveness com interação;
Melhorias internas de produto. Essas melhorias não afetam diretamente a experiência do usuário final, mantendo a interface e funcionalidades externas inalteradas;

Atualização Crítica

Reforço na detecção e proteção contra ataques de injeção no dispositivo e servidor envolvendo inteligência artificial;
Reforços críticos na camada de RASP com aprimoramento na detecção de ameaças críticas, e medidas que eliminam a exploração contínua por fraudadores;
Melhorias na camada do motor de liveness contra ataques recorrentes no mercado;

Melhorias de acessibilidade;
Atualização do SDK e server de Liveness com interação;
Melhorias internas de produto. Essas melhorias não afetam diretamente a experiência do usuário final, mantendo a interface e funcionalidades externas inalteradas;
Reforço na proteção RASP: detecção de ameaças agora resulta no encerramento imediato da aplicação, com melhorias nas verificações de injeção de vídeo no dispositivo e no servidor para mitigar riscos de IA generativa;

Ajustes de dependências internas garantindo a compatibilidade com a versão de kotlin 1.6.0;

Suporte a câmera traseira em fluxos de lojas físicas;
Atualização do SDK e server de Liveness com interação;
Melhorias internas de produto. Essas melhorias não afetam diretamente a experiência do usuário final, mantendo a interface e funcionalidades externas inalteradas.

Atualização do SDK e server de Liveness com interação. Melhorias internas de produto. Essas melhorias não afetam diretamente a experiência do usuário final, mantendo a interface e funcionalidades externas inalteradas.

Atualização do SDK e server do Liveness com interação.

Atualização do SDK e server do Liveness com interação.

Nessa versão atualizamos o compileSdkVersion para a API 34, de acordo com as políticas do Google Play

Atualização do SDK e server do Liveness com interação.

Atualização do SDK e server do Liveness com interação.

Atualização do SDK e server do Liveness com interação;
Melhorias internas no produto, sem impacto externo.

Correção na câmera de documento, onde em alguns cenários ocorria um crash após a captura.

Atualização do SDK e server do Liveness com interação;
Melhorias internas no produto, sem impacto externo;

Versão 5.22.0 - 19/09/2024

Atualização do SDK e server do Liveness com interação;
Melhorias internas no produto, sem impacto externo.

Correção na resposta das requisições internas da sdk, onde em alguns casos quando não havia internet, o callback de erro não era devolvido e mantinha o usuário preso na tela.

Melhorias internas no produto, sem impacto externo.

Versão 5.20.0 - 20/08/2024

Melhorias internas no produto, sem impacto externo.

Versão 5.19.2 - 13/08/2024

Correção de localização setLocale() na captura com Liveness interativo.

Correção de erros internos que não afetam a experiência do usuário final.

Melhorias internas de produto. Essas melhorias não afetam diretamente a experiência do usuário final, mantendo a interface e funcionalidades externas inalteradas.

Melhorias de segurança em nosso Liveness;
A partir de agora, os desenvolvedores serão notificados em tempo real durante o desenvolvimento se a versão utilizada não estiver em conformidade com as políticas de atualização da Unico. Em casos de dúvidas, contacte o seu CSM;
A partir de agora, é possível definir o ambiente da SDK pela própria API pública no método setEnvironment() . Em casos de dúvidas, contate o seu CSM.

Atualização Crítica

A partir dessa versão não damos mais suporte para versões anteriores ou iguais ao gradle 7.5

Atualização do SDK e server do Smartlive com interação.

Melhorias nos algoritmos de comunicação entre o clientside e serverside unico.

Correção do erro current host is not registred em ambiente de homologação.

Melhorias internas no produto, sem impacto externo.

Atualização Crítica

Atualização do SDK e server do Smartlive com interação;
Melhorias nas verificações de injeção de vídeo recentemente adicionadas no lado do dispositivo e no lado do servidor para mitigar ameaças de IA generativa.

Atualização Crítica

Atualização do SDK e server do Smartlive com interação;
Melhorias nas verificações de injeção de vídeo recentemente adicionadas no lado do dispositivo e no lado do servidor para mitigar ameaças de IA generativa.

Melhorias e correções na inicialização da SDK, evitando a perda de 1.5% das sessões.

Atualização do SDK e server do Smartlive com interação.

Novas funcionalidades que melhoram a experiência de captura no Liveness Interativo.

Melhorias nas verificações de injeção de vídeo recentemente adicionadas no lado do dispositivo e no lado do servidor para mitigar ameaças de IA generativa.

Correção no botão de fechar na captura de liveness interativo, em alguns cenários uma tela de loading pode aparecer por tempo indeterminado.

Correção no ciclo de vida da captura, em cenários onde a tela é encerrada antes do callback de sucesso ou erro.

Correção na geolocalização, em cenários onde a aplicação pode parar quando for desabilitada.

Correção na compatibilidade em estilos predefinidos, causando conflitos entre <attr ... />.

Atualização Crítica

Melhorias nas verificações de injeção de vídeo recentemente adicionadas no lado do dispositivo e no lado do servidor para mitigar ameaças de IA generativa;
Nova funcionalidade de captura para garantir segurança eficaz;
Atualização do SDK e server do Smartlive com interação;
Fix camera traseira no modelo Multilaser M8.

Habilitamos a customização da cor da barra de progresso através do método opcional setColorProgressBar();
Habilitamos a customização dos textos da UI do liveness interativo via configuração remota;
Habilitação a customização do logo abaixo do frame de captura do smartlive com interação.

Atualização do SDK e server do Smartlive com interação;
Melhoria interna no produto, sem impacto externo.

Melhorias nos registros de log do SDK;
Melhoria interna no produto, sem impacto externo.

Correção do problema relacionado a orquestração thread's de retorno ao cliente que impactava a captura biométrica quando fluxo de retentativa habilitado.

Essa versão visa proporcionar uma experiência mais estável e eficiente. Requer apenas atualização da SDK.

Disponibilizado código e descrição do erro retornado pelo callback onCameraFailed, facilitando seu monitoramento e mapeamento;
Definição automática de ambientes de produção e homologação no SDK;
Otimização no fluxo de gerar JWT melhorando a performance.

Melhoria no fluxo de autenticação, reduzindo falhas na autenticação de dispositivos com configurações específicas no Sistema Operacional. Essa modificação visa proporcionar uma experiência mais estável e eficiente. Importante destacar que essa melhoria requer apenas a atualização da SDK para que os benefícios sejam integralmente aplicados.

Atualização do SDK e server do Smartlive com interação.

Melhoria internas no produto, sem impacto externo.

Melhorias internas;
Ao receber uma config inválida o erro é retornado pelo callback onCameraFailed e não mais pelo exception do UnicoCheckException.
Hotfix: Câmera de Documento com Liveness habilitado;
Hotfix: Modo escuro não respeita as cores customizadas em alguns dispositivos Xiaomi.

Disponibilizar o novo fluxo de captura e retentativas quando usado o Liveness com Interação (entrar em contato com a único caso queira habilitar essa nova funcionalidade);
Lançar erro 73800 caso haja falha na captura usando o fluxo de retentativa;
Lançar erro 73100 caso haja falha de conexão com internet durante uma requisição;
Removido o timeout do fluxo de captura usando Livenes com Interação.

Hotfix: Corrigido callbacks internos como opcionais prevenindo possíveis erros relacionados a propriedades não inicializadas;
Hotfix: Reforçado a clareza das mensagens de erro para desenvolvedores, em especial quando há ausência da implementação da AcessoBioListener, tornando mais intuitivo o processo de correção;
Hotfix: Alterado as regras de ofuscação para garantir que a classe UnicoCheckException não seja ofuscada e os erros sejam exibidos corretamente no console e nos logs;
Hotfix: Otimizado a inicialização do objeto bioConfig evitando erros internos.

Hotfix: Corrigido um problema na configuração do SDK através do arquivo JSON.

Hotfix: Corrigido erro de caractere afetando build;
Hotfix: Modo baixa luminosidade não altera a cor dos textos.

Hotfix: Aplicação não respondendo, ARN;
Hotfix: Modo alta luminosidade não altera a cor dos texto;
Hotfix: Erro internal exception.

Atualização do SDK client e server do Smartlive com interação.

Melhoria de segurança na comunicação da SDK.

Hotfix: Timeout na câmera traseira.

Atualização do SDK client e server do Smartlive com interação;
Atualização das mensagens do Smartlive com interação;
Atualização da biblioteca de CameraX
Adicionado timeout na câmera de liveness com interação;
Hotfix: Câmera de documento.

Hotfix: compatibilidade com Android 8.0.

Melhoria de compatibilidade com a ferramenta de ofuscação;
Melhoria de segurança na comunicação da SDK;
Nova URL do repositório para download do SDK;
Alteração do nome do SDK de com.github.acesso-io:acessobio-android para io.unico:capture;
Suporte para o Kotlin a partir da versão 1.5.

Atualização do SDK client e server do Smartlive com interação.

Hotfix: Suporte ao tema dark.

Hotfix: Compatibilidade ofuscação.

Hotfix: Geolocalização em casos de endereço nulo;
Hotfix: Tempo de expiração da câmera de documentos;
Hotfix: Implementação de projeto com sentry.

Hotfix: Abertura de camera traseira;
Atualização da versão do modo de câmera de selfie com prova de vida da FaceTec.

Feat: segurança no changelog;
Feat: Atualização da SDK e server do Smartlive com interação.
Fix: Suporte a uso do modo de câmera com captura automática em tablets;
Fix: Conflito com sentry.

Atualização da SDK e server do Smartlive com interação;
Coleta de dados de uso, geolocalização e dispositivo (Os dados coletados são usados para garantir a segurança do processo e melhorar a experiência do usuário);
Correção do bug para abrir a câmera em dispositivos com Android 6.0.1.

Hotfix: Prefixo da url.

Hotfix: Contorno da silhueta na cor branca.

Uma nova camada de segurança;
Atualização da versão do modo de câmera de selfie com prova de vida da FaceTec.

Hotfix: Melhoria da lentidão na main thread;
Hotfix: Tratamento dos retornos de erro onBackPressed, bitmap e no available camera.

Novo incremento de segurança;
Ajuste na resolução das imagens;
Hotfix: Ajuste no uso de captura de documentos usando uma APIKey com Smartlive ativo habilitado;
Hotfix: Ajustes na configuração de timeout da câmera de documentos.

Hotfix: Ajuste no frame de captura de documentos genéricos;
Hotfix: Correção de nomenclaturas que causavam conflito de themes;
Hotfix: Melhoria na coleta de logs de erro.

Indicador de atividade agora possui mesma cor que a mensagem na customização;
Possibilidade de executar os métodos prepareSelfieCamera e prepareDocumentCamera sem o arquivo json, utilizando uma interface do tipo AcessoBioConfigDataSource.

Hotfix: ajuste no lifecycle do frame de captura com interação.

Melhoria da resolução da imagem gerada pelo modo de câmera de selfie com prova de vida da FaceTec para celulares de qualidade média/alta;
Atualização do google play services ML Kit face detection para a versão 17.0.1.

Atualização da versão do modo de câmera de selfie com prova de vida da FaceTec;
Remoção de pedidos de permissões que não estavam sendo usados.

Ajuste no tema padrão para o modo de baixa luminosidade modo de câmera de selfie com prova de vida da FaceTec.

Customização do botão de fechar camera;
Correções de erros na customização de sucesso.

Ajuste para otimizar performance;
Ajuste no seletor de câmera para dispositivos com múltiplas câmeras.

Ajuste nas configurações que geram o objeto encriptado unico;
Correções em configuração de Temas;
Resolução de conflitos com bugfender.

Downgrade do Kotlin para 1.4.0;
Ajuste ao abrir a câmera pela segunda vez.

Correção no encrypted.

Ajuste de dependencias para tornar as bibliotecas do SDK Android compativeis com minCompileSdk 30.

Adicionada compatibilidade com java 8;
Adicionado frames de captura de CNH frente e CNH verso.

Correção de erro no jitpack.

Update da biblioteca GSON para versão 2.8.9;
Ajuste no módulo de abertura de câmera.

Foi corrigido o bug no módulo de abertura da câmera de documentos.

Foi corrigido o bug que deixa o debug lento ao utilizar o SDK Android.

Foi corrigido o bug referente a: request prepare camera.

A partir de agora, o SDK Android conta com a funcionalidade de Prova de Vida. Para atualizar essa nova versão do SDK, solicite junto ao seu gestor de contas a documentação correspondente a nova implementação e ativação da funcionalidade para sua operação;
O SDK Android está ainda mais seguro.

A partir dessa versão é necessário adicionar no projeto o arquivo: unico-check-mobile-services.json. Procure o customer success ou o gestor de contas para ter acesso ao Portal do Cliente e seguir o passo a passo necessário;
Foi disponibilizado mais um frame de captura em documentos: CPF.
Não é permitido o uso da câmera em emuladores.

Ajuste na captura do log de erro.

Correção de espelhamento de imagem ao utilizar a câmera do tipo "Documento".

Mudança na estrutura de classes.

Mudança na estrutura de classes.

Refatoração de funções públicas, permitindo o retorno assync dentro da própria função;
Refatoração nos métodos disableAutoCapture e disableSmartFrame;
Correção de bug de enquadramento de face;
Correção de bug de travamento de tela após a captura.

Troca do motor de tracking biométrico, foi migrado do FirebaseMLVision para FaceDetectorMLKit;
Foi atualizada a API padrão de abertura de câmera, migramos da API de Camera2 para API de CameraX;
Foram obtidos ganhos significativos na gerência de ciclo de vida, memória, processamento e aumentando a compatibilidade de dispositivos que são suportados;
Foi removida a necessidade da implementação do Firebase para o uso das tecnologias do SDK Android, diminuindo consideravelmente a fricção na integração e evitando conflitos que anteriormente ocorriam;
Foram removidos todos os métodos de processos REST da API pública, garbages code e realizamos outras melhorias.

A SDK está mais segura com novos métodos de criptografia em real-time;
A SDK está mais rápida e precisa na detecção de faces com melhorias dos modelos de IA para o câmera inteligente;
Agora é possível configurar o tempo máximo de sessão do seu usuário;
Agora é possível configurar o tempo máximo de captura ao utilizar a detecção da face (smart câmera). Caso o usuário encontre alguma dificuldade para capturar a foto através da detecção de face e ultrapasse o tempo determinado em seu processo, a captura será alterada automaticamente para a manual, visando facilitar a ação para o usuário.
Depreciamos todos os métodos referentes a requisições REST, que outrora permitiam a criação de processos dentro da v3 do unico-onboarding diretamente da SDK.

Nesta versão trazemos grande otimização no tamanho da SDK, diminuindo em 75% do tamanho anterior;
Foram incluidas melhorias de performance.

A SDK está 42% mais leve com a remoção de várias intra-dependências e remoções de garbage-code;
A SDK está mais segura com novos métodos de criptografia em real-time;
A SDK está mais rápida com os novos modelos de IA para o câmera inteligente;
Foram removidos todos os métodos que permitiam acesso ao Liveness com interação.

Foi removido o método de validação REST no fluxo básico de captura de documentos.

Atualização do Firebase ML-Vision 19.0.3 para 24.1.0;
Atualização do Google Services 4.3.3 para 4.3.5.

Agora é possível customizar todos os elementos visuais utilizando também cores no formato hexadecimal. Lembrando que os formatos padrões dos SO's continuam ativos, como UIColor para iOS e Colors para Android;
Foi adicionado um novo método de retorno para notificar a sua classe implementadora no momento em que o usuário fechar a câmera manualmente;
Foi corrigido o retorno do método de FaceMatch, devolvendo o objeto completo com base64 da selfie, base64 do documento e o status de FaceMatch.

Agora é possível customizar todos os elementos visuais utilizando também cores no formato hexadecimal. Lembrando que os formatos padrões dos SO's continuam ativos, como UIColor para iOS e Colors para Android;
Foi adicionado um novo método de retorno para notificar a sua classe implementadora no momento em que o usuário fechar a câmera manualmente;
Foi corrigido o retorno do método de FaceMatch, devolvendo o objeto completo com base64 da selfie, base64 do documento e o status de FaceMatch;
Outras limpezas.

Foi adicionado um novo método de callback (retorno) para notificar a sua classe implementadora no momento em que o usuário fechar a câmera manualmente;
Foi corrigido o callback do método de FaceMatch, devolvendo o objeto completo com base64 da selfie, base64 do documento e o status de facematch;
Outras limpezas.

Novas validações prévias, facilitando a visibilidade de qualquer tipo de anormalidade quanto ao setup previamente a abertura de câmera em si;
Pequenas melhorias e limpeza em toda solução.

Pequenas correções de bugs e melhorias no fluxo de permissões.

Posibilidade de customizar a imagem do ícone de popup de reset de sessão dentro do fluxo do Liveness com interação;
Foi removida a obrigatoriedade da tag allowBackups em AndroidManifest.

Possibilidade de personalizar todos os elementos visuais utilizando cores em formato hexadecimal. Os formatos padrão permanecem ativos;
Foi adicionado um novo método de callback para notificar sua classe implementadora no momento em que o usuário fecha manualmente a câmera;
Foram corrigidos pequenos bugs no fluxo do Liveness com interação;
Corrigido o retorno do método FaceMatch, retornando o objeto completo com base64 da selfie, base64 do documento e o status do FaceMatch.

Guia de tratamento de erros

Nesta seção, você encontrará todas as informações necessárias para o tratamento dos erros do SDK da plataforma Unico IDCloud em seus aplicativos Android

Este objeto é retornado sempre que ocorre um erro no SDK Android.

Métodos disponíveis

Nome do método

Descrição

getCode()

Método utilizado para obter o código de erro ocorrido

getDescription()

Método utilizado para obter a descrição de erro ocorrido

É disponibilizado a seguir a lista de possíveis códigos de erro do SDK Android:

Código

Descrição

73001

Context invalid

73002

Did not grant permission to open camera

73003

The lest API is 21(LOLLIPOP)

73004

Could not find implementation interface callback iAcessoBioSelfie

73005

Could not find implementation interface callback iAcessoBioDocument

73006

Unable to open camera on emulators

73100

Unable to connect to internet

73200

Please inform the json file name

73202

Unable to parse json file

73300

Unable to get unico authentication object

73301

Unable to parse object

73302

Could not find the unico token

73303

Current host is not registered

73400

Could not initialize camera

73500

Unable to get session token, service response error

73501

Unable to parce object

73502

Could not get session token

73701

Could not find active liveness import

73702

Unable to initialize active liveness in production mode

73703

Unable to get active liveness session

73704

The user pressed the cancel button and did not complete the Session.

73705

The Session was not performed successfully and a FaceScan was not generated. In general, other statuses will be sent to the

73706

The camera access is prevented because either the user has explicitly denied permission or the user's device is configured to

73707

The Session was cancelled due to the app being terminated, put to sleep, an OS notification, or the app was placed in the

73708

The Session was cancelled because device is in landscape mode. The user experience of devices in these orientations is poor

73709

The Session was cancelled because device is in reverse portrait mode. The user experience of devices in these orientations is

73710

The Session was cancelled because the user was unable to complete a Session in the default allotted time or the timeout set

73712

The Session was cancelled due to memory pressure.

73712

The Session was cancelled because your App is not in production and requires a network connection.

73713

The Session was cancelled because your key needs to be validated again.

73714

The Session was cancelled because the developer-configured encryption key was not valid.

73715

The Session was cancelled because not all guidance images were configured.

73716

The Session was cancelled because SDK was unable to start the camera on this device.

73717

The Session was cancelled because the user was in a locked out state.

73718

The Session was cancelled because of an unknown and unexpected error. SDK leverages a variety of iOS APIs including camera,

73719

The Session cancelled because user pressed the Get Ready screen subtext message. Note: This functionality is not available by

73800

Could not build encrypted key

Captura de documento

Nesta seção, você encontrará todas as informações necessárias para o uso e integração do SDK da plataforma Unico IDCloud em seus aplicativos Android para a captura do documento

Frames de documentos disponíveis

Neste modo de câmera, existe um frame de captura para auxiliar o usuário a posicionar o documento corretamente. Após posicionar o documento corretamente, o usuário deve clicar no botão para realizar a captura da foto do documento.

A SDK não realiza nenhum tipo de validação do que está sendo capturado.

Neste modo de câmera é possivel capturar os documentos:

CPF: Captura da frente do CPF;
CNH: Captura da CNH aberta;
CNH frente: Captura da frente da CNH;
CNH verso: Captura do verso da CNH;
RG frente: Captura da frente do RG;
RG verso: Captura do verso do RG;
Outros: Captura de qualquer outro documento.

Inicializar o SDK

Crie uma instância do builder (Gerado através da interface IAcessoBioBuilder), fornecendo como parâmetro o contexto em questão e a implementação da classe AcessoBioListener.

A implementação dessa classe é bem simples e pode ser feita com poucas linhas de código. Tudo que precisa fazer é instanciar o builder informando o contexto em questão e sobrescrever os métodos de callback com as lógicas de negócio de sua aplicação:

public class MainActivity extends AppCompatActivity {

    private AcessoBioListener callback = new AcessoBioListener() {
        @Override
        public void onErrorAcessoBio(ErrorBio errorBio) { }

        @Override
        public void onUserClosedCameraManually() { }

        @Override
        public void onSystemClosedCameraTimeoutSession() { }

        @Override
        public void onSystemChangedTypeCameraTimeoutFaceInference() { }
    };

    private IAcessoBioBuilder acessoBioBuilder = new AcessoBio(this, callback);
}

internal class MainActivity : AppCompatActivity() {

    private val callback = object : AcessoBioListener {
        override fun onErrorAcessoBio(errorBio: ErrorBio?) { }
    
        override fun onUserClosedCameraManually() { }
    
        override fun onSystemClosedCameraTimeoutSession() { }
    
        override fun onSystemChangedTypeCameraTimeoutFaceInference() { }
    }

    private val acessoBioBuilder: IAcessoBioBuilder = AcessoBio(this, callback)
}

Implementar as funções de callback

Note que, o trabalho de implementação da classe AcessoBioListener é, em grande parte, a configuração dos métodos de callback. Cada método é chamado em uma situação específica de retorno do SDK.

Basta sobrescrever os métodos exemplificados no passo anterior com as lógicas de negócio de sua aplicação:

onErrorAcessoBio(ErrorBio errorBio)

onUserClosedCameraManually()

Este método é invocado sempre quando o usuário fechar a câmera de forma manual, como por exemplo, ao clicar no botão "Voltar".

onSystemClosedCameraTimeoutSession()

Este método é invocado assim que o tempo máximo de sessão for atingido (Sem capturar nenhuma imagem).

Pode ser configurado no builder através do método setTimeoutSession. Este método deve receber o tempo máximo da sessão em segundos. É possível alterar o tempo máximo de sessão do seu usuário ao utilizar a funcionalidade de detecção do rosto (Câmera de selfie com captura inteligente). Caso ele ultrapasse o tempo determinado em seu processo para capturar a foto, você pode apresentar alguma mensagem personalizável ou instrução ao usuário. O valor padrão é de 40 segundos e seu valor mínimo também é de 40 segundos.

onSystemChangedTypeCameraTimeoutFaceInference()

Este método é invocado assim que o tempo máximo para detecção do rosto de um usuário for atingido (Sem ter nada detectado). Neste caso, o modo de câmera é alterado automaticamente para o modo de captura manual (Sem a silhueta de captura inteligente).

O tempo máximo de captura ao utilizar a detecção do rosto (Câmera de selfie com captura inteligente) é de 13 segundos. Se o usuário encontra alguma dificuldade para captura da foto através da detecção do rosto e ultrapasse o tempo determinado em seu processo, a captura é alterada automaticamente para a manual, tendo como objetivo facilitar a ação para o usuário (TimeoutToFaceInference).

Todos os métodos acima devem ser criados da forma indicada em seu projeto (Mesmo que sem nenhuma lógica). Caso contrário, o projeto não compila com sucesso.

Implementar listeners para eventos da câmera

A implementação destes métodos listeners deve ser feita através de uma instância da classe iAcessoBioSelfie.

O método de abertura da câmera, que é chamado na próxima etapa, precisa saber o que fazer ao conseguir capturar uma imagem com sucesso ou ao ocorrer algum erro no processo. É necessário informar "o que fazer" ao método de abertura da câmera através da implantação de listeners que são chamados em situações de sucesso ou erro.

Através da configuração dos listeners, você pode especificar o que acontece em seu App em situações de erro (Método onErrorDocument) ou sucesso (Método onSuccessDocument) na captura de imagens.

O exemplo abaixo ilustra a configuração dos listeners, build e abertura da câmera:

iAcessoBioDocument cameraListener = new iAcessoBioDocument() {
    @Override
    public void onSuccessDocument(ResultCamera result) { }

    @Override
    public void onErrorDocument(ErrorBio errorBio) { }
};

unicoCheckCamera.prepareDocumentCamera(unicoConfig, new DocumentCameraListener() {
    @Override
    public void onCameraReady(UnicoCheckCameraOpener.Document cameraOpener) {
        cameraOpener.open(DocumentType.CNH, cameraListener);
    }

    @Override
    public void onCameraFailed(String message) {
        Log.e(TAG, message);
    }
});

val cameraListener: iAcessoBioDocument = object : iAcessoBioDocument {
    override fun onSuccessDocument(result: ResultCamera?) {}

    override fun onErrorDocument(errorBio: ErrorBio?) {}
}

unicoCheckCamera.prepareDocumentCamera(unicoConfig, object : DocumentCameraListener {
    override fun onCameraReady(cameraOpener: UnicoCheckCameraOpener.Document?) {
        cameraOpener?.open(DocumentType.CNH, cameraListener)
    }

    override fun onCameraFailed(message: String?) {
        Log.e(TAG, message)
    }
})

Preparar e abrir câmera

É necessário criar uma instância do builder através do método build(). Este método é disponibilizado através do objeto gerado com a interface IAcessoBioBuilder e classe AcessoBio:

UnicoCheckCamera unicoCheckCamera = acessoBioBuilder.build();

val unicoCheckCamera = acessoBioBuilder.build()

O próximo passo é preparar a câmera utilizando o método prepareDocumentCamera() com o objeto retornado pelo builder (Nomeado como UnicoCheckCamera no exemplo acima).

O método prepareDocumentCamera() gera um objeto do tipo UnicoCheckCameraOpener.Document, que é utilizado para abrir a câmera com seu método open(), recebendo os parâmetros tipo de documento a ser capturado, sendo eles:

Parâmetro

Descrição

DocumentCameraType.CPF

Frame para captura da frente do CPF

DocumentCameraType.CNH

Frame para captura da CNH aberta

DocumentCameraType.CNH_FRENTE

Frame para captura da frente da CNH

DocumentCameraType.CNH_VERSO

Frame para captura do verso da CNH

DocumentCameraType.RG_FRENTE

Frame para captura da frente do RG

DocumentCameraType.RG_VERSO

Frame para captura do verso do RG

DocumentCameraType.None

Frame para captura de qualquer outro documento

Caso precise capturar um documento que não possuímos um frame específico (ex: RNE, entre outros), utilize o frame DocumentCameraType.None, que irá te possibilitar um frame genérico, retangular, que pode ser utilizado para orientar qualquer captura.

Método `onSucessDocument`

Ao efetuar uma captura de imagem com sucesso, este método é invocado e retorna um objeto do tipo ResultCamera que é utilizado posteriormente na chamada das APIs REST:

public void onSuccessDocument(ResultCamera result) { }

O objeto ResultCamera retorna 2 atributos: base64 e encrypted:

O atributo base64 pode ser utilizado se quiser exibir uma prévia da imagem em seu app;

Método `onErrorDocument`

Ao ocorrer algum erro na captura de imagem, este método é invocado e retorna um objeto do tipo ErrorBio:

public void onErrorDocument(ErrorBio errorBio) { }

Realize um requisição POST na API REST do by Client

Captura de Selfie

Nesta seção, você encontrará todas as informações necessárias para o uso e integração do SDK da plataforma Unico IDCloud em seus aplicativos Android para a captura da selfie

Inicializar o SDK

Crie uma instância do builder (Gerado através da interface IAcessoBioBuilder), fornecendo como parâmetro o contexto e ambiente em questão e a implementação da classe AcessoBioListener.

public class MainActivity extends AppCompatActivity {

    private AcessoBioListener callback = new AcessoBioListener() {
        @Override
        public void onErrorAcessoBio(ErrorBio errorBio) { }

        @Override
        public void onUserClosedCameraManually() { }

        @Override
        public void onSystemClosedCameraTimeoutSession() { }

        @Override
        public void onSystemChangedTypeCameraTimeoutFaceInference() { }
    };

    private IAcessoBioBuilder acessoBioBuilder = new AcessoBio(this, callback);
}

internal class MainActivity : AppCompatActivity() {

    private val callback = object : AcessoBioListener {
        override fun onErrorAcessoBio(errorBio: ErrorBio?) { }
    
        override fun onUserClosedCameraManually() { }
    
        override fun onSystemClosedCameraTimeoutSession() { }
    
        override fun onSystemChangedTypeCameraTimeoutFaceInference() { }
    }

    private val acessoBioBuilder: IAcessoBioBuilder = AcessoBio(this, callback)
}

Configuração de ambientes

Configure o ambiente que será utilizado na execução da SDK. Utilize o enumerado Environment que contém os seguintes enumerados:

Environment.PROD: para ambiente de Produção;
Environment.UAT: para ambiente de Homologação.

Veja como implementar no exemplo abaixo:

acessoBioBuilder.setEnvironment(Environment.UAT);

acessoBioBuilder.setEnvironment(Environment.UAT);

Implementar as funções de callback

Note que, o trabalho de implementação da classe AcessoBioListener é, em grande parte, a configuração dos métodos de callback. Cada método é chamado em uma situação específica de retorno do SDK.

Basta sobrescrever os métodos exemplificados no passo anterior com as lógicas de negócio de sua aplicação.

Este método é invocado sempre que qualquer erro de implementação ocorrer ao utilizar algum de nossos métodos:

onErrorAcessoBio(ErrorBio errorBio)

onUserClosedCameraManually()

Este método é invocado sempre quando o usuário fechar a câmera de forma manual, como por exemplo, ao clicar no botão "Voltar".

onSystemClosedCameraTimeoutSession()

Este método é invocado assim que o tempo máximo de sessão for atingido (Sem capturar nenhuma imagem).

onSystemChangedTypeCameraTimeoutFaceInference()

Todos os métodos acima devem ser criados da forma indicada em seu projeto (Mesmo que sem nenhuma lógica). Caso contrário, o projeto não compila com sucesso.

Configurar modo de câmera

O SDK tem configurado e habilitado por padrão o enquadramento inteligente e a captura automática. Em função disso, deve-se configurar o modo de câmera no seu builder da seguinte forma:

UnicoCheckCamera unicoCheckCamera = acessoBioBuilder
    .setAutoCapture(true)
    .setSmartFrame(true)
    .build();

val unicoCheckCamera: UnicoCheckCamera = acessoBioBuilder
    .setAutoCapture(true)
    .setSmartFrame(true)
    .build()

Os valores false/true dos métodos acima não alteram a experiência de captura, servem apenas para a lógica interna do funcionamento do SDK.

Implementar listeners para eventos da câmera

A implementação destes métodos listeners deve ser feita através de uma instância da classe iAcessoBioSelfie.

Através da configuração dos listeners, você pode especificar o que acontece em seu App em situações de erro (Método onErrorSelfie) ou sucesso (Método onSuccessSelfie) na captura de imagens.

Mudanças da nomenclatura para as versões inferiores a 4.2.1:

Do método prepareCamera que antes era prepareSelfieCamera;
Da classe CameraListener que antes era SelfieCameraListener;
Do objeto UnicoCheckCameraOpener.Camera que antes era UnicoCheckCameraOpener.Selfie.

Para a configuração dos listeners, é necessário implementar:

iAcessoBioSelfie cameraListener = new iAcessoBioSelfie() {
    @Override
    public void onSuccessSelfie(ResultCamera result) { }

    @Override
    public void onErrorSelfie(ErrorBio errorBio) { }
};

unicoCheckCamera.prepareCamera(unicoConfig, new CameraListener() {
    @Override
    public void onCameraReady(UnicoCheckCameraOpener.Camera cameraOpener) {
        cameraOpener.open(cameraListener);
    }

    @Override
    public void onCameraFailed(String message) {
        Log.e(TAG, message);
    }
});

val cameraListener: iAcessoBioSelfie = object : iAcessoBioSelfie {
    override fun onSuccessSelfie(result: ResultCamera?) {}

    override fun onErrorSelfie(errorBio: ErrorBio?) {}
}

unicoCheckCamera.prepareCamera(unicoConfig, object : CameraListener {
    override fun onCameraReady(cameraOpener: UnicoCheckCameraOpener.Camera?) {
        cameraOpener?.open(cameraListener)
    }

    override fun onCameraFailed(message: String?) {
        Log.e(TAG, message)
    }
})

Preparar e abrir câmera

Quando a câmera estiver preparada, é disparado o evento onCameraReady, que recebe como parâmetro um objeto do tipo UnicoCheckCameraOpener.Camera.

É necessário sobrescrever este método, efetuando a abertura da câmera com o objeto recebido através do método open(). O método open() deve receber como parâmetro os listeners configurados nos passos acima.

Método `onSucessSelfie`

Ao efetuar uma captura de imagem com sucesso, este método é invocado e retorna um objeto do tipo ResultCamera que é utilizado posteriormente na chamada das APIs REST:

public void onSuccessSelfie(ResultCamera result) { }

O objeto ResultCamera retorna 2 atributos: base64 e encrypted:

O atributo base64 pode ser utilizado se quiser exibir uma prévia da imagem em seu app;

O atributo encrypted é destinado estritamente ao envio da imagem através das APIs do by Client. Não se deve abrir e serializar esse atributo, pois suas características podem ser alteradas sem aviso prévio. Seu uso deve ser exclusivo nas interações com as APIs para garantir a integridade e segurança dos dados. A Unico não se responsabiliza por quaisquer danos decorrentes dessa prática, uma vez que as modificações podem ocorrer de maneira imprevista.
Os arquivos base64/encrypted podem sofrer variações de tamanho de acordo com diversas variáveis, dentre elas, a qualidade dos aparelhos e das fotos geradas pelos mesmos e regras de negócio da Unico. Para não encontrar problemas em sua aplicação, não limite em sua lógica de programação ou sua infraestrutura o tamanho da string gerada pela SDK para os arquivos.

Método `onErrorSelfie`

Ao ocorrer algum erro na captura de imagem, este método é invocado e retorna um objeto do tipo ErrorBio:

public void onErrorSelfie(ErrorBio errorBio) { }

Realize um requisição POST na API REST do by Client

Por motivos de segurança, o intervalo entre a geração do encrypted e o envio via um dos fluxos disponíveis deve ser de até no máximo 10 minutos. Envios feitos além deste período serão rejeitados automaticamente pela API.

Guia de tratamento de erros

Nesta seção, você encontrará todas as informações necessárias para o tratamento dos erros do SDK da plataforma Unico IDCloud em seus aplicativos iOS

Este objeto é retornado sempre que ocorre um erro no SDK iOS.

Métodos disponíveis

Nome do método

Descrição

getCode()

Método utilizado para obter o código de erro ocorrido

getDescription()

Método utilizado para obter a descrição de erro ocorrido

É disponibilizado a seguir a lista de possíveis códigos de erro do SDK iOS:

Código

Descrição

73000

The Session was cancelled because of an unknown and unexpected error. The Unico Check SDK leverages a variety of iOS APIs including camera, storage, security, networking, and more. This return value is a catch-all for errors experienced during normal usage of these APIs.

73001

Context invalid

73003

The API version needs to be 12 or newer.

73006

Unable to open camera on emulators

73100

Unable to connect to internet

73200

Could not find the unico_sdk json file

73202

Unable to load unico_sdk json file

73203

Unable to load AcessoBioConfigDataSource

73204

Unable to initialize the SDK, please configure the environment on setEnviroment method of build.

73300

Unable to get unico authentication object

73301

Unable to parse unico authentication object

73302

Could not find the unico token

73701

Could not find active liveness import

73702

Unable to initialize active liveness in production mode

73703

Unable to get active liveness session

73704

The user pressed the cancel button and did not complete the Session.

73705

The Session was not performed successfully and a FaceScan was not generated. In general, other statuses will be sent to the developer for specific unsuccess reasons.

73706

The camera access is prevented because either the user has explicitly denied permission or the user's device is configured to not allow access by a device policy.

73707

The Session was cancelled due to the app being terminated, put to sleep, an OS notification, or the app was placed in the background.

73708

The Session was cancelled because the device is in landscape mode. The user experience of devices in these orientations is poor and thus portrait is required.

73709

The Session was cancelled because the device is in reverse portrait mode. The user experience of devices in these orientations is poor and thus portrait is required.

73710

The Session was cancelled because the user was unable to complete a Session in the default allotted time or the timeout set by the developer.

73711

The Session was cancelled due to memory pressure.

73712

The Session was cancelled because your App is not in production and requires a network connection.

73713

The Session was cancelled because your key needs to be validated again.

73714

The Session was cancelled because the developer-configured encryption key was not valid.

73715

The Session was cancelled because not all guidance images were configured.

73716

The Session was cancelled because SDK was unable to start the camera on this device.

73717

The Session was cancelled because the user was in a locked out state.

73718

The Session was cancelled because of an unknown and unexpected error. SDK leverages a variety of iOS APIs including camera, storage, security, networking, and more. This return value is a catch-all for errors experienced during normal usage of these APIs.

73719

The Session was cancelled because the user pressed the Get Ready screen subtext message. Note: This functionality is not available by default, and must be requested from FaceTec in order to enable it.

73720

The Session was not processed.

73721

The Session can't be performed: attempts limit exceeded.

73722

The Session can't be performed: face alignment timeout.

73730

Unable to initialize an active liveness session because of an unknown and unexpected license error.

73731

Unable to initialize an active liveness session because the license has expired.

73800

Could not build encrypted key

Captura de documento

Nesta seção, você encontrará todas as informações necessárias para o uso e integração do SDK da plataforma Unico IDCloud em seus aplicativos iOS para a captura do documento

Frames de documentos disponíveis

A SDK não realiza nenhum tipo de validação do que está sendo capturado.

Neste modo de câmera é possivel capturar os documentos:

RG: Captura do RG (separado em frente e verso);
CNH: Captura da CNH aberta;
CNH frente: Captura da frente da CNH;
CNH verso: Captura do verso da CNH;
CPF: Captura do documento de CPF;
Sem silhueta: Captura documento genérico.

Inicializar o SDK

Para iniciar com SDK iOS da plataforma Unico IDCloud, importe o SDK e implemente a interface AcessoBioManagerDelegate dentro da ViewController que deseja utilizar.

A implementação dessa classe é bem simples e pode ser feita com poucas linhas de código. Tudo que precisa fazer é intanciar o builder informando o contexto em questão e sobrescrever os métodos de callback com as lógicas de negócio de sua aplicação:

.m:
#import "ViewController.h"
#import <AcessoBio/AcessoBio.h>

@interface ViewController ()
@end

@implementation ViewController
- (void)viewDidLoad {
    [super viewDidLoad];   
    unicoCheck = [[AcessoBioManager alloc]initWithViewController:self];
}
   
- (void)onErrorAcessoBioManager:(ErrorBio *)error {
  // Your code
}

- (void)onSystemChangedTypeCameraTimeoutFaceInference {
  // Your code
}

- (void)onSystemClosedCameraTimeoutSession {
  // Your code
}

- (void)onUserClosedCameraManually {
  // Your code
}

@end

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate {
  var unicoCheck: AcessoBioManager!

  override func viewDidLoad() {
    super.viewDidLoad()
    
    unicoCheck = AcessoBioManager(viewController: self)
  }

  func onErrorAcessoBioManager(_ error: ErrorBio!) {
    // Your code
  }

  func onUserClosedCameraManually() {
    // Your code
  }

  func onSystemClosedCameraTimeoutSession() {
    // Your code
  }

  func onSystemChangedTypeCameraTimeoutFaceInference() {
    // Your code
  }
}

Implementar as funções de callback

Note que, conforme o exemplo anterior, o trabalho de implementação da interface AcessoBioManagerDelegate é, em grande parte, a configuração dos métodos de callback. Cada método é chamado em uma situação específica de retorno do SDK.

Basta sobrescrever os métodos exemplificados no passo anterior com as lógicas de negócio de sua aplicação:

onErrorAcessoBioManager(_ error: ErrorBio!)

Este método é invocado quando qualquer erro de implementação ocorrer ao utilizar algum dos métodos, como por exemplo, ao informar um tipo de documento incorreto para a funcionalidade de captura de documentos.

onUserClosedCameraManually()

Este método é invocado sempre quando o usuário fechar a câmera de forma manual, como por exemplo, ao clicar no botão "Voltar".

onSystemClosedCameraTimeoutSession()

Este método é invocado assim que o tempo máximo de sessão for atingido (Sem capturar nenhuma imagem).

onSystemChangedTypeCameraTimeoutFaceInference()

Todos os métodos acima devem ser criados da forma indicada em seu projeto (Mesmo que sem nenhuma lógica). Caso contrário, o projeto não compila com sucesso.

Implementar delegates para eventos da câmera

O método de abertura da câmera (que é chamado no próximo passo) precisa saber o que fazer ao conseguir capturar uma imagem com sucesso ou ao ter algum erro no processo. É informado "o que fazer" ao método de abertura da câmera através da configuração de delegates que são chamados em situações de sucesso ou erro.

Através da configuração dos delegates, você pode especificar o que acontece em seu App em situações de erro (método onErrorDocument) ou sucesso (método onSuccessDocument) na captura de imagens.

Para a configuração dos delegates, você deve implementar as interfaces DocumentCameraDelegate e AcessoBioDocumentDelegate:

.h:
#import <UIKit/UIKit.h>
#import <AcessoBio/AcessoBio.h>
#import "SelfieCameraDelegate.h"

@interface ViewController: UIViewController <AcessoBioManagerDelegate, DocumentCameraDelegate, 
  AcessoBioDocumentDelegate> {
  AcessoBioManager *unicoCheck;
  // Your code from previous and next steps here
}

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate, DocumentCameraDelegate, 
  AcessoBioDocumentDelegate {    
  // Your code from previous and next steps here
}

Método `onSucessDocument`

Ao efetuar uma captura de imagem com sucesso, este método é invocado e retorna um objeto do tipo ResultCamera que é utilizado posteriormente na chamada das APIs REST.

- (void)onSuccessDocument:(DocumentResult *)result {
    NSLog(@"%@", result.base64);
}

func onSuccessDocument(_ result: DocumentResult!) {
    // Your code
 }

O objeto ResultCamera retorna 2 atributos: base64 e encrypted:

O atributo base64 pode ser utilizado se quiser exibir uma prévia da imagem em seu app;

Método `onErrorDocument`

Ao ocorrer algum erro na captura de imagem, este método é invocado e retorna um objeto do tipo ErrorBio.

- (void)onErrorDocument:(ErrorBio *)errorBio {
    // Your code
}

func onErrorDocument(_ errorBio: ErrorBio!) {
    // Your code
 }

Preparar e abrir câmera

Para abrir da câmera, é necessário prepará-la utilizando o método prepareDocumentCamera. Este método recebe como parâmetro a implementação da classe DocumentCameraDelegate e o JSON com as credenciais, gerado na etapa acima.

.h:
#import <UIKit/UIKit.h>
#import <AcessoBio/AcessoBio.h>
#import "SelfieCameraDelegate.h"

@interface ViewController: UIViewController < AcessoBioManagerDelegate,
DocumentCameraDelegate, AcessoBioDocumentDelegate> {
    AcessoBioManager *unicoCheck;
}

.m:
- (IBAction)openCamera:(UIButton *)sender {
    [[unicoCheck build] prepareDocumentCamera:self config:[YourUnicoConfigClass new]];
}

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate, 
DocumentCameraDelegate, AcessoBioDocumentDelegate {
    @IBAction func openCamera(_ sender: Any) {
        unicoCheck.build().prepareDocumentCamera(self, config: YourUnicoConfigClass())
    }
}

Quando a câmera estiver preparada, o evento onCameraReadyDocument é disparado, que recebe como parâmetro um objeto do tipo AcessoBioCameraOpenerDelegate.

Você deve sobrescrever este método, efetuando a abertura da câmera com o objeto recebido através do método openDocument(), recebendo os parâmetros tipo de documento a ser capturado, sendo eles:

Parâmetro

Descrição

DocumentEnums.CPF

Frame para captura da frente do CPF

DocumentEnums.CNH

Frame para captura da CNH aberta

DocumentEnums.cnhFrente

Frame para captura da frente da CNH

DocumentEnums.cnhVerso

Frame para captura do verso da CNH

DocumentEnums.RG

Frame para captura do RG aberto

DocumentEnums.rgFrente

Frame para captura da frente do RG

DocumentEnums.rgVerso

Frame para captura do verso do RG

DocumentEnums.none

Frame para captura de qualquer outro documento

Caso precise capturar um documento que não possuímos um frame específico (ex: RNE, entre outros), utilize o frame DocumentEnums.none, que irá te possibilitar um frame genérico, retangular, que pode ser utilizado para orientar qualquer captura.

Os delegates implementados acima (aqui descritos como Self):

- (void)onCameraReadyDocument:(id)cameraOpener {
    [cameraOpener openDocument:DocumentCNH delegate:self];
}

- (void)onCameraFailedDocument:(ErrorPrepare *)message {
  // Your code
}

func onCameraReadyDocument(_ cameraOpener: AcessoBioCameraOpenerDelegate!) {
    cameraOpener.openDocument(DocumentEnums.CNH, delegate: self)
}
 
func onCameraFailedDocument(_ message: ErrorPrepare!) {
  // Your code
}

Caso ocorra algum erro ao preparar a câmera, o evento onCameraFailedDocument é disparado. Você deve implementar este método aplicando as regras de negócio de seu App.

Em caso de sucesso, o evento onSuccessDocument é disparado, conforme explicado na seção acima.

Realize um requisição POST na API REST do by Client

Captura de Selfie

Nesta seção, você encontrará todas as informações necessárias para o uso e integração do SDK da plataforma Unico IDCloud em seus aplicativos iOS para a captura da selfie

Inicializar o SDK

Para iniciar com SDK iOS do Unico Check, importe o SDK e implemente a interface AcessoBioManagerDelegate dentro da ViewController que deseja utilizar.

A implementação dessa classe é bem simples e pode ser feita com poucas linhas de código. Tudo que precisa fazer é instanciar o builder informando o contexto e ambiente em questão e sobrescrever os métodos de callback com as lógicas de negócio de sua aplicação:

.m:
#import "ViewController.h"
#import <AcessoBio/AcessoBio.h>

@implementation ViewController: UIViewController
- (void)viewDidLoad {
    [super viewDidLoad];  
    unicoCheck = [[AcessoBioManager alloc]initWithViewController:self];
}

- (void)onErrorAcessoBioManager:(ErrorBio *)error {
  // your code
}

- (void)onSystemChangedTypeCameraTimeoutFaceInference {
  // your code
}

- (void)onSystemClosedCameraTimeoutSession {
  // your code
}

- (void)onUserClosedCameraManually {
  // your code
}
@end

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate {
  var unicoCheck: AcessoBioManager!

  override func viewDidLoad() {
    super.viewDidLoad()      
    unicoCheck = AcessoBioManager(viewController: self)
  }

  func onErrorAcessoBioManager(_ error: ErrorBio!) {
      // your code
  }

  func onUserClosedCameraManually() {
      // your code
  }

  func onSystemClosedCameraTimeoutSession() {
      // your code
  }

  func onSystemChangedTypeCameraTimeoutFaceInference() {
      // your code 
  }
}

Configuração de ambientes

Configure o ambiente que será utilizado na execução da SDK. Utilize o enumerado Environment que contém os seguintes enumerados:

PROD: para ambiente de Produção;
UAT: para ambiente de Homologação.

Veja como implementar no exemplo abaixo:

 [unicoCheck setEnvironment:UAT];

unicoCheck.setEnvironment(.UAT);

Implementar as funções de callback

Basta sobrescrever os métodos exemplificados no passo anterior com as lógicas de negócio de sua aplicação:

onErrorAcessoBioManager(_ error: ErrorBio!)

onUserClosedCameraManually()

Este método é invocado sempre quando o usuário fechar a câmera de forma manual, como por exemplo, ao clicar no botão "Voltar".

onSystemClosedCameraTimeoutSession()

Este método é invocado assim que o tempo máximo de sessão for atingido (Sem capturar nenhuma imagem).

onSystemChangedTypeCameraTimeoutFaceInference()

Todos os métodos acima devem ser criados da forma indicada em seu projeto (Mesmo que sem nenhuma lógica). Caso contrário, o projeto não compila com sucesso.

Configurar modo de câmera

.m:
- (IBAction)configureSmartCamera:(UIButton *)sender {
   // Objeto unicoCheck da classe AcessoBioManager
   [unicoCheck setSmartFrame:true];
   [unicoCheck setAutoCapture:true];
}

@IBAction func configureSmartCamera(_ sender: Any) {
    // Objeto unicoCheck da classe AcessoBioManager
    unicoCheck.setSmartFrame(true)
    unicoCheck.setAutoCapture(true)    
}

Os valores false/true dos métodos acima não alteram a experiência de captura, servem apenas para a lógica interna do funcionamento do SDK.

Implementar delegates para eventos da câmera

O método de abertura da câmera precisa saber o que fazer ao conseguir capturar uma imagem com sucesso ou ao ter algum erro no processo. É informado "o que fazer" ao método de abertura da câmera através da configuração de delegates que são chamados em situações de sucesso ou erro.

Através da configuração dos delegates, você pode especificar o que acontece em seu App em situações de erro (método onErrorSelfie) ou sucesso (método onSuccessSelfie) na captura de imagens.

Para a configuração dos delegates, você deve implementar as interfaces SelfieCameraDelegate e AcessoBioSelfieDelegate:

.h:
#import <UIKit/UIKit.h>
#import <AcessoBio/AcessoBio.h>
#import "SelfieCameraDelegate.h"

@interface ViewController: UIViewController <AcessoBioManagerDelegate, SelfieCameraDelegate,
   AcessoBioSelfieDelegate> {
  AcessoBioManager *unicoCheck;
  // Your code from previous and next steps here
}

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate,
                      SelfieCameraDelegate, AcessoBioSelfieDelegate {    
  //Your code from previous and next steps here
}

Método `onSuccessSelfie`

Ao efetuar uma captura de imagem com sucesso, este método é invocado e retorna um objeto do tipo SelfieResult que é utilizado posteriormente na chamada das APIs REST.

- (void)onSuccessSelfie:(SelfieResult *)result {
    NSLog(@"%@", result.base64);
}

func onSuccessSelfie(_ result: AcessoBio.SelfieResult!) {
    // Your code
 }

O objeto ResultCamera retorna 2 atributos: base64 e encrypted:

O atributo base64 pode ser utilizado se quiser exibir uma prévia da imagem em seu app;

O atributo encrypted é destinado estritamente ao envio da imagem através das APIs do by Client. Não se deve abrir e serializar esse atributo, pois suas características podem ser alteradas sem aviso prévio. Seu uso deve ser exclusivo nas interações com as APIs para garantir a integridade e segurança dos dados. A Unico não se responsabiliza por quaisquer danos decorrentes dessa prática, uma vez que as modificações podem ocorrer de maneira imprevista.
Os arquivos base64/encrypted podem sofrer variações de tamanho de acordo com diversas variáveis, dentre elas, a qualidade dos aparelhos e das fotos geradas pelos mesmos e regras de negócio da Unico. Para não encontrar problemas em sua aplicação, não limite em sua lógica de programação ou sua infraestrutura o tamanho da string gerada pela SDK para os arquivos.

Método `onErrorSelfie`

Ao ocorrer algum erro na captura de imagem, este método é invocado e retorna um objeto do tipo ErrorBio:

- (void)onErrorSelfie:(ErrorBio *)errorBio {
  // Your code
}

func onErrorSelfie(_ errorBio: ErrorBio!) {
  // Your code
 }

Configurar ambientes

Caso não seja configurado, a SDK usa o ambiente configurado em através do arquivo de configuração (getHostKey). Caso getHostKey não esteja sendo usado, um erro é retornado.

É possível configurar o ambiente que será utilizado na execução da SDK. Utilize o enumerado EnvironmentEnum que contém os seguintes enumerados:

EnvironmentEnum.PROD: para ambiente de Produção
EnvironmentEnum.UAT: para ambiente de Homologação

Veja como implementar no exemplo abaixo:

[unicoCheck setEnvironment:PROD];

unicoCheck.setEnvironment(.PROD);

Preparar e abrir câmera

Para seguir com a abertura da câmera, primeiro deve-se prepará-la utilizando o método prepareSelfieCamera. Este método recebe como parâmetro a implementação da classe SelfieCameraDelegate e o JSON com as credenciais, gerado na etapa acima.

.h:
#import <UIKit/UIKit.h>
#import <AcessoBio/AcessoBio.h>
#import "SelfieCameraDelegate.h"

@interface ViewController: UIViewController <AcessoBioManagerDelegate,
SelfieCameraDelegate, AcessoBioSelfieDelegate> {
    AcessoBioManager *unicoCheck;
}

.m:
- (IBAction)openCamera:(UIButton *)sender {
    [[unicoCheck build] prepareSelfieCamera:self config:[YourUnicoConfigClass new]];
}

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate,
  SelfieCameraDelegate, AcessoBioSelfieDelegate {
    @IBAction func openCamera(_ sender: Any) {
        unicoCheck.build().prepareSelfieCamera(self, config: YourUnicoConfigClass())
    }
}

Quando a câmera estiver preparada, o evento onCameraReady é disparado e recebe como parâmetro um objeto do tipo AcessoBioCameraOpenerDelegate.

Você deve sobrescrever este método, efetuando a abertura da câmera com o objeto recebido através do método open():

- (void)onCameraReady:(id)cameraOpener {
    [cameraOpener open:self];
}

- (void)onCameraFailed:(ErrorPrepare *)message {
    // Your code
}

func onCameraReady(_ cameraOpener: AcessoBioCameraOpenerDelegate!) {
    cameraOpener.open(self)
 }
 
func onCameraFailed(_ message: ErrorPrepare!) {
    // Your code
 }

Caso ocorra algum erro ao preparar a câmera, o evento onCameraFailed é disparado. Você devem implementar este método aplicando as regras de negócio de seu App.

Realize um requisição POST na API REST do by Client

Release notes

Nesta seção, você encontrará todas as atualizações do SDK iOS

Mantenha seu SDK iOS sempre atualizado com a última versão disponível.

Versão 2.17.0 - 29/04/2025

pod 'unicocheck-ios', '2.17.10'

Atualização de build, a partir dessa versão o suporte mímino é Xcode16/iOS12.
- Generated by Apple Swift version 6.0 effective-5.10 (swiftlang-6.0.0.9.10 clang-1600.0.26.2)
Atualização do SDK e server de Liveness com interação.
Melhorias internas de produto. Essas melhorias não afetam diretamente a experiência do usuário final, mantendo a interface e funcionalidades externas inalteradas.