How auth-svc Works with duo-server

Why duo-server Needs Auth-svc

Without an authorization layer, any party holding a valid keyshare could trigger MPC operations on duo-server. Blocking requests at the network level — putting a proxy in front of duo-server — doesn't work cleanly: the proxy must relay and fully understand the MPC protocol traffic.

Auth-svc solves this with hooks: duo-server calls auth-svc server-to-server over a local HTTP channel before executing each operation. auth-svc owns the device→user and key→user mappings and returns "ok" or "reject". The mobile app only ever talks to duo-server for MPC.

The Three Hooks

Hook 1: DKG Setup Validation

Called before keygen begins. The phone signs its setup message with its device secret key (held in the Secure Enclave). Duo-server verifies the signature, then delegates the authorization decision to auth-svc, which checks whether the device is registered.

Request (duo-server → auth-svc):

{
  "token": "<hex-encoded device verifying key>",
  "setup": {
    "<tagname>": ["<hex value>", "..."],
    "user_tag_1": ["<hex value>", "..."]
  },
  "instance": "<hex-encoded 32-byte instance ID>"
}

token is the device verifying key (device_vk). auth-svc looks it up in the DEVICES table to confirm it maps to a registered user.

Response: "ok" or "reject" (JSON string).

Hook 2: Key-ID Notification

Sent by duo-server once keygen completes. auth-svc uses this to record the new key and associate it with the device (and therefore the user) that initiated keygen.

{
  "token": "<hex-encoded device verifying key>",
  "key_id": "<hex-encoded key ID>",
  "instance": "<hex-encoded 32-byte instance ID>"
}

This creates the key_id → user_id mapping that auth-svc needs to authorize signing later.

Hook 3: DSG Setup Validation

Called before each signing operation. In addition to checking device registration, auth-svc verifies that the requesting device owns the key being signed with.

{
  "token": "<hex-encoded device verifying key>",
  "setup": {
    "key_id": ["<hex-encoded key ID>"],
    "message": ["<message to be signed>"],
    "<tagname>": ["<hex value>", "..."]
  },
  "instance": "<hex-encoded 32-byte instance ID>",
  "extra": "<extra user-defined bytes embedded in keyshare>"
}

auth-svc resolves token → user_id and setup.key_id → user_id.

Response: "ok" or "reject".

Registration & Authorization Flow

Device registration (via the auth-svc REST API) must happen before any MPC operation can be authorized.