Problem
An app built on Seamless Auth has no password to hand to a store reviewer. Apple's App Review (guideline 2.1) and Google's app access declaration both ask for a way to sign in to anything behind a login. With email codes and sign-in links, a demo account's code lands in an inbox the reviewer does not have; with passkeys, the credential lives on a device the reviewer does not have.
Today the only honest answer is "registration is open and free, sign up with your own address", which Apple accepts in principle and rejects in practice often enough that adopters will ask for something better. The first adopter to hit this is RoxTarget (fells-code/roxtarget-mobile).
Options
- Documented guidance only. A docs page on what to write in App Review Information for a passwordless app. Zero API change, some rejection risk per submission.
- Review identities with a fixed code. A system config list of identifiers (
review_identities) for which the OTP flow accepts a configured code instead of a generated one. Constraints if this is built: explicit allowlist, never a default; the code is hashed at rest like every other OTP; the identity is a normal user with no roles; every use is an auth event flagged as a review sign-in; rate limited like any other OTP; and the admin dashboard shows the list so nobody forgets it is on. Magic links and passkeys stay unaffected.
- Admin-issued sign-in link. An admin endpoint that mints a single-use link for a chosen identity that the reviewer opens in the app. Simpler surface than a fixed code, but the reviewer has to receive the link out of band and it expires, which does not fit a review queue that may take days.
Recommendation: 1 now, so the docs say something before the first adopter submits, and 2 as the feature, since it is the pattern reviewers already understand (a demo account with a known code).
Filed as a feature; not a security fix. Related to the mobile work tracked in fells-code/seamless-templates#40.
Problem
An app built on Seamless Auth has no password to hand to a store reviewer. Apple's App Review (guideline 2.1) and Google's app access declaration both ask for a way to sign in to anything behind a login. With email codes and sign-in links, a demo account's code lands in an inbox the reviewer does not have; with passkeys, the credential lives on a device the reviewer does not have.
Today the only honest answer is "registration is open and free, sign up with your own address", which Apple accepts in principle and rejects in practice often enough that adopters will ask for something better. The first adopter to hit this is RoxTarget (fells-code/roxtarget-mobile).
Options
review_identities) for which the OTP flow accepts a configured code instead of a generated one. Constraints if this is built: explicit allowlist, never a default; the code is hashed at rest like every other OTP; the identity is a normal user with no roles; every use is an auth event flagged as a review sign-in; rate limited like any other OTP; and the admin dashboard shows the list so nobody forgets it is on. Magic links and passkeys stay unaffected.Recommendation: 1 now, so the docs say something before the first adopter submits, and 2 as the feature, since it is the pattern reviewers already understand (a demo account with a known code).
Filed as a feature; not a security fix. Related to the mobile work tracked in fells-code/seamless-templates#40.