How it works · details
From tapping a card to signing in
An employee taps their card and gets on with work. Inside ChipLogin, several steps verify the card, prepare the right account and securely deliver its credentials where they are needed.
First approval. Then mutual authentication.
During registration, an administrator compares the workstation key fingerprints. The approved workstation and its then authenticate each other on every connection.
On the workstation
Workstation key fingerprint
and approves
On the Auth server
Fingerprint of the same key
The administrator also compares and confirms the Auth server's fingerprint on the workstation. The illustrated fingerprints here explain the principle; they are not application screenshots.
Approved workstation
Proves its identity to the server.
Company Auth
Proves its identity to the workstation.
The workstation knows its server. The server accepts approved devices.
cryptographic authentication. The public card number alone is not enough.
Workstation ↔ company Auth: with . Auth protects stored passwords with . Credentials are transferred in an package intended for the Windows or application component.
Authentication is performed by the workstation. Windows protects stored sensitive data under the SYSTEM service account. Transfer to the uses ECIES.
Licensing, diagnostics, and card preparation. The cloud does not mediate routine authentication on the company Auth server.
The card proves it has the right key
The reader connects to the card. Its identifier helps find the relevant record, but reading the number alone is not enough to sign in. A DESFire card then undergoes cryptographic authentication: must prove knowledge of the right key. ChipLogin thus verifies the card issued to the employee and checks its link to an authorised identity.
The employee does not manage this exchange between card and system. There is no to select or code to type. The action remains simple; authentication happens in the background. The card provides access, while Windows credentials come from ChipLogin's protected store.
Local and Auth: two deployment options
In Local mode, a service on the individual computer handles card authentication and stored credentials. This part of sign-in needs neither a network nor an Auth server. Card issuance and assignment are managed on that workstation, which operates independently with its own directory.
In Auth mode, the workstation contacts the company authentication server. It verifies the card and links it to a centrally managed identity and account for the requested destination. The server runs in your infrastructure and does not need ChipLogin Cloud for routine sign-in. The workstation does, however, need a working connection to the company Auth server.
You choose the mode during deployment. A network workstation does not automatically switch to a local database if Auth fails. Local is a standalone computer option, not an automatic fallback for the central system.
Device approval establishes trust
The workstation and Auth server each have their own cryptographic identity. When connecting a new workstation, an administrator compares its visual fingerprint on the computer with the one in the server's pending-device list. Only then is the workstation approved. On the workstation, the administrator also checks the server fingerprint against the one shown in Auth management and saves it as trusted.
The visual fingerprint is derived from the public key and helps a person compare the two displays. It supports the initial pairing of devices. In routine operation, nothing is compared by eye: the workstation and server prove their identities using keys and certificates when they connect.
Communication uses encrypted HTTPS with mutual authentication. The server checks that the workstation is an approved device, and the workstation checks the stored fingerprint of the server's key. Successful card authentication is therefore linked to trust in the specific device and server.
Protected storage and transfer
On the Auth server, passwords and card keys are stored using AES-256-GCM encryption. The encryption key is separate from the database, and the system service and server administrators have access to the data folder. In Local mode, Windows protects stored data through DPAPI in the system service context. Protection is therefore tied to that workstation's environment.
After successful authentication, the Auth server prepares the account and password and encrypts them for a specific recipient. It uses ECIES with the curve, key derivation and AES-256-GCM. The workstation service forwards this network package while it remains encrypted. Only the sign-in component opens it. In Local mode, the local service first decrypts the data and then repackages it for the recipient.
The final step is sign-in
ChipLogin's sign-in component, called the Credential Provider, passes the credentials to Windows. Windows verifies them according to the account's rules. For a supported application sign-in form, the Agent performs the equivalent role by receiving and filling in the credentials. In both cases, convenient card use connects to an account the employee already uses.
The authentication event is recorded in the . Administrators can trace the workstation, identity and authentication result. The next section explains these records and how ChipLogin helps with lost cards or changed passwords.