Skip to content

feat: v0.20 routes and recovery sessions in every adapter #232

Closed

Description

@Bccorb

What the v0.20 API (epic fells-code/seamless-auth-api#386) needs from the adapters. Contract: @seamless-auth/types 0.30.0 (fells-code/seamless-auth-types#108).

Recovery sessions (fells-code/seamless-auth-api#491)

  • An access token may carry recovery: true. requireAuth (and the Next.js / Go / Python / Rust equivalents) refuses it by default with 403 enrollment_required, with an option to allow it, so an app does not treat a half-recovered account as signed in.
  • After passkey registration or TOTP enrollment from a recovery session, the API lifts the restriction on the session; the adapter should refresh so the cookie's access token drops the claim.

Routes

Manifest-driven (public / pre-auth; picked up from /.well-known/seamless-adapter.json, verify they work):

Access routes needing explicit passthroughs (no catch-all proxy; see the seven-file checklist):

Pass through unchanged

Related: #231 (placeholder secrets), #225-#230 (hardening). Ship in the one v0.20 adapter release, before API 0.20.0.

Activity

  1. added this to the v0.20 milestone on Oct 22, 2026
  2. added
    P1Next
    safeServes the safe promise: no lockout, no lock-in, honest
    v0.20Targets the v0.20 release
    on Oct 22, 2026
  3. Bccorb commented on Oct 24, 2026

    @Bccorb
    ContributorAuthor

    Also from fells-code/seamless-auth-api#490: DELETE /users/delete (a user deleting their own account) now needs a fresh step-up and answers 403 step_up_required with the step-up status fields otherwise. Pass it through unchanged; the React SDK's account deletion needs to step up first (and an account with no passkey or TOTP cannot delete itself).

  4. Bccorb commented on Oct 25, 2026

    @Bccorb
    ContributorAuthor

    From fells-code/seamless-auth-api#498: POST /recovery/verify can now answer 503 with recovery_notice_failed (the request is voided when the owner could not be notified). When the /recovery/* passthroughs land, pass that status and body through unchanged, and don't send x-seamless-auth-delivery-mode: external on /recovery/verify until fells-code/seamless-auth-api#499 adds a delivery kind for the notice.

  5. Bccorb commented on Oct 25, 2026

    @Bccorb
    ContributorAuthor

    Contract from fells-code/seamless-auth-api#500 (types @seamless-auth/types 0.31.0):

    • Handle the new delivery kinds account_notice_email (to, subject, text, notice, cancelUrl?) and account_notice_sms (to, text, notice, cancelUrl?). cancelUrl carries a credential: send it only to to, never log it.
    • On manifest routes marked notices: true (today POST /recovery/verify), send external delivery plus x-seamless-auth-delivery-kinds: account_notice_email,account_notice_sms, deliver every item in the response's deliveries array, and strip it before answering the client. Do not send that header unless every listed kind is actually delivered, because the API counts a returned notice as the owner being told.
    • otp_email / otp_sms may carry purpose: 'account_recovery': word that message as a recovery warning.
    • New access routes GET /recovery/requests and DELETE /recovery/requests/:id need no adapter-specific code where the manifest catch-all is used.
    • POST /recovery/verify can answer 503 recovery_notice_failed; pass it through.
  6. Bccorb commented on Oct 29, 2026

    @Bccorb
    ContributorAuthor

    Done: the recovery-session refusal and account notices shipped in #233, the hardening in #234, and the bundled manifest carries every v0.20 route (policy, recovery codes, recovery). Released in core/express 0.22.0, fastify 0.13.0, nextjs 0.6.0. The refresh-after-enrollment parity is #235, now in v0.21.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1NextsafeServes the safe promise: no lockout, no lock-in, honestv0.20Targets the v0.20 release

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions