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
  1. Developer documentation
  2. HAS for Applications

Encryption key (auth_key)

PreviousConnectionNextAuthentication

Last updated 1 month ago

To secure the authentication process, the data exchanged between the APP and the PKSA will be encrypted using an encryption key (auth_key). By encrypting these data, the HAS will be unaware of what's going on between the APP and the PKSA and unable to tamper with the authentication process.

Before initiating the authentication process, the APP must create an auth_key for each account it manages.

The auth_key can be any string. However, we recommend using a each time you generate a new auth_key to strengthen security.

This auth_key should be stored by the APP if it plans to perform transactions later.

Each account managed by the APP should use a different auth_key.

The APP should create a new auth_key each time it authenticates an account and should never reuse it for another authentication.

For the PKSA to be able to decrypt the payload sent to it by the APP, the APP will have to share it with the PKSA. This can be done in two ways:

  1. by embedding it in a QR code that the PKSA mobile app will scan

  2. by encrypting it and embedding it in the auth_req authentication payload when running your own PKSA in

uuid
Service Mode