# 1:N Feature

The functionality **1:N** (or “One to Many”) is an essential component in facial recognition systems aimed at **identification of individuals**. Unlike the **1:1**approach, where a person's facial image is compared directly with another reference image (for example, identity validation via a selfie against a document), the **1:N** performs the comparison of a facial image against a **database containing multiple registered facial profiles**.

This functionality allows identifying a person **without them previously providing their identity**, based only on the image of their face. The system then searches, within the database, for the record most similar or compatible with that image.

## Container

The Faces Container is an organized set of facial representations (embeddings) stored in the database, used as the basis for identifying people. The Faces Container is registered per client, meaning the client can perform Face Registration in the Container and, later, the 1:N Match against the base of all faces registered in their profile.

## Liveness

In the implementation of Registration and 1:N Match, the client may choose to enable or disable Liveness as a parameter to perform face registrations or authentications.

* Liveness parameter enabled: If the submitted face does not pass the Liveness, the Facesign API returns with *Code 400 - Error*, not allowing the completion of the process with a negative Liveness result;
* Liveness parameter disabled: Registrations and Matches can be performed without positive Liveness validation; the face will go through the Registration or Match process regardless of the positive or negative Liveness result. Even with the Liveness parameter disabled, the Facesign API will return the Liveness result of the submitted face in the Payload.

The Liveness parameter enabled ensures greater security and authenticity both in Registration and in 1:N Match.

## Token

To generate an authentication token, send a JSON with the ID and password provided by Facesign to the endpoint: `/api/v1/auth/empresa/autenticar`.

JSON example:

```json
{
  "empresaId": "9EEC5EFD-XXXX-XXXX-8A10-1F689615D3BE",
  "password": "S6YW59TejZ9aJ0gXXXXXXXXXXXXXtnpOUCObZCL5r"
}
```

When sent, the payload will return the access token and the time to expire, like this:

```json
{
 "AccessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI5ZWVjNWVmZC0wYWY1LTQwZTItOGExMC0xZjY4OT...",
    "ExpiresIn": 86400,
    "UserToken": {
        "UsuarioId": "9eec5efd-XXXX-XXXX-XXXX-1f689615d3be",
        "EmpresaId": "9eec5efd-XXXX-XXXX-XXXX-1f689615d3be",
        "Nome": "Face1N_Dev",
        "Role": 1
    }
}
```

The access token will be inserted in the header as “Authorization” : “Bearer Token”

Example:

“Authorization” : “Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 .eyJzdWIiOiI5ZWVjNWVmZC0wYWY1LTQwZTItOGExMC0xZjY4OT...”

For testing via Postman, just go to the “Authorization” tab in the Collection, select the “Bearer Token” option in the authentication type (*Auth* *Type*) and paste the generated token.