> For the complete documentation index, see [llms.txt](https://kaze.gitbook.io/qa-theory/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kaze.gitbook.io/qa-theory/web/kak-proiskhodit-avtorizaciya-na-servere.md).

# Как происходит авторизация на сервере?

Авторизация на сервере происходит после успешной **аутентификации** (проверки личности пользователя) и сводится к проверке его **прав доступа** к ресурсам или действиям.

***

### Этапы процесса:

#### **1. Клиент → Сервер: отправка данных**

* Пользователь вводит логин/пароль или предоставляет токен/сертификат.
* Эти данные отправляются на сервер (обычно через HTTPS для защиты).

***

#### **2. Аутентификация (Authentication)**

* Сервер проверяет, что пользователь действительно тот, за кого себя выдает.\
  Примеры:
  * Сравнение логина/пароля с базой.
  * Проверка JWT-токена (подпись + срок действия).
  * Валидация OAuth-токена через внешний сервис.

***

#### **3. Авторизация (Authorization)**

* После успешной аутентификации сервер проверяет:
  * какие **роли** есть у пользователя (admin, user, guest);
  * какие **права** назначены (можно ли читать, писать, удалять ресурс).
* Это реализуется через **ACL (Access Control List)**, **RBAC (Role-Based Access Control)** или **ABAC (Attribute-Based Access Control)**.

***

#### **4. Ответ сервера**

* Если права есть → доступ разрешён (**200 OK** или нужный результат).
* Если прав нет → возвращается **403 Forbidden**.

***

### Примеры механизмов авторизации:

* **JWT (JSON Web Token)** — клиент хранит токен, сервер проверяет подпись и срок действия.
* **OAuth 2.0** — доступ через внешний сервис (Google, Facebook, GitHub).
* **Session-based** — сервер хранит сессию в базе/Redis, клиент — cookie с session ID.
* **API Keys** — простой вариант для сервисов и интеграций.