Go to developer

Security

Partner 2FA is only as strong as your secret handling, consume boundary, and session design.

On this page

Client secret storage

Auth header format: Authorization: Bearer {clientId}:{clientSecret} — see Credentials.

Browser vs server

  • Server: createKeyraPartner2FA / Java Partner client, status, enroll, challenge, poll, consume, recovery, disable.
  • Browser: render QR/images and UX only from data your backend returns.
  • Browser Partner proxy patterns in @keyra/web-sdk still require a trusted backend proxy — secrets stay server-side.

externalUserId

  • Must be stable and unique per user within your project.
  • Prefer opaque IDs over email/phone to reduce PII in KEYRA and your logs.
  • Max length 128 characters.

Verification tokens

  • Short TTL (~60 seconds after approval).
  • Returned once on approved poll — prefer wait helpers.
  • Challenge expiry (~120 seconds) limits approval window.

Application sessions

After consumed: true, create sessions with your normal secure practices (HTTPS-only cookies, rotation, CSRF where applicable). Do not skip consume and trust a browser-only “approved” signal.

Recovery codes

  • Show once; require re-auth in your app before display.
  • Regeneration invalidates previous unused codes.
  • Restrict which roles can call recovery/disable APIs.

Logging & HTTPS

  • Always use HTTPS to https://auth.keyra.ie.
  • Log challengeId / enrollmentId for support — not secrets or verification tokens.
  • Avoid putting raw error bodies containing tokens in client-visible responses.