---
title: Authorisation
updatedAt: 2026-09-06T11:12:34.150Z
---
Fetch the complete documentation index at: https://docs.watchers.io/llms.txt
# Authorisation
User authorisation in Watchers' Social SaaS Platform secures access to chat rooms and user data. Two main methods are offered:
1. **Authorisation with an Encrypted User ID**This method involves passing an encrypted user ID via a GET parameter, ensuring security against unauthorised access attempts like guessing or brute-forcing.
2. **OAUTH Authorisation.** Watchers supports OAUTH as an authorisation method, allowing for secure and efficient user verification.
## Authorisation with an Encrypted User ID
This method involves passing an encrypted user ID via a GET parameter, ensuring security against unauthorised access attempts like guessing or brute-forcing.
### Authorisation scheme
**How it works:**
For authorisation, the encrypted user ID is transferred in the URL when opening a room, as shown below:
```
https://chat.watchers.io/?roomId=[Room ID]&userId=[Encrypted User ID]&apikey=[API key]
```
• **userId** is encrypted by the Partner using a mutually agreed method. Watchers will decrypt this using a secret key.
### User ID Encryption
You can encrypt GET parameter `userId` using **`aes-256-ecb`** encryption method
And encode encrypted result to **`base64`**, **`urlencode`** and transmit it **`by GET parameter`**.
### Scheme
> If users try to transmit any data without correct secret key encryption - **decryption will be failed**
>
> **users can’t guess any other userID or enter to chat without registration or try to avoiding the product which the chat was integrated**
### Example encryption service code
[https://gitlab.com/watchershub/aes-example](https://gitlab.com/watchershub/aes-example)
### Secret Key requirements
We use a 256-bit secret key and AES ECB type of encryption; the secret key should be 32 symbols in length.
## OAUTH Authorisation
Watchers supports OAUTH as an authorisation method, allowing for secure and efficient user verification.
### Enabling OAUTH Authorisation
You can enable this authorisation method through the **Admin Panel**.
### OAUTH Overview - Scheme
The OAUTH scheme used by Watchers involves passing an **authcode** instead of a **userid**. This authcode should be a one-time use code to enhance security.
### Requirements for Implementation
This authorisation type necessitates an API endpoint on the partner’s side to exchange the authcode for a userid. The URL for this API endpoint must be entered in the Admin Panel.
### API Endpoint Details
Request data:
```json
{ "authCode" : "123456789" }
```
Response requirement:
```jsx
{"userId" : "987654321" }
```
Setting up this endpoint ensures that the authorization code provided during user interaction is exchanged securely and efficiently for a userid, which is then used within the Watchers platform to identify and authenticate the user.
### Admin Panel Chat Authorization
In addition to the standard OAUTH flow, admin panel users can be authorised to access chat using a static token.
#### Configuration
To enable this flow, set a static token in the **Authorization token** field in the admin panel.
#### How it works
* When an admin opens the chat, the system sends the configured **Authorization token** as `authCode` to the OAUTH endpoint.
* The endpoint must recognize this token and return a valid user account.
* The returned `userId` is used to authorise the admin panel user in chat.
#### Requirements
* The token must be **permanent (non-expiring)**.
* A **single shared token** is used for all admin panel users.
* The partner’s OAUTH endpoint must map this token to a predefined user account.
* The response format remains the same as in the standard flow:
```json
{
"userId": "admin_user_id"
}
```
#### Example
**Request**
```json
{
"authCode": "STATIC_ADMIN_TOKEN"
}
```
**Response**
```json
{
"userId": "admin_123"
}
```
For authorisation, the encrypted user ID is transferred in the URL when opening a room, as shown below:
```
https://chat.watchers.io/?roomId=[Room ID]&userId=[Encrypted User ID]&apikey=[API key]
```
• **userId** is encrypted by the Partner using a mutually agreed method. Watchers will decrypt this using a secret key.
### User ID Encryption
You can encrypt GET parameter `userId` using **`aes-256-ecb`** encryption method
And encode encrypted result to **`base64`**, **`urlencode`** and transmit it **`by GET parameter`**.
### Scheme
> If users try to transmit any data without correct secret key encryption - **decryption will be failed**
>
> **users can’t guess any other userID or enter to chat without registration or try to avoiding the product which the chat was integrated**
### Example encryption service code
[https://gitlab.com/watchershub/aes-example](https://gitlab.com/watchershub/aes-example)
### Secret Key requirements
We use a 256-bit secret key and AES ECB type of encryption; the secret key should be 32 symbols in length.
## OAUTH Authorisation
Watchers supports OAUTH as an authorisation method, allowing for secure and efficient user verification.
### Enabling OAUTH Authorisation
You can enable this authorisation method through the **Admin Panel**.
### OAUTH Overview - Scheme
The OAUTH scheme used by Watchers involves passing an **authcode** instead of a **userid**. This authcode should be a one-time use code to enhance security.
### Requirements for Implementation
This authorisation type necessitates an API endpoint on the partner’s side to exchange the authcode for a userid. The URL for this API endpoint must be entered in the Admin Panel.
### API Endpoint Details
Request data:
```json
{ "authCode" : "123456789" }
```
Response requirement:
```jsx
{"userId" : "987654321" }
```
Setting up this endpoint ensures that the authorization code provided during user interaction is exchanged securely and efficiently for a userid, which is then used within the Watchers platform to identify and authenticate the user.
### Admin Panel Chat Authorization
In addition to the standard OAUTH flow, admin panel users can be authorised to access chat using a static token.
#### Configuration
To enable this flow, set a static token in the **Authorization token** field in the admin panel.
#### How it works
* When an admin opens the chat, the system sends the configured **Authorization token** as `authCode` to the OAUTH endpoint.
* The endpoint must recognize this token and return a valid user account.
* The returned `userId` is used to authorise the admin panel user in chat.
#### Requirements
* The token must be **permanent (non-expiring)**.
* A **single shared token** is used for all admin panel users.
* The partner’s OAUTH endpoint must map this token to a predefined user account.
* The response format remains the same as in the standard flow:
```json
{
"userId": "admin_user_id"
}
```
#### Example
**Request**
```json
{
"authCode": "STATIC_ADMIN_TOKEN"
}
```
**Response**
```json
{
"userId": "admin_123"
}
```