Как работает OAuth 2.0 и OpenID Connect

Client Credentials

Рассмотрим один из самых простых способов авторизации в OAuth 2.0 — схему Client Credentials. Этот метод разработан для безопасного взаимодействия между сервисами и часто используется, когда один сервис должен обращаться к другому сервису без участия пользователя.

Каждый клиент должен быть зарегистрирован на авторизационном сервере. В процессе регистрации клиент получает уникальные идентификаторы:

• client_id – это публичный идентификатор клиента, который передаётся в каждом запросе на авторизацию. Он позволяет авторизационному серверу определить, какое приложение запрашивает доступ.
• client_secret – это секретный ключ, который используется для проверки подлинности клиента. Он должен храниться в надёжном месте и не должен быть раскрыт третьим лицам.

Запрос токена (1). Service 1 отправляет запрос к авторизационному серверу, передавая свои client_id и client_secret. Это делается с использованием метода POST и указанием типа авторизации grant_type=client_credentials:

curl --request POST \
 --url 'https://YOUR_DOMAIN/oauth/token' \
 --header 'content-type: application/x-www-form-urlencoded' \
 --data grant_type=client_credentials \
 --data client_id=YOUR_CLIENT_ID \
 --data client_secret=YOUR_CLIENT_SECRET \
 --data audience=YOUR_API_IDENTIFIER

Здесь audience указывает целевой ресурс (Service 2), для которого будет действовать access_token. Это поле определяет, какие именно ресурсы будут доступны по этому токену. Авторизационный сервер проверяет audience при выдаче токена, чтобы убедиться, что запрос направлен на доступ к конкретному API. Это помогает избежать использования токена не по назначению и усиливает безопасность.

Получение access_token (2). В ответ на запрос авторизационный сервер выдаёт access_token, который Service 1 может использовать для обращения к Service 2:

{
    "access_token": "eyJz93a...k4laUWw",
    "token_type": "Bearer",
    "expires_in": 86400
}

• access_token: строка токена, которая используется для авторизации запросов к Service 2. Это временный токен доступа.
• token_type: обычно Bearer, что указывает на способ передачи токена в заголовке Authorization.
• expires_in: время действия токена в секундах (например, 86400 секунд, что соответствует 24 часам). После этого срока действия токен становится недействительным.

Обращение к Service 2 (3). Service 1 использует полученный access_token для отправки запросов к Service 2. Токен передаётся в заголовке Authorization с типом Bearer:

curl --request GET \
--url https://api2.com/api \
--header 'authorization: Bearer ACCESS_TOKEN' \
--header 'content-type: application/json'

Проверка токена (4). Получив запрос с access_token, Service 2 должен убедиться, что токен действителен и не был отозван. Для этого существуют два подхода:

• Запрос к авторизационному серверу: Service 2 может обратиться к авторизационному серверу с помощью протокола, описанного в RFC 7662, чтобы проверить действительность токена. Авторизационный сервер может подтвердить, что токен не истёк и не был отозван.
• Локальная проверка с использованием JWT: Если access_token представлен в виде JWT (JSON Web Token), Service 2 может выполнить локальную проверку токена. JWT содержит в себе закодированную информацию о клиенте и правах доступа, и Service 2 может проверить подпись токена, чтобы убедиться в его подлинности без обращения к авторизационному серверу. Это снижает нагрузку на сервер и ускоряет обработку запросов.

Что такое JWT токен?

Эта статья посвящена детальному разбору JWT и его возможностей. Мы изучим структуру токена и построим его с нуля. Затем рассмотрим наиболее распространенные способы использования.

struchkov.devStruchkov Mark

Когда использовать Client Credentials?

Схема Client Credentials подходит для следующих сценариев:

• Межсерверное взаимодействие, где один сервер должен получить доступ к API другого сервера, например, для синхронизации данных.
• Микросервисная архитектура, где отдельные микросервисы взаимодействуют друг с другом через API.
• Сервисные учётные записи, когда доступ к API требуется не от имени конкретного пользователя, а от имени самого сервиса.

Важно учитывать, что client_secret должен храниться только в безопасных серверных окружениях. Это значит, что клиент должен быть доверительным и иметь возможность безопасно хранить client_secret без риска его утечки. Поэтому Client Credentials не рекомендуется использовать в клиентских приложениях, таких как мобильные или SPA, где client_secret может быть легко извлечён.

Resource Owner Password Credential

Эта схема авторизации является одной из самых простых, но при этом наименее безопасных. В самом стандарте OAuth 2.0 отмечено, что её использование не рекомендуется, и следует прибегать к ней только в том случае, если невозможно реализовать более безопасные схемы авторизации.

Схема Resource Owner Password Credential предполагает передачу пользователем своих учётных данных (логина и пароля) напрямую клиенту, что создаёт значительные риски для безопасности. Этот метод удобен, когда клиент и сервер авторизации находятся под контролем одной организации, однако он крайне уязвим при взаимодействии с третьими сторонами.

1. Передача логина и пароля. Владелец ресурсов (пользователь) передаёт свои логин и пароль клиенту, доверяя ему обработку этих данных. Это предполагает, что клиент является безопасным и не будет злоупотреблять полученными учётными данными.
2. Запрос токена клиентом. Клиент затем отправляет логин и пароль пользователя на авторизационный сервер вместе с client_id и client_secret для аутентификации:

curl -d "grant_type=password" \
    -d "client_id=3MVG9QDx8IKCsXTFM0o9aE3KfEwsZLvRt" \
    -d "client_secret=4826278391389087694" \
    -d "username=ryan%40ryguy.com" \
    -d "password=_userspassword__userssecuritytoken_" \
    https://as.com/oauth2/token

Если авторизационный сервер успешно аутентифицирует учётные данные пользователя, он возвращает access_token, который клиент может использовать для доступа к ресурсам:

{
    "id":"https://as.com/id/00DU0000000Io8rMAC/005U0000000hMDCIA2",
    "issued_at":"1316990706988",
    "instance_url":"https://na12.salesforce.com",
    "signature":"Q2KTt8Ez5dwJ4Adu6QttAhCxbEP3HyfaTUXoNI=",
    "access_token":"00DU0000000Io8r!AQcKbNiJPt0OCSAvxU2SBjVGP6hW0mfmKH07QiPEGIX"
}

Authorization Code Grant

Authorization Code Grant – это рекомендуемый способ авторизации для OAuth 2.0, особенно в тех случаях, когда речь идёт о серверных приложениях. Он обеспечивает высокий уровень безопасности, поскольку позволяет хранить учётные данные клиента и секреты на серверной стороне, недоступной для посторонних.

Этот метод подходит для веб-приложений, где исходный код и секреты клиента остаются скрытыми от пользователей. Исключением для использования этого метода является межсерверное взаимодействие, где больше подходит схема Client Credentials.

Этот способ авторизации включает несколько этапов, обеспечивающих безопасный обмен данными между клиентом и сервером:

Пользователь на сайте нажимает кнопку авторизации (например, «Войти через Facebook»), инициируя процесс получения прав доступа. После этого происходит перенаправление пользователя на страницу авторизационного сервера, где он должен пройти аутентификацию.

Пользователь видит страницу авторизационного сервера:

1. Если у него уже есть активная сессия на авторизационном сервере, то он просто подтверждает своё согласие на предоставление доступа.
2. Если сессии нет, пользователь должен войти в свой аккаунт на авторизационном сервере.

После успешной аутентификации пользователь перенаправляется на URL-адрес, указанный клиентом в параметре redirect_uri. Пример авторизационного запроса выглядит следующим образом:

https://YOUR_DOMAIN/authorize
     ?response_type=code
     &client_id=YOUR_CLIENT_ID
     &redirect_uri=https://YOUR_APP/callback
     &scope=SCOPE
     &audience=API_AUDIENCE
     &state=STATE

• response_type=code – указывает, что авторизационный сервер должен вернуть одноразовый код авторизации.
• redirect_uri – URL-адрес, на который авторизационный сервер перенаправит пользователя после завершения авторизации. Код авторизации будет передан в параметре code. В настройках авторизационного сервера можно указать разрешённые адреса redirect_uri для предотвращения атак на переадресацию (redirect attacks).

Если авторизация прошла успешно, клиент получает код авторизации через HTTP-ответ 302, где в URL содержится параметр code:

HTTP/1.1 302
Found Location: https://YOUR_APP/callback?code=AUTHORIZATION_CODE&state=xyzABC123

После получения кода авторизации, клиент отправляет POST-запрос к авторизационному серверу для обмена кода на access_token и другие токены:

curl --request POST \
    --url 'https://YOUR_DOMAIN/oauth/token' \
    --header 'content-type: application/x-www-form-urlencoded' \
    --data 'grant_type=authorization_code' \
    --data 'client_id=YOUR_CLIENT_ID' \
    --data 'client_secret=YOUR_CLIENT_SECRET' \
    --data 'code=YOUR_AUTHORIZATION_CODE' \
    --data 'redirect_uri=https://YOUR_APP/callback'

Здесь указывается grant_type=authorization_code, который указывает на тип авторизации, и параметры client_id, client_secret, code и redirect_uri для идентификации клиента и подтверждения запроса.

Если обмен прошёл успешно, авторизационный сервер возвращает HTTP-ответ с полезной нагрузкой в формате JSON, содержащей различные токены:

{
    "access_token": "eyJz93a...k4laUWw",
    "refresh_token": "GEbRxBN...edjnXbL",
    "id_token": "eyJ0XAi...4faeEoQ",
    "token_type": "Bearer",
    "expires_in": 3600
}

• access_token – используется для доступа к защищённым ресурсам.
• refresh_token – позволяет запросить новый access_token после его истечения.
• id_token – используется для передачи информации о пользователе (при использовании OpenID Connect).
• expires_in – срок действия access_token в секундах.

После получения access_token клиент может использовать его для авторизации запросов к защищённым API, добавляя токен в заголовок Authorization:

curl --request GET \
    --url https://myapi.com/api \
    --header 'authorization: Bearer ACCESS_TOKEN' \
    --header 'content-type: application/json'

API проверяет подлинность токена и предоставляет доступ к ресурсам в зависимости от разрешений (scope), указанных при запросе авторизации.

Implicit Grant

Implicit Grant предназначен для приложений без серверной части, таких как SPA (Single Page Applications). Этот метод упрощает процесс получения access_token, но делает его менее безопасным по сравнению с другими схемами.

Принцип работы

Пользователь нажимает на кнопку авторизации на сайте (например, «Войти через Google»), что инициирует процесс авторизации. Затем пользователь перенаправляется на страницу авторизационного сервера.

Если у пользователя уже есть активная сессия, он просто подтверждает доступ. В противном случае ему нужно ввести свои логин и пароль на странице авторизационного сервера.

После успешной аутентификации пользователь перенаправляется обратно на сайт клиента, и access_token передаётся в виде фрагмента URL после символа #:

https://domain.com/back_path#access_token=8ijfwWEFFf0wefOofreW6rglk

Хотя access_token передаётся в URL, он остаётся доступен только в браузере и не отправляется на сервер при выполнении HTTP-запросов. Это связано с тем, что фрагмент предназначен исключительно для обработки на стороне клиента. JavaScript в браузере может прочитать фрагмент через window.location.hash и извлечь токен:

const accessToken = window.location.hash.split('=')[1];
fetch('https://api.example.com/data', {
    method: 'GET',
    headers: {
        'Authorization': `Bearer ${accessToken}`
    }
});

Приложение использует этот токен для выполнения защищённых запросов к API, добавляя его в заголовок Authorization. Благодаря использованию HTTPS соединение зашифровано, и сам токен не виден в сети

fetch('https://api.example.com/data', {
    method: 'GET',
    headers: {
        'Authorization': 'Bearer 8ijfwWEFFf0wefOofreW6rglk'
    }
});

Уязвимости передачи токена через URL

Из-за этих рисков использование Implicit Grant рекомендуется ограничивать, особенно в случаях, когда возможна реализация более защищённых методов авторизации

Доступность фрагмента в браузере. Хотя фрагменты URL не передаются на сервер, они доступны в JavaScript. Это делает токен уязвимым для межсайтового скриптинга (XSS), когда злонамеренные скрипты могут извлечь access_token из URL и передать его злоумышленнику

Сохранение в истории браузера и закладках. URL с access_token может быть случайно сохранён в истории браузера или закладках. Это создаёт риск утечки токена, если пользователь случайно поделится таким URL с другими или если на устройстве установлено вредоносное ПО, которое может получить доступ к истории браузера.

Неправильная настройка redirect_uri. Если redirect_uri не проверяется строго и злоумышленник указывает свой собственный URI, он может получить access_token. В этом случае пользователь будет перенаправлен на страницу, контролируемую злоумышленником, с токеном в URL-фрагменте, что позволит злоумышленнику с помощью JavaScript считать этот токен

Проблемы с перенаправлениями (redirects). Если redirect_uri неправильно настроен и не проверяется должным образом, злоумышленники могут подставить собственный URI и перехватить access_token. Это может привести к утечке токена, если сервер авторизации перенаправляет пользователя на контролируемый злоумышленником сайт