HiveAuth
HomeGitHub
  • Introduction
    • Authentication
    • Signing and Broadcasting Transactions
    • Why use Hive Authentication Services?
  • Support
  • Developer documentation
    • Protocol description
      • Authentication
      • Transactions
      • Challenge
    • HAS for Applications
      • Connection
      • Encryption key (auth_key)
      • Authentication
        • Authentication request
        • Authentication payload
        • Authentication approval
        • Authentication refusal
        • Errors
        • Expiration
      • Transactions
        • Transaction request
        • Feedback to user
        • Transaction approval
        • Transaction refusal
        • Errors
        • Expiration
      • Challenge
        • Challenge request
        • Feedback to user
        • Challenge approval
        • Challenge refusal
        • Errors
        • Expiration
      • Attach
  • HAS for Wallets (PKSA)
    • Connection
    • Server Encryption Key retrieval
    • Proof of Key
    • Account registration
    • Authentication
      • Authentication payload
      • Authentications request
      • Feedback to user
      • Authentication approval
      • Authentication refusal
      • Errors
    • Transactions
      • Transaction request
      • Feedback to user
      • Transaction approval
      • Transaction refusal
      • Errors
    • Challenge
      • Challenge request
      • Feedback to user
      • Challenge approval
      • Challenge refusal
      • Errors
  • Tutorials
    • App code example
      • HAS Wrapper library
      • HTML code example
      • .NET code example
    • PKSA code example
      • Service Mode
  • Resources
    • Materials
Powered by GitBook
On this page
  • challenge_ack
  • challenge_ack_data
  1. Developer documentation
  2. HAS for Applications
  3. Challenge

Challenge approval

If the user approves the challenge request with its PKSA, the latest will send a challenge_ack message to the HAS with an access token and its expiration.

When the HAS will receive the user approval from its PKSA, it will forward it to the APP which will receive the following message:

challenge_ack

{
    cmd: "auth_ack",
    uuid: string,
    data: string
}
  • uuid: the request identifier

  • data: challenge_ack_data encrypted with the auth_key and converted to Base64

The APP must validate the received uuid against the request ID (uuid) that it received from the HAS in the challenge_wait message and ignore the challenge_ack message if they don't match.

The APP must decrypt the challenge_ack_data object using the encryption key previously shared with the PKSA (auth_key). If the APP cannot decrypt and parse challenge_ack_data, the APP must ignore the challenge_ack message.

This challenge_ack_data encryption/decryption process has been put in place to ensure that a malicious actor operating a HAS cannot bypass the PKSA to approve a challenge request.

As the encryption key has been provided offline to the PKSA, the HAS has no access to it and is therefore unable to decrypt, tamper then (re-)encrypt any data exchanged between the APP and the PKSA.

The structure of the challenge_ack_data is:

challenge_ack_data

{
    pubkey: string,
    challenge: string
}
  • pubkey: the account public key

  • challenge: the signed challenge

PreviousFeedback to userNextChallenge refusal

Last updated 3 years ago