Agent Sign-In

An agent can complete an interactive sign-in built for a human, without impersonating an employee or sharing a login. Which credential it uses depends on what the target application expects. That might be a username and password held as schema attributes, an emailed or texted one-time code or magic link, or a passkey the agent registers and uses itself.

Allow the agent type on the application

An application accepts an agent as a sign-in subject only when agent sign-in is enabled for it. Every application rejects agents until you turn it on, even when the agent presents the right credentials.

Console

1. Go to Applications and open the application the agent signs in to.
2. On the Access tab, click on Enable Agent Sign-In.
3. Save from the unsaved-changes bar.

API

The update replaces the application in full, so fetch the current one first:

curl -X GET https://localhost:8090/applications/<application-id> \
  -H 'Authorization: Bearer <access-token>'

Add allowedAgentTypes alongside the existing fields, then send the merged application back:

curl -X PUT https://localhost:8090/applications/<application-id> \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <access-token>' \
  -d '{
    "name": "Vendor Portal",
    "allowedUserTypes": ["customer"],
    "allowedAgentTypes": ["default"]
  }'

See the Applications API Reference.

This setting gates sign-in only. Roles and scopes still govern what the agent can do once it is signed in.

Sign the agent in

An agent can have multiple methods of authentication to sign in to an application. Choose the method that fits your use case.

Add the attributes to the agent schema

ThunderID agents carry one schema per organization unit, shared by every agent in it. See Agent Schema for the full attribute model.

Console

1. On the Agents list, click Schema.
2. Add a username attribute: set Type to String, and turn on Required and Unique.
3. Add a password attribute: set Type to String, and turn on Required and Credential.
4. Save from the unsaved-changes bar.

API

The update replaces the schema in full, so fetch the current one first:

curl -X GET https://localhost:8090/agent-types/<agent-type-id> \
  -H 'Authorization: Bearer <access-token>'

Add username and password alongside the existing attributes, then send the merged schema back:

curl -X PUT https://localhost:8090/agent-types/<agent-type-id> \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <access-token>' \
  -d '{
    "name": "default",
    "ouId": "<organization-unit-id>",
    "schema": {
      "username": { "type": "string", "required": true, "unique": true },
      "password": { "type": "string", "required": true, "credential": true }
    }
  }'

See the Agent Types API Reference.

Marking password as a credential means ThunderID hashes it on write and never returns it in a read response, the same guarantee that applies to any credential attribute.

Create an agent

Create the agent the same way as any agent, filling in the username and password attributes with the values the application expects. See Create an agent.

The password cannot be read back

Once created, ThunderID can verify the password but cannot return it, the same as any credential attribute. Provision the same value to the agent's runtime through your own secrets manager or deployment pipeline, since creating the agent already required it.

Authenticate to the application

The agent submits the username and password from its schema to the application's own sign-in flow, exactly as a person would.

See Authenticate the Agent for this pattern applied in a full scenario.