> For the complete documentation index, see [llms.txt](https://docs.hiveauth.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hiveauth.com/developer-documentation/protocol-description/challenge.md).

# Challenge

Sometimes, an **APP** may want to validate an account by asking it to sign a predefined text string (challenge) with one of its keys.

This can be useful if the **APP** uses a front-end/back-end infrastructure. The **APP** front-end asks the **PKSA** to sign a message with one of the account's keys, then send it to its back-end when it makes API calls related to the account. The back-end can then validate the signed challenge against the account public key.

![](/files/CZ3abf0RQufbOgj4Z7st)

1. the **APP** sends a `challenge_req` command to the **HAS** with a valid `auth_token`.
2. the **HAS** provides the **APP** with a request identifier (`uuid`) and its expiration time (`expire`) in a `challenge_wait` message.
3. \[Optional] the **APP** shows information about the pending request to the user. It may also ask them to (re)start their **PKSA** to approve the challenge signing within the allowed delay.\
   **Note:** the **PKSA** can be started before or after the challenge request is issued. It doesn't matter.
4. the **HAS** then forwards the `challenge_req` command to the **PKSA**
5. the **PKSA** checks if it can decrypt the payload and prompts the user to approve or reject the challenge
6. the user approves or rejects the challenge.
7. the **PKSA** signs the challenge and sends a `challenge_ack` to the **HAS**
8. the **HAS** forwards the `challenge_ack` message to the **APP**.

{% hint style="info" %}
*For clarity, transaction refusal is not depicted in the above diagram.* The flow would be the same but with a `sign_nack` message.
{% endhint %}