Add optional recipient access-code authentication

[jusso-dev]

Context

ScopeStack uses secure token links for recipient access. Mature e-signature tools offer additional signer authentication options such as access codes, SMS OTP, and ID verification. Access code authentication is the simplest high-value next step.

Goal

Add optional access-code authentication for recipient portal links.

Scope

• Sender can require an access code for a document or specific recipient.
• Sender can set or generate the code.
• Recipient must enter the code before viewing/signing the document.
• Access-code attempts are rate limited.
• Successful and failed attempts are audit logged without leaking the code.
• Codes are stored securely, hashed rather than plaintext.

UX Notes

• Add this to send settings and/or recipient settings.
• Email should not include the access code by default if that defeats the purpose.
• Client portal should show a simple verification screen before document content.
• Sender should be able to regenerate/reset a code.

Data/Architecture Notes

Potential fields:

• DocumentRecipient.accessCodeHash
• DocumentRecipient.accessCodeRequired
• DocumentRecipient.accessCodeAttempts
• Or a separate auth challenge model if preferred.

Security considerations:

• Hash access codes with existing token/crypto helpers or a password hash suitable for short secrets.
• Rate limit by token/IP/recipient.
• Do not include code in audit metadata.

Acceptance Criteria

• Sender can require access code for a recipient.
• Recipient cannot view document until the correct code is entered.
• Wrong attempts are blocked/rate limited after a threshold.
• Access code is stored hashed.
• Audit logs record challenge success/failure safely.
• Existing links without access-code requirement keep working.

Dependencies

• Correct/resend/reassign flow should preserve or reset access-code state deliberately.

Priority

P1. Strong trust improvement with relatively small scope compared with SMS/ID verification.