Introduction

You can use Access Manager to generate time-limited tokens with permissions for individual resources such as channels, channel groups, or uuids. Once the permissions are granted, the token must be passed back to the clients. You can also revoke tokens, effectively removing all embedded permissions.

For more details, refer to Access Manager.

Signature Generation in Access Manager​

The signature is used to verify if the request was signed with the secret key associated with the PubNub subscribe key.

  • Signature is computed using HMAC+SHA256 with the user's secret key as the signing key.
  • The signing message is composed of the HTTP method, publish key, request path, query string, and request body (or empty string) in the following format {method}\n{pub_key}\n{path}\n{query_string}\n{body}
  • Query parameters must be sorted lexicographically (case-sensitive) by a key. Duplicate keys are not allowed.
  • Replace special characters in the query parameters using the %xx escape. Letters, digits, and the characters _.- are never quoted. For example, ~user/1_2.3-4 should be encoded %7Euser%2F1_2.3-4. Uppercase characters in the percent escapes are required. In other words, all characters matching the RegEx /[^0-9a-zA-Z\-_\.]/ must remain unencoded.
  • Space characters must be replaced by %20 (NOT the + character).
  • Each key-value pair must be separated by an ampersand (&) character.
  • Unicode characters must be broken up into UTF-8 encoded bytes before percent-encoding.
# Example query string containing unicode characters
timestamp=1234567898&PoundsSterling=£13.37

# The same query string after sorting and percent-encoding
timestamp=1234567898&PoundsSterling=%C2%A313.37
  • The request body must be appended to the message verbatim (byte-for-byte, as provided in the request).

Access Manager uses signatures in v2, but if your application uses signatures in v1, read the v1 signature documentation to learn more about computing the signature for the request.

Signature example​

In this example, the POST body does not have a trailing line break character, but it does have a structural whitespace and is encoded with UTF-8.

POST demo /v3/pam/demo/grant PoundsSterling=%C2%A313.37&timestamp=1234567898

{ "ttl": 1440, "permissions": { "resources" : { "channels": { "inbox-jay": 3 }, "groups": {}, "users": {}, "spaces": {} }, "patterns" : { "channels": {}, "groups": {}, "users": {}, "spaces": {} }, "meta": { "user-id": "jay@example.com", "contains-unicode": "The 🦝 test." } } }

Let's imagine the demo account's secret key is wMfbo9G0xVUG8yfTfYw5qIdfJkTd7A. The signature generated for this request is Base64 encoded:e1H7ZHXXXNCp8X4dMx3tXFGPiIngCMF4ZtN1eKnq05I=. Then, let's use the URL safe characters and replace + and / with - and _, respectively. The padding = characters are removed from the end. The final step is concatenating the version prefix v2. The expected signature for this request will look as follows: v2.2vhp1zCBy5LwyeZTS6/BiS8A9sXQisrcRFSBRYyZU/4=.