You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
date: 2021-08-01
title: Pusher Channels Docs | Generating authentication and authorization strings
description: This guide is designed for library makers who wish to implement the signing mechanism in use for user authentication and by private channels.
layout: channels.njk
eleventyNavigation:
parent: Library auth reference
key: Authentication and authorization signatures
title: Authentication and authorization signatures
order: 1
Generating authentication and authorization strings
This guide is designed for library makers who wish to implement the signing mechanism in use for user authentication and by private channels. Visit those pages for information about integration and an overview of the technique.
For both user authentication and private channel authorization, auth strings have the following format
<pusher-key>:<signature>
The signature is a HMAC SHA256 hex digest. This is generated by signing a string with your Channels secret.
For user authentication, the string should be the following, where user_data is a JSON-encoded object containing at least an user_id property set to a non-empty string containing the user id.
<socket_id>:<channel_name>:<user_data>
For private channel authorization, the string should be:
<socket_id>:<channel_name>
Worked examples
Suppose that you have the following Channels credentials
And the user has connected and Channels has assigned that user with a socket_id with the value 1234.1234.
User authentication
Given that your application receives a POST request to /pusher/user-auth with the parameters
(socket_id = 1234.1234)
You would retrieve the user information according to your application and create a string containing a JSON encoded object with at least the id property set to a non-empty string.
{"user_id":"12345"}
Then you would create a HMAC SHA256 hex digest of the following string using your secret key
The authentication response should be a JSON object with
an auth property with a value composed of the application key and the authentication signature separated by a colon ':' as follows
a user_data property with a string containing the JSON encoded object. It should be exactly the same as the one included in the authentication signature
You would first check that the user (authenticated via cookies or whatever) has permission to access channel private-foobar. If she has permission you would create a HMAC SHA256 hex digest of the following string using your secret key
The authorization response should be a JSON string with a an auth property with a value composed of the application key and the authentication signature separated by a colon ':' as follows:
For user authentication, as outlined in the example above, the response from the server must include a user_data property. The user_data property must contain the exact same JSON-encoded string that was used to build the auth string.
Encrypted channels require an additional shared_secret key in the authorization response, which is populated with the per-channel shared key to use for decryption. The key is base64 encoded, it must be decoded before use.
This value is not part of the signature for the authorization token, it is independent of the value in the auth key.
For example:
{
"auth": "...", // as above for private channels"shared_secret": "<channel secret derived from master secret>"
}
Presence channels
Presence channels require extra user data to be passed back to the client along with the authorization string. These data need to be part of the signature as a valid JSON string. For presence channels, the signature is a HMAC SHA256 hex digest of the following string:
<socket_id>:<channel_name>:<JSONencodeduserdata>
Ruby example for presence channels:
require"json"require"openssl"json_user_data=JSON.generate({:user_id=>10,:user_info=>{:name=>"Mr. Channels"}})# NB: written as double-escaped JSON!# => "{\"user_id\":10,\"user_info\":{\"name\":\"Mr. Channels\"}}"digest=OpenSSL::Digest::SHA256.newsecret="7ad3773142a6692b25b8"string_to_sign="1234.1234:presence-foobar:#{json_user_data}"signature=OpenSSL::HMAC.hexdigest(digest,secret,string_to_sign)putsauth="278d425bdf160c739803:#{signature}"# => 278d425bdf160c739803:afaed3695da2ffd16931f457e338e6c9f2921fa133ce7dac49f529792be6304c
The authorization response should be a JSON string with a an auth property with a value composed of the application key and the authentication signature separated by a colon ':'. A channel_data property should also be present composed of the data for the channel as a string (note: double-encoded JSON):
date: 2021-08-01
title: Pusher Channels Docs | Generating authentication and authorization strings
description: This guide is designed for library makers who wish to implement the signing mechanism in use for user authentication and by private channels.
layout: channels.njk
eleventyNavigation:
parent: Library auth reference
key: Authentication and authorization signatures
title: Authentication and authorization signatures
order: 1
Generating authentication and authorization strings
This guide is designed for library makers who wish to implement the signing mechanism in use for user authentication and by private channels. Visit those pages for information about integration and an overview of the technique.
For both user authentication and private channel authorization, auth strings have the following format
The signature is a HMAC SHA256 hex digest. This is generated by signing a string with your Channels secret.
user_data
is a JSON-encoded object containing at least anuser_id
property set to a non-empty string containing the user id.Worked examples
Suppose that you have the following Channels credentials
And the user has connected and Channels has assigned that user with a
socket_id
with the value1234.1234
.User authentication
Given that your application receives a POST request to
/pusher/user-auth
with the parametersYou would retrieve the user information according to your application and create a string containing a JSON encoded object with at least the
id
property set to a non-empty string.Then you would create a HMAC SHA256 hex digest of the following string using your secret key
Using Ruby as an example
The authentication response should be a JSON object with
auth
property with a value composed of the application key and the authentication signature separated by a colon ':' as followsuser_data
property with a string containing the JSON encoded object. It should be exactly the same as the one included in the authentication signaturePrivate channel
Given that your application receives a POST request to
/pusher/auth
with the parametersYou would first check that the user (authenticated via cookies or whatever) has permission to access channel
private-foobar
. If she has permission you would create a HMAC SHA256 hex digest of the following string using your secret keyUsing Ruby as an example
The authorization response should be a JSON string with a an
auth
property with a value composed of the application key and the authentication signature separated by a colon ':' as follows:User authentication
For user authentication, as outlined in the example above, the response from the server must include a
user_data
property. Theuser_data
property must contain the exact same JSON-encoded string that was used to build theauth
string.Encrypted channels
Encrypted channels require an additional
shared_secret
key in the authorization response, which is populated with the per-channel shared key to use for decryption. The key is base64 encoded, it must be decoded before use.This value is not part of the signature for the authorization token, it is independent of the value in the
auth
key.For example:
Presence channels
Presence channels require extra user data to be passed back to the client along with the authorization string. These data need to be part of the signature as a valid JSON string. For presence channels, the signature is a HMAC SHA256 hex digest of the following string:
Ruby example for presence channels:
The authorization response should be a JSON string with a an
auth
property with a value composed of the application key and the authentication signature separated by a colon ':'. Achannel_data
property should also be present composed of the data for the channel as a string (note: double-encoded JSON):The text was updated successfully, but these errors were encountered: