Skip to main content

4.2 Authentication Flow

This is the canonical authentication flow used throughout PTERI.

Every login, approval, or authorization is a variation of this sequence.

Step-by-step flow​

  1. The application requests authentication
  2. The backend generates a challenge
    • Random nonce
    • Short expiry
  3. The wallet receives the challenge
  4. The user approves via biometrics
  5. The wallet signs the challenge
  6. The signature is sent to the backend
  7. The backend verifies the signature
  8. The backend issues its own session or JWT

At no point does the backend:

  • Receive a secret
  • Store reusable credentials
  • Gain signing authority

Why this works​

  • Challenges are single-use
  • Signatures are non-replayable
  • Authority is proven, not assumed
  • Compromised servers cannot impersonate users

Authentication becomes a cryptographic event, not a credential exchange.