Login with IDfier
Add "Login with IDfier" to a web app. The customer scans a QR code or taps a button, approves in the IDfier app, and your server logs them in.
This is how IDfier's own products, IDfier Sign and Rezervoj, log people in. The Next.js example has the complete code.
Flow
Browser Your server IDfier API
│ "Log in" │ │
│ ────────────────────────▶│ POST /business/auth/request │
│ │ ─────────────────────────────▶│
│ │ ◀── referenceId, qrReferenceSecret, createdAt
│ ◀── the three values ────│ (and a cookie with referenceId)
│ │ │
│ shows the QR code, refreshed every 2 s │
│ (on a phone: a button that opens the IDfier app) │
│ │ │
│ polls your server ──────▶│ POST /business/auth/result │
│ │ ─────────────────────────────▶│
│ │ ◀── session.status │
│ ... customer approves in the IDfier app ... │
│ "approved" ─────────────▶│ reads the result once more, │
│ │ checks the cookie, logs in │
│ ◀── your session ────────│ │Steps
Start a session (server)
Your server calls POST /business/auth/request
and returns referenceId, qrReferenceSecret and createdAt to the browser.
Also set an httpOnly cookie with the referenceId. Only the browser that
started the login may finish it (step 4). Without this, anyone who learns a
referenceId, for example by seeing the QR code over someone's shoulder,
could finish that customer's login in their own browser.
Show the QR code (browser)
Build the QR payload from the three values and refresh it every ~2 seconds:
the payload contains the seconds since createdAt, and the app accepts only a
small time window. The format is in QR code payload.
On a phone, show a button instead that opens the app with the same payload:
https://www.idfier.com/auth?authData=<payload>.
Wait for approval (browser → your server → IDfier)
Poll your own server, which calls POST /business/auth/result.
Start at about every 2 seconds and back off to about 10:
session.status | Do |
|---|---|
pending | Not scanned yet; keep polling |
started | Scanned; stop refreshing the QR code and ask the customer to approve |
approved | Go to step 4 |
denied, error | Stop and tell the customer |
expiresAt passed | The session expired (after 5 minutes); offer a new one |
Or set a webhook when you create the session.
Log the customer in (server)
When the browser reports approved, don't take the customer's data from the
browser. On your server:
- Check that the
referenceIdmatches the cookie from step 1. - Call
POST /business/auth/resultand check thatdata.session.statusisapproved. - Use
data.userfrom that response: find or create the customer byuser.id, and issue your own session. - Delete the cookie, so the login can't be reused.
The result
{
"status": 100,
"data": {
"user": {
"id": "u_3f9a2c…",
"fullname": "Anna Lindqvist",
"email": "anna@example.com"
},
"session": {
"referenceId": "550e8400-e29b-41d4-a716-446655440000",
"status": "approved",
"method": "idfier",
"expiresAt": "2026-10-31T10:05:00.000Z",
"createdAt": "2026-10-31T10:00:00.000Z"
}
}
}userisnulluntil the session isapproved. It always hasid, plus the fields in your scopes that IDfier has for the customer.session.methodisidfier(the IDfier app) oreudi_wallet(an EU Digital Identity Wallet), once approved.- A session belongs to the first person who scans it: only they can approve or deny it, and only before it expires. Its scopes are fixed when it is created, so the result has exactly what the customer was shown and approved.
Recognise returning customers
user.id is stable for a customer within your business, and different for
every other business. Key the customer's account on it, not on email or name:
a customer may not share them, and they can change.
Checklist
-
clientSecretonly on the server - The QR code refreshes every 2 seconds; a phone gets a button instead
- The result is read on the server, never taken from the browser
- The
referenceIdis tied to the browser with an httpOnly cookie - Accounts are keyed on
user.id - Expired, denied and failed sessions offer a way to start again