QAuth — Authentication

QAuth — Authentication

QAuth is the strong customer authentication (SCA) service of the QoinPay Enterprise suite. It provides a single, policy-driven point at which any product — payments, payroll approvals, admin actions, API access — can require a subject to prove identity to a defined assurance level before an operation proceeds. QAuth centralizes authenticators, challenge orchestration, and step-up logic so individual applications do not each reimplement it, and it runs entirely on your infrastructure.

Core concepts

Subject — the entity being authenticated: a customer, an employee, an operator, or a service principal. A subject owns one or more authenticators (an enrolled factor: password/PIN, TOTP, WebAuthn/FIDO2 security key or passkey, OTP over SMS/email, or an out-of-band push approval).

Authentication request (auth request) — the unit of work. A relying application creates an auth request describing who must authenticate, what they are authorizing, and the required assurance level. QAuth selects the appropriate authenticator(s), drives the challenge, and returns a signed assertion that the application verifies before acting.

Step-up — an already-authenticated session can be elevated for a higher-risk action (a large payout, a beneficiary change) by issuing a fresh auth request that demands a stronger or additional factor, without forcing a full re-login.

Capabilities

• Multi-factor — QAuth composes factors by policy: something known, something held, something inherent. Policies map an action or risk level to a required factor combination and assurance level.
• Dynamic linking — for payment authorization, the challenge is cryptographically bound to the amount and payee, so an approval cannot be replayed against a different transaction — a PSD2/SCA requirement satisfied out of the box.
• Step-up authentication — elevate an existing session in place; QAuth tracks the assurance level of the active authentication and only challenges when the requested level exceeds it.
• Verifiable assertions — successful authentication yields a short-lived, signed assertion carrying the subject, the level reached, the factors used, and the bound action context, so relying applications verify rather than trust.

Integration

Applications talk to QAuth over /api/v1. The pattern is: create an auth request, present any challenge to the subject, then confirm and receive the assertion.

POST /api/v1/auth/requests
Content-Type: application/json

{
  "subject": "sub_4471",
  "action": "payout.approve",
  "assurance": "aal2",
  "context": { "amount": "120000", "currency": "EUR", "payee": "acct_88" }
}

QAuth responds with the challenge to render, or — if the session already meets the required assurance — an immediate assertion:

{
  "request_id": "areq_0f31",
  "status": "challenge",
  "challenge": { "type": "webauthn", "options": { "...": "..." } }
}

QAuth can also drive out-of-band factors through signed webhooks — for example notifying a companion app of a pending push approval and receiving the result asynchronously.

Editions

• Standard — subjects and authenticators, password/PIN, TOTP, and email/SMS OTP, policy-mapped factor requirements, and signed assertions. Covers internal operator and admin authentication.
• Advanced — adds WebAuthn/FIDO2 (security keys and passkeys), out-of-band push approvals, dynamic transaction linking for payment SCA, step-up orchestration, and the full webhook event stream. Required for customer-facing PSD2-grade authentication.

The active edition is controlled by the license key and upgraded in place.

Sizing

QAuth is lightweight per request but latency-critical, since it sits in the user's interactive path:

• Up to ~100 auth/s: 2 vCPU / 4 GB, single node, authenticator and subject data in the primary MariaDB.
• 100–500 auth/s: 4 vCPU / 8 GB across two nodes behind the load balancer, with a shared session/challenge store for continuity.
• 500+ auth/s: scale nodes horizontally; the enrollment and assertion audit grows modestly (well under 1 KB per event). Cryptographic verification (WebAuthn) is CPU-cheap but benefits from modern instruction sets.

Provision for peak concurrency during business open and payroll approval windows rather than average load.

Licensing

QAuth is perpetually licensed per production instance, with the edition and enabled factor set encoded in the activation key. First-year SnS is included and covers factor-library updates (new WebAuthn attestation formats, evolving SCA regulatory mandates) and security fixes. See the licensing overview for the entitlement and activation lifecycle, including offline activation for air-gapped deployments.

Deployment security

• Authenticator secrets (TOTP seeds, OTP hashes, WebAuthn public keys) are sensitive — store seeds encrypted at rest and keep the assertion signing key in the platform HSM or key store, never in application config.
• Assertions are short-lived and signed; relying applications must verify the signature and the bound action context on every use, and reject expired or context-mismatched assertions.
• Rate-limit and lock out authenticator verification to resist brute force; QAuth records every attempt with its outcome for audit and anomaly detection.
• Keep the QAuth API on the internal tier behind an authenticated gateway. Pair with QShield to feed authentication anomalies into transaction fraud rules, and use QVault tokens for any instrument identifiers referenced in the action context.