Logins Without Stored Passwords: Adding Passkey Authentication to a Rork Max App

Registration: the server issues a challenge, the device returns a public key

Server first. Hand-rolling WebAuthn verification is how vulnerabilities happen, so I use the well-tested @simplewebauthn/server. This is the minimal shape — issuing registration options and verifying the attestation:

// server/passkey.ts — what this solves: issuing the registration challenge and verifying attestation
import {
  generateRegistrationOptions,
  verifyRegistrationResponse,
} from "@simplewebauthn/server";
 
const rpID = "example.com";          // RP ID = your domain; must match the app exactly
const origin = `https://${rpID}`;
 
export async function startRegistration(userId: string, userName: string) {
  const options = await generateRegistrationOptions({
    rpName: "Your App",
    rpID,
    userID: new TextEncoder().encode(userId),
    userName,
    attestationType: "none",
    authenticatorSelection: { residentKey: "required", userVerification: "required" },
  });
  await saveChallenge(userId, options.challenge); // store with an expiry
  return options;
}
 
export async function finishRegistration(userId: string, body: unknown) {
  const expectedChallenge = await loadChallenge(userId);
  const verification = await verifyRegistrationResponse({
    response: body as any,
    expectedChallenge,
    expectedOrigin: origin,
    expectedRPID: rpID,
  });
  if (!verification.verified || !verification.registrationInfo) {
    throw new Error("registration failed");
  }
  const { credential } = verification.registrationInfo;
  await savePublicKey(userId, credential.id, credential.publicKey, credential.counter);
  return { ok: true };
}

If you skip storing and matching the challenge, you are wide open to replay. Don't skip it.

On the client, the Swift side looks like this — added as an authentication manager alongside the code Rork Max generated:

// PasskeyRegistration.swift — what this solves: creating a credential from the server's challenge
import AuthenticationServices
 
final class PasskeyRegistrar: NSObject, ASAuthorizationControllerDelegate,
                              ASAuthorizationControllerPresentationContextProviding {
    private let rpID = "example.com"
 
    func register(challenge: Data, userID: Data, userName: String) {
        let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
            relyingPartyIdentifier: rpID)
        let request = provider.createCredentialRegistrationRequest(
            challenge: challenge, name: userName, userID: userID)
        let controller = ASAuthorizationController(authorizationRequests: [request])
        controller.delegate = self
        controller.presentationContextProvider = self
        controller.performRequests()
    }
 
    func authorizationController(controller: ASAuthorizationController,
                                 didCompleteWithAuthorization authorization: ASAuthorization) {
        guard let cred = authorization.credential
                as? ASAuthorizationPlatformPublicKeyCredentialRegistration else { return }
        // POST rawAttestationObject / rawClientDataJSON / credentialID to the server
        sendToServer(attestation: cred.rawAttestationObject,
                     clientData: cred.rawClientDataJSON,
                     credentialID: cred.credentialID)
    }
 
    func authorizationController(controller: ASAuthorizationController,
                                 didCompleteWithError error: Error) {
        // Error taxonomy below; 1004 almost always means a configuration mismatch
        print("passkey registration error: \(error)")
    }
 
    func presentationAnchor(for controller: ASAuthorizationController) -> ASPresentationAnchor {
        ASPresentationAnchor()
    }
}

The flow: fetch a challenge from startRegistration, call register, and forward the attestation your delegate receives to finishRegistration. The Face ID sheet appears and the whole thing finishes in about two seconds.

Sign-in: nothing counts until the server verifies the signature

Sign-in mirrors registration. The server issues an authentication challenge, the device signs it with the stored private key, and the server verifies against the saved public key.

// PasskeySignIn.swift — what this solves: obtaining a signature from a saved passkey
func signIn(challenge: Data) {
    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier: "example.com")
    let request = provider.createCredentialAssertionRequest(challenge: challenge)
    let controller = ASAuthorizationController(authorizationRequests: [request])
    controller.delegate = self
    controller.presentationContextProvider = self
    controller.performRequests()
}

Your delegate receives an ASAuthorizationPlatformPublicKeyCredentialAssertion; send its signature, rawClientDataJSON, rawAuthenticatorData, and credentialID to the server. There, verifyAuthenticationResponse takes the stored public key and counter, and only on success do you mint a session. Update the stored counter on every successful verification — forget that, and cloned-authenticator detection stops working.

One small UX note: tag your sign-in field with .textContentType(.username) and the QuickType bar will offer the passkey through AutoFill. In my app that path converted better than a dedicated button, so I made it the default.

The three places real-device testing stalled

First, error 1004. If you see a message to the effect of "Application with identifier is not associated with domain," the cause is almost certainly an RP ID/domain mismatch or an AASA file that couldn't be fetched. If you run your API on a subdomain, note that using api.example.com as the RP ID makes those credentials entirely separate from ones registered under example.com. Pick one RP ID and keep it identical across registration and sign-in.

Second, AASA caching. Apple fetches your AASA through its CDN and caches it, so fixing the file on your server doesn't reach devices immediately. During development, set the entitlement to webcredentials:example.com?mode=developer to bypass the CDN and fetch directly. You can inspect the state with swcutil on a Mac, but my working routine became: confirm everything passes in developer mode first, then let production mode propagate overnight.

Third, the simulator. Passkeys live in iCloud Keychain, so a simulator that isn't signed in to an Apple Account fails the registration sheet immediately. Rork Max's in-browser simulator is fine for walking the UI, but for the full credential round trip, a signed-in physical device is simply the fastest path — that was my conclusion.

For existing users, I recommend not forcing migration. Right after a successful password login, offer once: "Next time, sign in with Face ID." In that order, the user is already authenticated when they enter the registration flow, so no extra identity check is needed.

What the numbers looked like afterward

One month in, password-reset requests went from a dozen-plus per month to zero. Median time from screen load to completed sign-in dropped from about nine seconds to just over two. Roughly forty percent of users accepted the passkey prompt; the rest still use passwords. Running both paths costs a little extra code, but forcing registration to shorten the transition would, I believe, just trade it for churn you can't recover.

Where to start

The order that worked: get the AASA file serving correctly first, verify the registration flow on a device in developer mode, then harden sign-in and counter updates. Start by checking that your own /.well-known/apple-app-site-association returns with the right Content-Type.

If you'd rather not run an auth server at all, the setup in building unified web/mobile authentication with Rork and Better Auth is a solid alternative. I hope this saves you the half-day it cost me.