Авторизационные протоколы и стандарты: OAuth 2.0 и JWT

Абстрактный механизм работы протокола OAuth 2.0

Абстрактный флоу авторизации с использованием протокола OAuth 2.0

• Клиент — это могут быть веб-приложения на серверах; приложения, исполняемые в user-agent, например PWA; нативные приложения, когда клиент работает на девайсе пользователя (телефоне или десктопе).
• Владелец ресурса — конечный пользователь, который владеет данными на ресурсе.
• Авторизационный сервер — сервер, который предоставляет механизм авторизации.
• Сервер ресурсов — это тот ресурс, с которым клиент хочет взаимодействовать.

1. Клиент (стороннее приложение) делает запрос авторизации к владельцу ресурса (пользователю). Это может происходить напрямую или через авторизационный сервер. Последний вариант является более предпочтительным.
2. Пользователь позволяет авторизацию, предоставляя креды. Это делается тем из способов, который используется на клиенте и поддерживается сервером. Например, Authorization Code Grant, Implicit, PKCE, — далее в уроке вы с ними познакомитесь.
3. Клиент запрашивает токен у авторизационного сервера, аутентифицируясь у авторизационного сервера и предоставляя разрешение авторизации от пользователя. Другими словами, через клиент передаются креды в авторизационный сервер, который может выступать одновременно и аутентификационным сервером, передавая креды от клиента. Например, пользователь вводит креды в почту (авторизационный сервер), вводя их через браузер (клиент).
4. Авторизационный сервер аутентифицирует клиента, валидирует разрешение пользователя и, если всё хорошо, выпускает access_token. В практической реализации авторизационный сервер выпускает JSON Web Token (JWT) — токен, который может содержать в себе и id_token, и access_token, и refresh_token, и другую дополнительную информацию.
5. Клиент идёт к серверу ресурсов и запрашивает защищённые ресурсы, предоставляя access_token, аутентифицируя себя через токен.
6. Сервер валидирует токен и решает, можно ли авторизовать запрашиваемого на предоставление ресурсов. Как правило, ресурсный сервер анализирует роли пользователя и, если их достаточно для получения запрашиваемой информации, — предоставляет эти ресурсы.

Понятия авторизации

Scope

• read_profile — чтение профиля пользователя;
• write_posts — создание постов;
• read_emails — чтение email пользователя;
• offline_access — получение refresh token.

https://oauth.provider.com/auth?
  client_id=YOUR_CLIENT_ID
  &response_type=code
  &scope=read_profile write_posts 

Local state

// 1. Генерируем случайное значение state
const state = generateRandomString();

// 2. Сохраняем его локально (например, в сессии)
session.setState(state);

// 3. Добавляем в URL авторизации
const authUrl = `https://oauth.provider.com/auth?
  client_id=YOUR_CLIENT_ID
  &response_type=code
  &state=${state}
  &redirect_uri=YOUR_REDIRECT_URI`; 

// При получении ответа от OAuth провайдера
function handleCallback(request) {
    // Получаем state из ответа
    const receivedState = request.query.state;
    
    // Получаем сохранённый state
    const savedState = session.getState();
    
    // Сравниваем значения
    if (receivedState !== savedState) {
        throw new Error('State mismatch - possible CSRF attack');
    }
    
    // Продолжаем процесс авторизации
    // ...
} 

Refresh token

1. Клиент запрашивает авторизацию и получает access token и refresh token.
   Authorization grant здесь — это разрешение, которое клиент получает от пользователя для доступа к защищённым ресурсам от имени пользователя. В контексте протокола OAuth 2.0 Authorization grant выступает как начальный шаг процесса авторизации, который клиент использует для получения токена доступа.
2. Клиент использует access token для доступа к ресурсному сервису и получает его.
3. Когда заканчивается access token, ресурсный сервис отправляет ошибку.
4. Когда клиент получает ошибку, он использует refresh token, чтобы получить новый access token.

• Хранить на сервере
  Поскольку ресурсный сервис не принадлежит пользователю, user-agent не обязан запрашивать их напрямую. Обычно это делается через API, и именно в этом сервисе следует хранить токены. Таким образом, ни десктопное приложение, ни браузер не имеют доступа к ним.
• Хранить в HTTP-only cookie
  Этот метод менее безопасен, чем предыдущий, но может быть применим в ситуациях с распределёнными серверами, которые не имеют доступа к данным о сессиях пользователей, например, если отсутствует общий кеш. В этом случае необходимо использовать HTTPS.
• Использовать шифрование перед сохранением в localStorage
  Этот сценарий подходит, когда нет собственного сервера API и для доступа к ресурсам сервиса необходимо обращаться к ним самим клиентом.
• Хранить в WebWorker
  Работает аналогично предыдущему способу, только токен хранится в памяти браузера.

JSON Web Token

• Заголовок (header) — эта часть содержит информацию о типе токена и алгоритме, который использовался для его подписи.
• Полезная нагрузка (payload) — она содержит утверждения о пользователе (например, идентификатор, роли и т. д.).
• Подпись (signature) — используется для проверки подлинности токена и целостности данных. JWS (JSON Web Signature) содержит информацию о том, как токен был подписан, включая алгоритм подписи и саму подпись. Подпись позволяет удостовериться, что данные не были изменены в процессе передачи.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c 

import jwt
from cryptography.hazmat.primitives import serialization

# Load the public key
with open("public_key.pem", "rb") as key_file:
    public_key = serialization.load_pem_public_key(
        key_file.read()
    )

# The JWT token received from the client
token = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"

try:
    # Decode and verify the token
    payload = jwt.decode(token, public_key, algorithms=["RS256"])
    print("Token is valid. Payload:", payload)
except jwt.ExpiredSignatureError:
    print("Token has expired")
except jwt.InvalidTokenError:
    print("Token is invalid") 

1. Импортируем библиотеку для работы с JWT: используется для создания, проверки и декодирования JSON Web Tokens.
2. Загружаем публичный ключ из файла:
   • Публичный ключ получен из файла public_key.pem. В указанном примере он представлен в виде сертификата.
   • Этот ключ может быть получен различными способами (например, запрашиваться у авторизационного сервера).
3. JWT, полученный от клиента:
   • Эта строка содержит токен, который был отправлен клиентом для аутентификации.
4. Декодируем и проверяем токен:
   • Используем публичный ключ и алгоритм RS256 для декодирования токена.
   • При успешной проверке получаем полезную нагрузку (payload) токена.
5. Обработка ошибок:
   • Если токен истёк, выводим сообщение о его истечении.
   • Если токен недействителен, выводим сообщение об этом.

• Нагрузка на авторизационный сервер меньше: JWT может являться репрезентацией авторизации и аутентификации — в нём содержится информация, которую можно использовать сразу для авторизации без перехода в авторизационный сервер.
• Может являться репрезентацией аутентификации: в токене есть несколько частей, например id_token, который представляет аутентификацию.
• Компактен по сравнению с другими стандартами, поэтому может использоваться для каждого HTTP/HTTPS-запроса. Вспомните, что XML-документ, который используется в протоколе SAML для аутентификации, громоздок. Из-за этого ресурсный сервер генерирует свой ключ, который и используется. А JWT может одновременно выполнять функции, аналогичные SAML-assertion и access_token. Поэтому из-за компактности и наличия авторизации его можно использовать для каждого запроса вместо ещё какого-то ключа.

• Токен продолжит действовать при смене роли пользователю или его выключении.

Authorization Code Grant

• Клиент — это приложение, которое запрашивает доступ к защищённым ресурсам от имени пользователя. Клиент может быть нативным приложением (например, мобильным) или веб-приложением (например, одностраничное приложение, SPA). Сам по себе клиент не имеет доступа к ресурсам, пока не получит разрешение от пользователя через сервер авторизации.
• User-agent — это программное обеспечение, которое взаимодействует с пользователем и клиентом. Обычно это браузер либо другое приложение, которое играет роль посредника, через который пользователь взаимодействует с сервером авторизации и клиентом.
• Владелец ресурса — конечный пользователь, владеющий ресурсами, доступ к которым запрашивает клиент.
• Сервер авторизации.

Процесс авторизации по Authorization Code Grant

1. Клиент инициализирует флоу, направляя владельца ресурса на сервер авторизации. Он передаёт свой идентификатор (client_id), указывает скоупы (scopes), локальное состояние (state) для защиты от CSRF-атак и redirect URI, на который сервер должен вернуть пользователя после авторизации.
2. Авторизационный сервер аутентифицирует владельца ресурса через user-agent и запрашивает разрешение у владельца ресурса на доступ для клиента.
3. Если пользователь успешно аутентифицирован и дал разрешение клиенту, сервер авторизации редиректит user-agent пользователя на redirect URI, который указал клиент. В этот URI добавляется авторизационный код и переданный ранее локальный state для проверки целостности данных (синхронизации сессии).
4. Авторизационный код передаётся клиенту. Время жизни этого кода настраивается в авторизационном сервере. Времени должно быть достаточно, чтобы клиент мог отправить его на сервер для обмена на токен, но ограниченно — для предотвращения злоупотреблений.
5. Клиент отсылает код на авторизационный сервер и получает взамен токен (как правило, JWT).
6. Клиент анализирует токен, забирает необходимую информацию, в том числе access_token, и сохраняет его для последующего использования.
7. Клиент запрашивает данные у ресурсного сервера, включая в запрос access_token.
8. Ресурсный сервер получает запрос, читает access_token, валидирует его. Если токен валидный и информация в токене позволяет осуществить действие — осуществляет запрашиваемое действие.

• client_id — идентификатор клиента, который использует способ авторизации;
• client_secret — эта информация генерируется авторизационным сервисом при настройке, и её надо безопасно предоставить клиенту и сохранить для использования;
• redirection endpoint URI — то, куда авторизационный пользователь будет переводить user-agent после успешной аутентификации. К этому же адресу добавляется авторизационный код. Это надо указывать, чтобы авторизационный сервер сверял redirect_URL, указанный в user-agent, с тем, который указан для этого сервиса, чтобы избежать подстановки redirect_URL.

Пример

1. Пользователь открывает десктоп-клиент Notion в первый раз, и приложение показывает варианты логина. Пользователь выбирает вход через Google.
2. Клиент передаёт на открытие user-agent (браузер) адрес SSO Google.
3. В нём есть scope, state и redirect URI, куда перевести пользователя.
4. Пользователь вводит креды Google или выбирает свой аккаунт.
5. Google переводит пользовательский user-agent (браузер) на страницу Notion с кодом.
6. Страница Notion забирает код и генерирует ссылку такого типа:
   Скопировать код

   JSX

   [https://www.notion.so/native/oauth2callback?state=eyJjYWxsYmFja1R5cGUiOiJuYXRpdmVyZWRpcmVjdCIsImVuY3J5cHRlZFRva2VuIjoidjAyOmdddfffZ29vZ2xlOm9ya3Jxdkg5dWF1S1JBX1l5QVVwYzN6NG5YWEZqSmJHT3JSc19kM3RxUHdBa2FDSWtEUURXUGthTFJSbmxwVjhheF9wU3pkX3lCVGFDZjFLUkZzUDhINk96Y2xsbjFaaGZUZEw2ZHpvUHR5REZKZ293VmRubHpXV0o1cUw4TGctSnM2YSJ9&code=4%2F0AVG7fiQbn2fVVpSXlGflu5woXQGjH4_J93SgFRFfMvkc_HSWCSLfgNSmlKHvR1eBvuh2nQ&scope=email profile https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile openid https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email&authuser=0&prompt=none](https://www.notion.so/native/oauth2callback?state=eyJjYWxsYmFja1R5cGUiOiJuYXRpdmVyZWRpcmVjdCIsImVuY3J5cHRlZFRva2VuIjoidjAyOmxvZ2luX3dpdGhfZ29vZ2xlOm9ya3Jxdkg5dWF1S1JBX1l5QVVwYzN6NG5YWEZqSmJHT3JSc19kM3RxUHdBa2FDSWtEUURXUGthTFJSbmxwVjhheF9wU3pkX3lCVGFDZjFLUkZzUDhINk96Y2xsbjFaaGZUZEw2ZHpvUHR5REZKZ293VmRubHpXV0o1cUw4TGctSnM2YSJ9&code=4%2F0AVG7fiQbn2fVVpSXlGflu5woXQGjH4_J93SgFRFfMvkc_HSWCSLfgNSmlKHvR1eBvuh2nQ&scope=email%20profile%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile%20openid%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email&authuser=0&prompt=none)  
7. Страница ноушена предлагает открыть ссылку по кастомному протоколу и при согласии пользователя передаёт десктоп-клиенту код.
8. Десктоп-клиент использует этот код, чтобы получить JWT.
9. Десктоп-клиент используется токен, чтобы запрашивать ресурсы Notion-страницы, заметки, файлы и прочее.

• Ресурсный сервис не узнаёт креды пользователей, а только получает токен.
• Передаётся только авторизационный код — данные пользователей остаются скрытыми.

Implicit Grant

Процесс авторизации по Implicit Grant

1. User-agent (браузер) инциирует работу, заходя в авторизационный сервис c добавлением redirect URL.
2. Пользователь аутентифицируется на этом сервере.
3. Авторизационный сервер возвращает redirect URL с добавлением во фрагмент URI информации, содержащей access token.
4. User-agent заходит на ресурс, указанный в redirect URL, но без access token.
5. User-agent скачивает скрипт работы локально.
6. User-agent выполняет скрипт для экстракции информации из фрагмента URI и получения из него access token.
7. User-agent передаёт токен клиенту для последующего использования.

Уязвимости рассмотренных протоколов

1. Оригинальное приложение делает запрос авторизации.
2. Браузер перенаправляет запрос на авторизационный сервис.
3. Браузер получает авторизационный код и открывает кастомный протокол.
4. Но открывается не ожидаемый клиент, а клиент злонамеренного приложения.
5. Злонамеренное приложение теперь есть доступ к секретным данным. Оно использует все креды и временный код.
6. И получает токен.

PKCE (Proof Key for Code Exchange)

Процесс авторизации по PKCE

1. Когда клиент идёт на авторизационный сервер, он предоставляет ещё хеш от code_verifier. Авторизационный сервер запоминает этот хеш.
2. Клиент получает код от авторизационного сервера.
3. Клиент отсылает авторизационный код + code_verifier.
4. Авторизационный сервер хеширует code_verifier, сравнивает результат с тем, что отослалось на первом шаге.
5. Если верификация прошла, сервер отсылает access_token.

• Сервисы, которые предоставляют данные сторонним приложениям. Например: Yandex, VK, Evernote. Стороннее приложение может получить доступ к ресурсам этих сервисов: прочитать ленту новостей, увидеть год рождения, скачать рекламную кампанию пользователя в определённом формате.
• Сервисы для реализации SSO, которые компании могут развернуть у себя, чтобы сделать авторизацию. Например, AWS IAM, Keyckoak, Okta.
• Кастомные самописные решения, реализующие протокол. Сюда попадают все сервисы из первой категории и то, что можете написать, например, вы самостоятельно.

Что почитать про протокол OAuth 2.0 и JWT

• Стандарт OAuth 2.0
• Стандарт JWT
• Сайт, который позволяет декодировать и валидировать JWT

Итоги

• OAuth 2.0 — это стандарт авторизации, который позволяет сторонним приложениям безопасно запрашивать доступ к данным пользователя без передачи пароля. Работа системы начинается с запроса клиента (стороннего приложения) через авторизационный сервер, после чего пользователь подтверждает запрос, а сервер выдаёт токен для взаимодействия с ресурсным сервером от имени пользователя.
• Флоу авторизации включает несколько вариантов. Authorization Code Grant обеспечивает максимальную защиту и подходит для веб- и десктопных приложений, Implicit Grant — более простой, используется для быстрого доступа в SPA и мобильных приложениях, но менее безопасен. PKCE дополняет защиту для клиентских приложений, особенно когда есть риск подмены авторизационного кода.
• Элементы безопасности в OAuth 2.0 включают Scope для ограничения доступа к конкретным данным, Local State для защиты от CSRF-атак и refresh token, который обновляет access token без повторной авторизации, улучшая пользовательский опыт и защищённость данных.
• JWT (JSON Web Token) также используется для компактной передачи аутентификационных и авторизационных данных, снижая нагрузку на авторизационный сервер.