You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+13-17Lines changed: 13 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,14 +2,12 @@
2
2
3
3
This project demonstrates a secure face authentication flow using Incode's WebSDK with proper validation and session management. The application implements:
4
4
5
-
-**User hint input** for authentication (customerId, email, or phone)
5
+
-**User hint input** for authentication (identityId)
6
6
-**Face authentication** using Incode's renderAuthFace SDK
7
-
-**Session management** with IndexedDB to prevent reuse
8
7
-**Backend validation** to verify authentication integrity by:
9
8
- Matching candidate from the SDK with identityId from the score API
10
-
- Validating overall authentication status
11
-
- Preventing token tampering and session replay attacks
12
-
- Marking sessions as used to prevent reuse
9
+
- Validating overall status to be OK
10
+
- Closing sessions to prevent modification
13
11
14
12
This example showcases best practices for implementing face authentication in a web application with proper security measures.
15
13
@@ -61,7 +59,7 @@ sequenceDiagram
61
59
62
60
# Requirements
63
61
64
-
Vite requires Node.js version 14.18+, 16+. some templates require a higher Node.js version to work, please upgrade if your package manager warns about it.
62
+
Vite 8 requires **Node.js ^20.19.0 || >=22.12.0**. Run `node -v`to verify before installing.
65
63
66
64
# Install
67
65
@@ -83,24 +81,22 @@ VITE_FAKE_BACKEND_FLOW_ID=
83
81
84
82
Remember the Flow holds the backend counter part of the process, some configurations there might affect the behavior of the WebSDK here.
85
83
86
-
# Fake Backend Server
84
+
# Example Backend
87
85
88
86
Starting and finishing the session must be done in the backend. To simplify development, this
89
-
sample includes a `fake_backend.js` file that handles backend operations in the frontend.
87
+
sample includes an `example_backend.js` file that handles backend operations in the frontend.
90
88
91
89
**Important:** Replace this with a proper backend for production. The API key should NEVER be exposed in the frontend.
92
90
93
91
## Key Backend Functions
94
92
95
-
-`fakeBackendStart()` - Creates a new session and stores it in IndexedDB with `used: false`
96
-
-`fakeBackendFinish()` - Retrieves the finish status from the API
97
-
-`fakeBackendGetScore()` - Gets the authentication score from the API
98
-
-`fakeBackendValidateAuthentication()` - Validates the authentication by:
99
-
- Checking if the session exists and hasn't been used
100
-
- Verifying the token matches the stored token
101
-
- Comparing candidate with identityId from the score
102
-
- Ensuring overall status is "OK"
103
-
- Marking the session as used to prevent reuse
93
+
-`start(identityId)` - Calls Incode's `/omni/start` API to create a new session and returns the session `token`
94
+
-`getResults(token, candidate)` - Verifies the authentication by:
95
+
- Finishing the session via `/omni/finish-status` to trigger score calculation
96
+
- Closing the session via `/omni/session/status/set?action=Closed` to freeze the score
97
+
- Retrieving the score via `/omni/get/score`
98
+
- Comparing `candidate` (from the WebSDK) with `identityId` from the score to prevent tampering
0 commit comments