WebAuthn: Add user id to PublicKeyCredentialsCreateOptions, Authenticator and WebAuthnCredentials (#580, #581) #582
Conversation
| @@ -60,6 +60,10 @@ public static void fromJson(Iterable<java.util.Map.Entry<String, Object>> json, | |||
| obj.setUserName((String)member.getValue()); | |||
| } | |||
| break; | |||
| case "userId": | |||
There was a problem hiding this comment.
Realized I modified these by hand... how do I run the code generator?
mnylen
force-pushed
the
add-user-id-to-authenticator
branch
from
7a8a277
to
acae48b
Compare
| @@ -20,17 +21,25 @@ public void clear() { | |||
| } | |||
|
|
|||
| public Future<List<Authenticator>> fetch(Authenticator query) { | |||
| if (query.getUserName() == null && query.getCredID() == null && query.getUserId() == null) { | |||
There was a problem hiding this comment.
I thought it was better to explicitly fail the query in the tests if all conditions were null (which should not happen with proper usage / implementation)
| @@ -43,27 +46,61 @@ public void testFIDORegister(TestContext should) { | |||
| .authenticatorFetcher(database::fetch) | |||
| .authenticatorUpdater(database::store); | |||
|
|
|||
| database.add( | |||
There was a problem hiding this comment.
Instead of starting the register test with the authenticator already in database, I changed the test to test that the authenticator was persisted in the database after registration.
| } | ||
|
|
||
| @Test(timeout = 1000) | ||
| public void testFIDOLoginWhenNoAuthenticatorsFoundByCredID(TestContext should) { |
There was a problem hiding this comment.
Just a little sanity check test to make sure that authenticate() fails if no authenticators are found by the credential id.
|
Seemed to have resolved itself. |
…ator and WebAuthnCredentials (eclipse-vertx#580, eclipse-vertx#581)
mnylen
force-pushed
the
add-user-id-to-authenticator
branch
from
acae48b
to
b96e8dd
Compare
* Give some guidance on where to store the challenge * Note that it's important to scope the challenge to either login / registration, or otherwise (as `authenticate` is the entrypoint for both operations) one could use a registration response to log in. * Challenge should have some kind of TTL and preferably be invalidated after use to prevent replay attacks.
|
Updated the documentation also. Added a mention that it's up to the caller of Have to say, I don't super love that the To tackle this somehow, mentioned in the documentation that, when storing the challenge, implementer should scope the stored challenge to either login or registration, so it can only be used in that context. But maybe this is something we should tackle at the API level to prevent possibility for the user to make such mistake. |
Motivation:
Fixes #580 and #581