# Human users (passkey)

:::note
Most integrations should use a Machine User or Agent. This page is here for context to explain how the system works. If you are writing code against the API, create a Machine User or Agent instead and follow the [Machine Users and Agents](/develop/authentication/machine-users) guide.
:::

## Session authentication

Human users sign in through your cloud identity provider (Google). A successful sign-in produces a JWT, which is sent as the `Authorization` header on API calls:

```
Authorization: Bearer <jwt-from-cloud-idp>
```

The JWT is a standard bearer token issued by the identity provider. The vault verifies it against your configured provider.

## Passkey assertion for state-changing operations

Read-only calls (such as [GET /v1/whoami](/api-reference#tag/whoami) or `GET /v1/admin-policies`) need only the `Authorization` header.

State-changing operations require a passkey assertion in `x-request-assertion`. This is a WebAuthn assertion response: a JSON object containing the credential ID, authenticator data, client data JSON, and signature from the user's registered hardware authenticator. The JSON is UTF-8-encoded and then base64url-encoded (RFC 4648 section 5, no padding) before being placed in the header.

The web application handles passkey challenges automatically. If you are calling the API directly as a human user (which is unusual), your client must implement the WebAuthn assertion flow, including obtaining the challenge from the relying party and presenting the signed result.

## Passkey enrollment

Each human user must enroll at least one [passkey](/api-reference#tag/auth) before they can perform state-changing operations. The first passkey uses Trust On First Use (TOFU): the enrollment request carries a `device_name` and the WebAuthn registration response, with an empty body slot in the transcript (since no credential ID exists yet).

Subsequent passkeys require proof of an existing passkey to prevent unauthorized enrollment.

An administrator can [reset all passkeys for a user](/api-reference#tag/auth) via the passkey management endpoint, returning the user to TOFU state.

## When a passkey is required

Any operation that requires the nonce, timestamp, and assertion headers also requires a passkey assertion for human users. This covers all create, update, and delete operations, as well as sensitive reads such as the backup export.