> ## Documentation Index
> Fetch the complete documentation index at: https://docs.botshield.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How it differs from OAuth

> Trusted Accounts is not OAuth or a sign-in. It is a consent confirmation that ends in a signed statement your server verifies.

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](/trusted-accounts/quickstart).