fix(auth): correct production WebAuthn RP configuration

[vitorhugo-dotnet]

Root cause

Production passkey authentication can inherit APP_WEBAUTHN_RP_ID=localhost from the previous defaults because the production application.yml used localhost as its fallback and .env.example did not declare any WebAuthn variables. The same config still allowed the old frontend origin https://jobapply-web.hugojava.dev.

For the current frontend at https://applywell.hugojava.dev, an RP ID such as localhost, jobapply-web.hugojava.dev, or jobapply-api.hugojava.dev is outside the calling origin's RP scope. The browser rejects navigator.credentials.get() before an assertion exists, which explains why /auth/passkey/login/options succeeds but /auth/passkey/login/verify is never called.

Changes

• production WebAuthn fallback is now explicit:
  • APP_WEBAUTHN_RP_ID=applywell.hugojava.dev
  • APP_WEBAUTHN_RP_NAME=ApplyWell
  • APP_WEBAUTHN_ORIGIN_1=https://applywell.hugojava.dev
• production CORS fallback/template now use https://applywell.hugojava.dev
• .env.example documents the production WebAuthn settings
• startup fails fast when a configured origin is not the RP ID itself or a subdomain of it
• integration coverage asserts that login options serialize publicKey.rpId
• configuration tests cover the valid ApplyWell RP ID and an invalid sibling API-host RP ID

Credential compatibility

WebAuthn credentials are scoped to the exact RP ID used at registration. This PR does not delete, migrate, or silently invalidate stored credentials. A passkey registered under a different RP ID must be registered again after deployment. Passkeys already registered with applywell.hugojava.dev remain in the same RP scope.

Deployment note

Repository defaults/templates are fixed, but an existing production .env/runtime variable has higher precedence. Deployment must not keep a stale APP_WEBAUTHN_RP_ID or APP_WEBAUTHN_ORIGIN_1 override.

Verification

Backend CI/CD run 35218179756 passed the test suite and packaged the JAR. Qodana run 35218179741 also passed.

Companion frontend diagnostics/tests: vitorhugo-dotnet/React-JobApplyTracker#114

[github-actions]

Qodana for JVM

3 new problems were found

Inspection name	Severity	Problems
Nullability and data flow problems	🔶 Warning	1
Mismatched query and update of 'StringBuilder'	🔶 Warning	1
Simplifiable conditional expression	🔶 Warning	1

View the detailed Qodana report

To be able to view the detailed Qodana report, you can either:

• Register at Qodana Cloud and configure the action
• Use GitHub Code Scanning with Qodana
• Host Qodana report at GitHub Pages
• Inspect and use qodana.sarif.json (see the Qodana SARIF format for details)

To get *.log files or any other Qodana artifacts, run the action with upload-result option set to true,
so that the action will upload the files as the job artifacts:

      - name: 'Qodana Scan'
        uses: JetBrains/qodana-action@v2025.3.2
        with:
          upload-result: true

Contact Qodana team

Contact us at qodana-support@jetbrains.com

• Or via our issue tracker: https://jb.gg/qodana-issue
• Or share your feedback: https://jb.gg/qodana-discussions