QuickBlox: Authorization and Authentication

Hi Habrovtsy!

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

So, any request to the QuickBlox API must be followed by a token . Anyone 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 rights. With an application token, for example, we can fulfill many requests for information, such as requests for 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:

')
A user is an entity that has access to all types of operations with an API, except perhaps for device-related operations, such as registering for receiving 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 that is not much different from an application . There is no write permission either. The only difference is that it is possible to track the devices on which the application is installed. Entity device to the fields of the application adds

• device [udid]
• device [platform]

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

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

application
application_id	Application id
auth_key	Application key
timestamp	Time in the Unix format of the era, 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]	User Owner. 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 user of the application uses all the described POST fields.

Learn more about creating a signature . The signature is generated by encryption using the HMAC-SHA1 mechanism. The encryption body is a string of POST request fields in the form of a GET request, i.e. fields are separated by an ampersad . Also the fields are sorted alphabetically. The encryption key is the Authorization secret , described earlier.

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 conveniently: http://pastebin.com/FhS5YEqR .

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

Here is an example of a 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 of a 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 the user with it:

 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 this, 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 will remove the token itself.

 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 GET, PUT, POST and DELETE request parameters has been abolished (deprecated), the request headers have become the main place to specify the token.

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

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

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