Implement recovery key support for user storage providers

[ShashankFC]

User description

Test 9

Summary by CodeRabbit

New Features

• Recovery Codes Authentication: Added support for recovery codes as an authentication credential type, enabling users to set up and use recovery codes during login as an additional authentication method.
• Recovery Code Verification: Implemented recovery code validation and verification within the authentication flow.
• Backwards Compatibility: Extended legacy storage systems to support recovery codes credentials alongside existing authentication methods.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

---

Replicated from ai-code-review-evaluation/keycloak-coderabbit#9

---

CodeAnt-AI Description

Add recovery code support across user storage and login flows

What Changed

• Users can create and store recovery authentication codes that are saved either in external (federated) user storage or in Keycloak's local storage and then used to sign in.
• The browser login flow accepts recovery codes and consumes stored recovery-code credentials; if all codes are used the stored credential is removed.
• Backwards-compatibility provider and tests updated so legacy/federated user-storage implementations can expose recovery-code credentials and validation; end-to-end tests cover setup and login with recovery codes.
• Admin and required-action flows persist recovery codes and honor the "logout other sessions" option during setup.

Impact

✅ Users can sign in with recovery codes stored in external user storage
✅ Backwards-compatible recovery-code setup for legacy user-storage providers
✅ Tests validate recovery-code setup and login flows

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[ShashankFC]

@CodeAnt-AI: review

[codeant-ai]

CodeAnt AI is running the review.

[codeant-ai]

Nitpicks 🔍

🔒 No security issues identified

⚡ Recommended areas for review Plaintext Recovery Codes The new code serializes raw generated recovery codes to JSON and writes that JSON into a UserCredentialModel value when creating the credential in user storage. This stores the actual recovery codes (sensitive secrets) in plaintext in the user storage path, while the local (Keycloak DB) path uses the credential model (which is expected to hold hashed codes). This creates an inconsistent storage format and exposes sensitive secrets. Possible Bug The constructor calls credentialModelOpt.get() without checking whether the Optional is present. If no recovery-codes credential exists for the user this will throw NoSuchElementException at runtime. The flow should handle the absent credential gracefully (e.g. throw an informative exception, return a safe default, or avoid constructing the bean). Credential lookup ordering & compatibility The new getCredential helper prefers federated (user-storage) credentials over local stored credentials. Make sure all callers and the rest of the flow are compatible with federated credentials semantics (format, id, stored data) — otherwise behaviour may differ depending on where the credential lives. NullPointer / Robustness The new getCredentials(...) method assumes myUser is non-null and directly accesses myUser.recoveryCodes. If getMyUser(user) returns null this will cause an NPE. Also JSON deserialization uses raw List.class (loses type information); consider using a typed TypeReference and validate the deserialized content.

[codeant-ai]

CodeAnt AI finished running the review.