Когда человек входит в приложение, системе нужно понять две вещи: кто перед ней и что этому пользователю или приложению разрешено. Для этого существуют разные механизмы.

Cookies + Session После входа сервер создаёт сессию. На сервере появляется запись примерно такого содержания: «Сессия ABC123 принадлежит пользователю 542. Пользователь авторизован. Его роль — клиент. Сессия действует до такого-то времени». Браузер получает Cookie, внутри которого обычно находится только идентификатор этой сессии: ABC123. При следующем запросе браузер отправляет этот идентификатор. Сервер находит по нему запись своей сессии и понимает, кто делает запрос и какое у него состояние. То есть сервер хранит именно состояние текущей пользовательской сессии: пользователя, факт авторизации, срок действия, иногда дополнительные данные и параметры сессии. Session привязана к конкретному входу пользователя. Вышел из аккаунта — сервер может удалить или сделать недействительной эту сессию.

API Key API Key работает похоже только на самом поверхностном уровне: клиент тоже отправляет некоторый ключ, а сервер по этому ключу что-то определяет. Но смысл ключа другой.Например, сервер хранит: «Ключ XYZ789 принадлежит приложению Mobile App №2. Ему разрешён доступ к API, доступны такие-то методы, лимит — 1000 запросов в час». Сам клиент отправляет только XYZ789. Здесь сервер хранит не состояние текущего входа пользователя, а информацию о самом API-клиенте или интеграции: кому принадлежит ключ, какие права у него есть, какие ограничения установлены, действует ли ключ, когда его нужно заменить и так далее. API Key обычно не означает: «Пользователь Вася сейчас вошёл в приложение». Он означает: «Вот зарегистрированный клиент или интеграция, которой разрешено обращаться к этому API».

В чём они похожи? И Session ID, и API Key могут выглядеть просто как случайная строка. Клиент отправляет эту строку серверу. Сервер использует её, чтобы понять, кому разрешён доступ и что можно делать. В обоих случаях сервер может хранить информацию, связанную с этой строкой. Но информация эта разная. Session: «ABC123 → пользователь 542 → текущая сессия → авторизован → действует до 20:00». API Key: «XYZ789 → приложение №2 → доступ к API → такие-то права → такой-то лимит».

Главное различие Session отвечает на вопрос: «Кто сейчас вошёл и что происходит с его текущей сессией?» API Key отвечает на вопрос: «Какой клиент или приложение обращается к API и какой доступ ему разрешён?» Поэтому Session обычно связана с пользовательским входом и текущим состоянием авторизации, а API Key — с постоянным доступом приложения или интеграции к API. И ещё важный момент: Session ID и API Key сами по себе могут выглядеть практически одинаково. Разница не в том, как выглядит строка, а в том, что эта строка означает и какую информацию сервер связывает с ней.

JWT Здесь подход другой. Сервер выдаёт клиенту токен, внутри которого уже содержатся данные, например идентификатор пользователя и срок действия, плюс криптографическая подпись. Клиент хранит токен и отправляет его с запросами. Сервер проверяет подпись и содержимое токена.

OAuth 2.0 OAuth нужен, когда одному приложению нужно получить разрешение на доступ к ресурсам другого приложения или сервиса. Например, приложение получает разрешение работать с определёнными данными пользователя Google.

OpenID Connect OpenID Connect построен поверх OAuth 2.0 и добавляет подтверждение личности пользователя.

Если совсем коротко: Session — «вот моя текущая пользовательская сессия». API Key — «вот зарегистрированный клиент, которому разрешено обращаться к API». JWT — «вот токен, внутри которого уже есть данные и подпись». OAuth 2.0 — «вот механизм, с помощью которого приложение получает разрешение». OpenID Connect — «вот механизм, с помощью которого подтверждается личность пользователя».

#QA #Тестирование #ManualQA #QAEngineer #IT #Разработка #Web #API