How it differs from OAuth

Trusted Accounts looks familiar if you have built an OAuth integration: a button, a short code, a confirmation on another device, a token. It is a different protocol with a different purpose. This page says what to expect, so you do not look for parts that are not there.

The direction is reversed

OAuth is delegated authorization. A user lets your application call another service on their behalf. Your application ends up holding a token that it uses against that service. Trusted Accounts is an attestation. A person vouches that they are the human behind an account on your platform. Your server ends up holding a signed statement that it verifies. The statement gives your platform no access to BotShield and no ability to act as the person.

	OAuth 2.0	Trusted Accounts
Purpose	Let a client act for a user	Let a person vouch for an account
Client registration	`client_id` and `client_secret`	None. You use your site key.
Scopes	Yes	None
Redirect and authorization code exchange	Yes	None
Token your server calls an API with	Access token	None
Refresh tokens	Yes	None
What your server receives	A token to use	A signed statement to verify
Identity of the user	Often included	Never included

Trusted Accounts is also not a sign-in. BotShield does not authenticate the user to your platform and does not issue a session. Your own sign-in comes first, and the offer appears after it.

What it borrows

The hand-off between your page and the person’s phone has the same shape as the OAuth device authorization flow: your page shows a short code and a QR code, the person opens a link on another device, and your page waits for the result. Only the shape is shared. No access token is issued at the end.

Part	What Trusted Accounts uses
The hand-off	A 6-character code and a QR code. The code lasts 5 minutes and works once. The widget waits for the result.
The confirmation	A passkey, which is a WebAuthn credential. The passkey belongs to BotShield’s relying party, so your page never sees it and cannot use it. The person’s biometric stays on their device.
The result	A JWT signed with ES256. You verify it against the public keys at `https://api.botshield.ai/.well-known/jwks.json`, or with `POST /sdk/verify-token`.

What your integration needs

You need	You do not need
A site key and an active Human Gate	A client ID or client secret
A stable ID for your signed-in user	A redirect URI
The widget on a page after your sign-in	A token exchange endpoint
A server check of the token	Token storage or refresh
A webhook handler for `account.unlinked`	Scope or consent screen configuration

Start with the Quickstart.

Get Started

BotShield Gate

Trusted Accounts

Agents Ask

Webhooks

Console

Server SDK

Integrations

Concepts

Changelog

The direction is reversed

What it borrows

What your integration needs

​The direction is reversed

​What it borrows

​What your integration needs

The direction is reversed

What it borrows

What your integration needs