Authentication

Full reference for PIN verification, session management, biometric workflows, and API key authentication.

All features supported

Every authentication capability listed below is implemented and working. Your portal never receives the raw PIN — PIN entry occurs only inside SecureSign Mobile App or Desktop Software.

Overview

SecureSign uses a two-layer authentication model:

  1. Portal layer — API key (ss_live_ / ss_test_) and domain whitelist validate your server-to-server calls.
  2. Token layer — DSC token PIN (and optional device biometric on mobile) validates the end user before private-key operations.

Private keys never leave the token. PINs are never transmitted to your portal or the SecureSign REST API.

Platform Support

FeatureMobile AppDesktop SoftwareREST API
PIN VerificationSupportedSupported— (product UI only)
PIN ChangeProduct settingsProduct settings
PIN Retry CounterShown in UIShown in UI
PIN Status CheckSupportedSupported
Unlock Token (PUK)Vendor-dependentVendor-dependent
Biometric + PINSupported
Session AuthenticationSupportedSupportedPOST /auth/session
Auto LogoutIdle timeoutIdle timeoutSession expiry
Multi-Factor AuthAPI key + PINAPI key + PINPOST /auth/validate

PIN Workflow

When a sign request requires token access, SecureSign prompts the user for PIN inside the product:

  1. Portal initiates sign via securesign://sign deep link or REST API orchestration.
  2. SecureSign detects token and shows PIN entry screen.
  3. On success, signing proceeds; PIN session may be cached for batch operations.
  4. On failure, retry counter decrements; after max retries token is blocked.

PIN never leaves the product

Do not build PIN input fields in your portal. Collecting DSC PINs in a web form violates security best practice and is not supported.

PIN status values

StatusDescription
ACTIVEPIN accepted; signing allowed
INVALIDWrong PIN; retries remaining shown
BLOCKEDMax retries exceeded; PUK unlock required
SESSION_ACTIVEPIN verified; session cached for batch signing

Session & MFA

Session authentication — after first successful PIN entry, subsequent signs in the same session skip PIN re-entry until idle timeout (default 15 minutes, configurable in product settings).

Biometric + PIN (Mobile App) — optional device fingerprint/face unlock before PIN screen for faster repeat signing.

Multi-factor — every signing flow requires both a valid API key (portal identity) and token PIN (user identity).

API Authentication

Server-side calls use Bearer token or header:

Authorization: Bearer ss_live_abc123xyz
// or
X-SecureSign-Api-Key: ss_live_abc123xyz

Validate key and domain before initiating signing:

EndpointPurpose
POST /auth/validateVerify API key + whitelisted origin
POST /auth/sessionCreate server-side signing session for multi-step workflows

Examples

curl -X POST https://api.securesign.toolsbots.com/v1/auth/validate \
  -H 'Authorization: Bearer ss_live_abc123xyz' \
  -H 'Content-Type: application/json' \
  -d '{"origin":"https://portal.example.gov.in","platform":"web"}'

Response

POST /auth/validate

{"success":true,"tenantId":"org_9f2a","allowed":true,"rateLimit":{"rpm":120}}

POST /auth/session

{"sessionId":"sess_7x9y","expiresAt":"2026-06-22T11:00:00Z","deepLink":"securesign://sign?requestId=a1b2c3d4&..."}

Errors

CodeCauseResolution
SS_PIN_INVALIDIncorrect PINUser retries; show remaining attempts
SS_PIN_BLOCKEDToken blocked after max retriesPUK unlock via product settings or CA
SS_API_KEY_INVALIDInvalid or revoked API keyCheck Admin Console key status
SS_DOMAIN_NOT_ALLOWEDOrigin not whitelistedAdd domain in Admin Console
SS_SESSION_EXPIREDSigning session timed outRe-initiate sign flow
SS_SIGN_CANCELLEDUser cancelled PIN entryAllow user to retry

See also Authentication API and API Keys.