Как работает авторизация на сайте?

Принципы авторизации на сайте

Авторизация — это процесс проверки прав доступа пользователя к определённым ресурсам или действиям после успешной аутентификации (подтверждения личности). Если аутентификация отвечает на вопрос «Кто вы?», то авторизация — «Что вам разрешено делать?». В современном вебе это сложный многоуровневый механизм.

Основные модели и протоколы авторизации

1. Ролевая модель (RBAC — Role-Based Access Control):

    *   Пользователям присваиваются роли (например, `Администратор`, `Редактор`, `Пользователь`).
    *   Каждой роли назначается набор разрешений (permissions).
    *   Это наиболее распространённый и гибкий подход.

```yaml
# Пример конфигурации RBAC
roles:
  admin:
    permissions: [create, read, update, delete, manage_users]
  editor:
    permissions: [create, read, update]
  viewer:
    permissions: [read]
```

2. На основе токенов (Token-Based):

    *   После логина сервер генерирует **JWT (JSON Web Token)** или подобный токен.
    *   Токен содержит «заявки» (claims) о пользователе и его правах.
    *   Клиент (браузер) хранит токен (часто в `localStorage` или куках) и отправляет его с каждым запросом в заголовке `Authorization: Bearer <token>`.
    *   Сервер проверяет валидность и подпись токена и извлекает из него данные для авторизации.

```javascript
// Пример структуры декодированного JWT (payload)
const payload = {
  sub: "user123", // subject (идентификатор пользователя)
  name: "Иван Иванов",
  roles: ["editor", "premium_user"],
  exp: 1735681999 // expiration time (срок действия)
};
```

3. Протокол OAuth 2.0:

    *   Используется для делегирования прав. Позволяет сайту получить ограниченный доступ к данным пользователя в другом сервисе (например, «Войти через Google»).
    *   Ключевые участники: **Resource Owner** (пользователь), **Client** (наш сайт), **Authorization Server** (сервер Google), **Resource Server** (API Google).
    *   Основной поток — **Authorization Code Flow**, безопасный для веб-приложений.

Техническая реализация на стороне сервера

На бэкенде авторизация реализуется как мидлварь (middleware) или фильтры (filters), которые перехватывают входящие запросы перед передачей в контроллеры бизнес-логики.

# Пример мидлвари авторизации на Python (Flask)
from functools import wraps
from flask import request, abort

def require_role(required_role):
    def decorator(f):
        @wraps(f)
        def decorated_function(*args, **kwargs):
            # 1. Извлекаем токен из заголовка
            auth_header = request.headers.get('Authorization')
            if not auth_header or not auth_header.startswith('Bearer '):
                abort(401)  # Unauthorized

            token = auth_header.split(' ')[1]

            # 2. Верифицируем токен и декодируем payload (опущено для краткости)
            user_data = verify_and_decode_jwt(token)

            # 3. Проверяем авторизацию (наличие нужной роли)
            if required_role not in user_data.get('roles', []):
                abort(403)  # Forbidden

            # 4. Если проверка пройдена — выполняем основной метод
            return f(*args, **kwargs)
        return decorated_function
    return decorator

# Использование декоратора на эндпоинте
@app.route('/admin/panel')
@require_role('admin')
def admin_panel():
    return "Панель администратора"

Роль фронтенда в авторизации

Фронтенд не принимает решений по авторизации (это делается только на сервере!), но отвечает за:

• Отображение UI в зависимости от прав: скрытие кнопок «Удалить» для пользователей без прав.
• Клиентскую маршрутизацию: запрет перехода на маршрут /admin через роутер.
• Хранение и передачу учётных данных: безопасное хранение токена и его прикрепление к исходящим HTTP-запросам.

// Пример проверки прав на фронтенде (Vue.js Composition API)
import { computed } from 'vue';
import { useAuthStore } from '@/stores/auth';

export function useUserPermissions() {
  const authStore = useAuthStore();

  const userCan = (permission: string) => {
    return authStore.currentUser?.permissions?.includes(permission);
  };

  // Реактивные вычисляемые свойства для UI
  const canEditArticles = computed(() => userCan('article:edit'));
  const canDeleteUsers = computed(() => userCan('user:delete'));

  return { userCan, canEditArticles, canDeleteUsers };
}

Безопасность и лучшие практики

• Принцип наименьших привилегий: пользователь получает ровно те права, которые необходимы для его задач.
• Проверка на сервере — всегда: клиентская проверка — только для UX, её легко обойти.
• Регулярная инвалидация сессий/токенов: короткое время жизни access-токенов, использование refresh-токенов.
• Защита от вертикального и горизонтального повышения прав: пользователь не может получить доступ к данным другого пользователя того же уровня (/api/orders/123, где 123 — не его заказ) или к функциям высшего уровня.
• Логирование событий авторизации для аудита безопасности.

Таким образом, авторизация — это непрерывный процесс проверки на уровне каждого запроса, основанный на информации о пользователе, полученной после аутентификации, и построенный на чётко определённой политике прав доступа (RBAC, ACL и др.). Корректная реализация критически важна для безопасности и целостности данных приложения.