Skip to content
GitHub

Hash verification

Once a resource owner (RO) authorizes a client software, the authorization server (AS) will redirect the RO’s identity provider (IdP) to the finish URI. In order to secure this communication and verify that the redirect indeed emanated from the AS, the AS will provide a hash parameter in the request to the client’s callback URI. The client must verify this hash.

Hashing method

The hash base is generated by concatentating the following values in sequence using a single newline (0x0A) character to separate them:

  1. nonce value sent by the client in the initial request.
  2. nonce value sent by the AS from the interaction finish response.
  3. interact_ref returned from the AS in the interaction finish method.
  4. The grant endpoint uri the client used to make its initial request.

The following example shows the four aforementioned components that make up the hash base. There is no padding or whitespace before or after each line and no trailing newline character.

Example hash base

VJLO6A4CATR0KRO
MBDOFXG4Y5CVJCX821LH
4IFWWIKYB2PQ6U56NL1
https://server.example.com/tx

The ASCII encoding of this string is hashed with the algorithm specified in the hash_method parameter under the finish key of the interaction finish request. The byte array from the hash function is then encoded using URL-Safe Base64 with no padding. The resultant string is the hash value.

Unless specified by the client in the initial request, the hash_method will default to sha-256. If the client specifies the hash_method, the hash_method must be one of the hash name strings defined in the IANA Named Information Hash Algorithm Registry.

Using our hash base string example above, the following is the sha-256 encoded hash that uses the 256-bit SHA2 algorithm.

SHA2 256-bit hash example

x-gguKWTj8rQf7d7i3w3UhzvuJ5bpOlKyAlVpLxBffY

For more information refer to the Calculating the interaction hash section of the GNAP specification.