Skip to main content

Authentication

The platform uses two key types: a secret key (sk_) that holds all permissions and lives on your server, and a session token (tok_) that's short-lived, scoped to one verification, and safe to ship to a mobile client.

Secret keys (dv_sk_…)​

You receive these from the dashboard at signup. Treat them like passwords. They authenticate every server-side request and have full tenant authority.

Use dv_sk_* from your backend code:

client, _ := ekyc.NewClient(ekyc.Config{
    APIKey: os.Getenv("EKYC_SECRET_KEY"),
})
curl -H "Authorization: Bearer dv_sk_test_..." https://api.drukverify.com/v1/ping

Rotate via the dashboard's API keys section. New sk_ is created alongside the old; update your servers, then revoke the old one.

Session tokens (dv_tok_…)​

Short-lived JWTs minted by POST /v1/sessions, signed by the gateway, scoped to one verification flow. Ship these to mobile clients.

Mint server-side:

session, err := client.Sessions.Create(ctx, ekyc.CreateSessionRequest{
    CustomerRef: "user_42",          // your user id, opaque to the platform
    TTL:         30 * time.Minute,   // gateway enforces an upper bound
})
// session.Token is a string starting with dv_tok_test_ or dv_tok_live_

The token is a JWT but the SDK treats it as opaque — only the prefix is parsed (to expose Mode). Don't try to decode it on the client.

Default TTL is 30 minutes. Tokens cannot be renewed; mint a fresh one when the previous expires.

Mobile flow (Flutter)​

Flutter never sees dv_sk_*. Instead, you supply a tokenProvider async callback that fetches a fresh dv_tok_* from your backend when needed:

final sdk = EkycSdk(EkycConfig(
  baseUrl: 'https://api.drukverify.com',
  tokenProvider: () async {
    final res = await Dio().get<Map<String, dynamic>>(
      'https://my-backend.example.com/session',
    );
    return res.data!['token'] as String;
  },
));

The SDK calls tokenProvider lazily on first request and reactively on 401 token_expired. Concurrent requests during refresh share the same tokenProvider future — only one upstream call fires.

Don'ts​

  • Don't embed dv_sk_* in mobile or browser code. Anyone who decompiles the binary or opens DevTools can extract it.
  • Don't reuse a tok_ across users. Mint one per verification.
  • Don't ship tok_ over email or chat. They're meant for request-scoped HTTPS only.