Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Авторизация это проверка того, какие действия пользователь может выполнять, и к каким ресурсам он имеет доступ. В отличие от аутентификации, которая просто подтверждает, что пользователь является тем, за кого себя выдает, авторизация отвечает на вопрос: "Что пользователь может делать?".

2 Обычно авторизация реализуется на стороне сервера. Когда пользователь отправляет запрос на выполнение какой-либо операции или доступ к ресурсу, сервер проверяет, имеет ли он право на это. Эта проверка может включать взаимодействие с базой данных или специальным сервисом, который хранит информацию о правах доступа пользователя.

3 Представьте себе веб-приложение для управления проектами. Допустим, что в системе есть два типа пользователей: администраторы и обычные пользователи. Администратор может создавать, редактировать и удалять проекты, тогда как обычный пользователь может только просматривать и комментировать их. Когда пользователь пытается удалить проект, сервер должен проверить, является ли он администратором. Эта проверка и есть процесс авторизации.

4 В распределенных системах, где множество сервисов взаимодействуют друг с другом, авторизация может стать сложной задачей по нескольким причинам:

5 <ul><li>Высокая нагрузка на серверы:Каждое обращение требует запроса на сервер для проверки прав доступа, что может привести к повышенной нагрузке и задержкам.</li>

6 <li>Узкое место системы:Если сервер авторизации становится недоступным, вся система может перестать работать.</li>

7 <li>Задержки из-за сетевого взаимодействия:Взаимодействие между различными компонентами системы, особенно в микросервисной архитектуре, может приводить к задержкам из-за сетевых вызовов.</li>

8 </ul>Чтобы преодолеть эти сложности, авторизационные данные можно перенести на сторону клиента, передав их ему после успешной аутентификации. Клиент же, обращаясь к ресурсам внутри системы, будет передавать эти данные на каждый запрос, помогая сервисам определить, имеет ли он права на такой запрос. Главная проблема в такой схеме, как обеспечить невозможность подмены данных клиентов? Ведь если передавать их в открытом виде, то клиент сможет изменить значения и, например, стать администратором с полным набором прав.

9 <h2>JWT</h2>

10 Для решения этой задачи подходит JSON Web Tokens (JWT). JWT - это компактный, URL-безопасный формат для передачи данных между сторонами в виде JSON-объекта, который включает в себя полезную нагрузку (payload), подписанную или зашифрованную для обеспечения безопасности.

11 При использовании JWT права доступа пользователя могут быть закодированы внутрь токена, который затем передается клиенту. Этот токен включает в себя всю необходимую информацию для авторизации, и сервисы могут проверять его подлинность и содержание без необходимости обращаться к базе данных или серверу авторизации. Это дает ряд преимуществ:

12 <ul><li>Автономность:Сервисы могут проверять права пользователя без необходимости отправлять дополнительные запросы на сервер.</li>

13 <li>Снижение нагрузки:Снижается нагрузка на центральный сервер авторизации, так как проверка прав может происходить локально на стороне сервиса.</li>

14 </ul>JWT активно используются в системах единой авторизации SSO. Это подход, при котором для доступа ко всем сервисам системы достаточно авторизоваться ровно один раз, в специально предназначенном для этого сервисе.

15 Работает это так. Пользователь проходит аутентификацию один раз, после чего ему выдается JWT, содержащий информацию о его правах доступа. Этот токен передается между различными сервисами, и каждый сервис может локально проверять его подлинность и права пользователя без необходимости обращаться к центральному серверу.

16 В большинстве случаев для передачи токена используется, уже знакомый нам, Bearer механизм, где токен передается в заголовке:

17 Пример запроса с заголовком: