QuickBlox: Authorization and Authentication

Hi Khabrovtsy!

Today I will talk about authentication methods in QuickBlox . As well as affect authorization and its aspects.

So, any request to the QuickBlox API must be accompanied by token . Any other than the authorization request itself. There are 4 possible authorization entities in QuickBlox :

• attachment
• user
• device
• device user

An application is an entity with ReadOnly privileges. With an application token , for example, we can fulfill many requests for information, such as requests to Ratings or Location. The only write operation available with the application token is user creation. This entity is authenticated with the following data set:

• Application id
• Authorization key
• Authorization secret

This data set is standard for authentication of all entities and can be found in the application settings:


User is an entity that has access to all types of operations with the API, except perhaps operations related to the device, such as registering to receive Push messages. The user is authenticated in the same way as the application , but is added to the fields

• user [login]
• user [password]
• user [owner_id]

A device is an entity not unlike an application . There are no rights to write the same. The only difference is the ability to track devices on which the application is installed. The entity device adds to the application fields

• device [udid]
• device [platform]

The user of the device is the main authorization entity to which all possible operations with the QuickBlox API are available . For authentication uses all the preceding paragraphs.

And now more about token generation . The token key is generated in the bowels of QuickBlox in response to a POST authentication request by a request at http://api.quickblox.com/session with the following fields:

application
application_id	Application id
auth_key	Application key
timestamp	Time in Unix era format, which may differ from the server time by 1 hour.
nonce	Random number
signature	Signature
User
user [login]	User login
user [password]	User password
user [owner_id]	The owner of the user. From May 30, 2012 this field will be accepted, but ignored, i.e. it can be omitted.
Device
device [platform]	Device platform - ios, android or windows_phone
device [udid]	Unique device identifier

The application user uses all the described POST fields.

Read more about forming signature . The signature is encrypted using the HMAC-SHA1 mechanism . As the encryption body , a string of POST request fields is used as a GET request, i.e. fields are separated by an ampersad . Fields are also sorted alphabetically. The encryption key is the Authorization secret described earlier.

An example of creating a signature in PHP:

$body="application_id=$app_id&auth_key=$auth_key&device[platform]=$device_platform&device[udid]=$device_udid&nonce=$nonce×tamp=$timestamp&user[login]=$user_login&user[owner_id]=$owner_id&user[password]=$user_password";
$signature=hash_hmac('sha1',$body,$auth_secret);

Here you can see more convenient: http://pastebin.com/FhS5YEqR .

When creating a session, we are given information about the session. The default format is XML. But, specifying in the end URI ".json", the answer will come in JSON format.

Here is an example user authentication request :

curl -X POST -H "Content-Type: application/json" -d '{"application_id": "2", "auth_key": "DtF9cZPqTF8Wy9Q", "timestamp": "1333630580", "nonce": "1340569516", "signature": "13293a5bd2026b957ebbb36c89d9649aae9e5503", "user": {"login": "injoit", "password": "injoit", "owner_id": "4"}}' https://api.quickblox.com/auth.json

Here is an example response to a user authentication request :

{
  "session": {
    "application_id": 2,
    "created_at": "2012-04-03T07:41:12Z",
    "device_id": null,
    "id": 744,
    "nonce": 289239351,
    "token": "25b29b8c8d6f2d3afbf1d437cc611b23741fc7ee",
    "ts": 1333438822,
    "updated_at": "2012-04-03T07:41:13Z",
    "user_id": 3
}

Also, for example, we can upgrade the application token by logging in with the user :

curl -X POST -H "Content-Type: application/json" -d '{"login": "injoit", "password": "injoit", "owner_id": "4", "token": "cf5709d6013fdb7a6787fbeb8340afed8aec4c69"}' http://api.quickblox.com/login.json
{
  "blob_id": null,
  "created_at": "2012-01-16T08:13:38Z",
  "custom_parameters": null,
  "email": null,
  "external_user_id": 111,
  "facebook_id": null,
  "full_name": null,
  "id": 3,
  "last_request_at": "2012-04-04T10:27:40Z",
  "login": "injoit",
  "owner_id": 4,
  "phone": null,
  "twitter_id": null,
  "updated_at": "2012-04-04T10:27:40Z",
  "website": null,
  "user_tags":"superman"
}

After that, the application token will already become the user's token.

The session is destroyed either by a direct DELETE request at http://api.quickblox.com/auth_exit , or after an hour of inactivity the system itself will delete the token.

curl -X DELETE "https://api.quickblox.com/auth_exit?token=422ce2791d7070b88a82f415b3693c81612e3423"

The main documentation for this section is on the Developers: Authentication and Authorization page .

Comment. Recently, the token in the request parameters GET, PUT, POST and DELETE has been deprecated, the main place for specifying the token is the request headers.

curl -X POST -H "QB-Token: cf5709d6013fdb7a6787fbeb8340afed8aec4c69"

This is an important security update, so all existing SDKs and samples will be updated accordingly.

For any questions of clarification, mutual cooperation or just using QuickBlox, you can contact me korjik and Taras qbtarzan or email andrey.kozhokaru@quickblox.com .