Merge pull request #71 from MasterKale/feat/port-example-to-ts

feat/port-example-to-ts

1 files changed, 39 insertions, 0 deletions

diff --git a/example/example-server.d.ts b/example/example-server.d.ts
new file mode 100644
index 0000000..6d1dfb8
--- /dev/null
+++ b/example/example-server.d.ts
@@ -0,0 +1,39 @@
+import type { AuthenticatorDevice } from '@simplewebauthn/typescript-types';
+
+/**
+ * You'll need a database to store a few things:
+ *
+ * 1. Users
+ *
+ * You'll need to be able to associate attestation and assertions challenges, and authenticators to
+ * a specific user. See `LoggedInUser` below for an idea of the minimum amount of info you'll need to
+ * track for a specific user during these flows.
+ *
+ * 2. Challenges
+ *
+ * The totally-random-unique-every-time values you pass into every execution of
+ * `generateAttestationOptions()` or `generateAssertionOptions()` MUST be stored until
+ * `verifyAttestationResponse()` or `verifyAssertionResponse()` (respectively) is called to verify
+ * that the response contains the signed challenge.
+ *
+ * These values only need to be persisted for `timeout` number of milliseconds (see the `generate`
+ * methods and their optional `timeout` parameter)
+ *
+ * 3. Authenticator Devices
+ *
+ * After an attestation, you'll need to store three things about the authenticator:
+ *
+ * - Base64-encoded "Credential ID" (varchar)
+ * - Base64-encoded "Public Key" (varchar)
+ * - Counter (int)
+ *
+ * Each authenticator must also be associated to a user so that you can generate a list of
+ * authenticator credential IDs to pass into `generateAssertionOptions()`, from which one is
+ * expected to generate an assertion response.
+ */
+interface LoggedInUser {
+  id: string;
+  username: string;
+  devices: AuthenticatorDevice[];
+  currentChallenge?: string;
+}