Package com.codename1.backend.security.webauthn
Passkeys: signing in with a credential an authenticator holds, as the Web Authentication specification defines it.
http.webAuthn(...) turns them on for a chain and serves the two
ceremonies -- registering a passkey for a user who is signed in, and
signing in with one. Behind those endpoints is
WebAuthnRelyingPartyOperations,
which makes the options a client starts a ceremony from and verifies what
the authenticator answered; an application that serves the ceremonies at
addresses of its own uses it directly.
What is kept is a
CredentialRecord for each
passkey, in a
UserCredentialRepository, and
for each user the handle authenticators know them by, in a
PublicKeyCredentialUserEntityRepository:
both in memory or in the server's database. Neither holds a secret.
The options and the answers travel as the specification's JSON forms,
byte strings in base64url, which is what a browser's
PublicKeyCredential.parseCreationOptionsFromJSON and toJSON(), and the
Codename One client's com.codename1.io.webauthn.WebAuthnClient, read and
write.
-
ClassDescriptionA credential's public key as an authenticator sends it -- a COSE_Key, RFC 9052 -- turned into what
Crypto.verify(String, byte[], byte[], byte[])takes: an algorithm name and a SubjectPublicKeyInfo.One registered passkey: what the server keeps of a credential, as the WebAuthn specification's credential record lists it.Builds aCredentialRecord.User handles kept in this process: gone when it stops, so that every passkey registered before then finds no user after.Credentials kept in this process: gone when it stops, and unknown to any other server.User handles kept in the server's database, in thecn1_webauthn_usertable ofSecuritySchema.Credentials kept in the server's database, in thecn1_webauthn_credentialtable ofSecuritySchema.What a client is given to make a passkey with: the relying party, the user, a challenge, and what kind of credential is wanted.What a client is given to sign in with a passkey: a challenge, the relying party, and -- when the user said who they are first -- which credentials may answer.The relying party of a passkey: the site a credential belongs to.A user as passkeys know them: the name they sign in with, and the user handle -- random bytes that stand for the account inside an authenticator, and that a sign-in without a user name hands back.Where each user's passkey handle is kept; seePublicKeyCredentialUserEntity.Where the passkeys users have registered are kept.Who signed in with a passkey.A passkey ceremony that was refused, with which check refused it.The two passkey ceremonies, as the relying party performs them: making the options a client starts from, and verifying what the authenticator answered.A verified sign-in.Told when a signature counter did not advance.