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
Have the library handle challenge management (#35)
The examples so far have all used sessions to manage the active
challenges, but not all applications are stateful in this way - namely,
most APIs will not be session-based.
Instead, this creates a new `ChallengeManagerInterface` that handles
this for applications. For now there's a single implementation that's
still session-based, though (via #30 which I'm reworking) other
implementations will be provided (e.g. a cache pool).
The majority of the change here is updating examples and adding tests.
Note that this would be a BC break but since the library is still
pre-1.0 it's not a concern for practical purposes.
// Verification failed. Send an error to the user?
322
316
header('HTTP/1.1 403 Unauthorized');
@@ -440,6 +434,26 @@ Those wire formats are covered by semantic versioning and guaranteed to not have
440
434
441
435
Similarly, for data storage, the output of `Codecs\Credential::encode()` are also covered.
442
436
437
+
### Challenge management
438
+
439
+
Challenges are a [cryptographic nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) that ensure a login attempt works only once.
440
+
Their single-use nature is critical to the security of the WebAuthn protocol.
441
+
442
+
Your application SHOULD use one of the library-provided `ChallengeManagerInterface` implementations to ensure the correct behavior.
443
+
444
+
| Implementation | Usage |
445
+
| --- | --- |
446
+
|`SessionChallengeManager`| Manages challenges through native PHP [Sessions](https://www.php.net/manual/en/intro.session.php). |
447
+
448
+
If one of the provided options is not suitable, you MAY implement the interface yourself or manage challenges manually.
449
+
In the event you find this necessary, you SHOULD open an Issue and/or Pull Request for the library that indicates the shortcoming.
450
+
451
+
> [!WARNING]
452
+
> You MUST validate that the challenge was generated by your server recently and has not already been used.
453
+
> **Failing to do so will compromise the security of the protocol!**
454
+
> Implementations MUST NOT trust a client-provided value.
455
+
> The built-in `ChallengeManagerInterface` implementations will handle this for you.
456
+
443
457
Challenges generated by your server SHOULD expire after a short amount of time.
444
458
You MAY use the `ExpiringChallenge` class for convenience (e.g. `$challenge = ExpiringChallenge::withLifetime(60);`), which will throw an exception if the specified expiration window has been exceeded.
445
459
It is RECOMMENDED that your javascript code uses the `timeout` setting (denoted in milliseconds) and matches the server-side challenge expiration, give or take a few seconds.
0 commit comments