Какие методы авторизации используют для построения api

Авторизация в системе через REST API

REST API работает только если при работе с ТСД используется сервер Mobile SMARTS. При прямом подключении ТСД к компьютеру через кабель/крэдл или при обмене с учетной системой через папку использовать REST API не получится.

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

• BASIC авторизация — в этом случае при каждом HTTP-запросе нужно будет отправлять логин и пароль;
• авторизация с использованием токена — при первом HTTP-запросе передаются логин и пароль, а сервер MS возвращается токен — уникальный идентификатор сессии (access token), который при последующих HTTP-запросах можно будет использовать вместо передачи логина и пароля. Срок действия токена (т.е. сессии) ограничен, поэтому для обновления токена при первом запросе сервер Mobile SMARTS дополнительно возвращает «токен обновления» (refresh token) — он нужен для получения нового токена после истечения срока действия текущего токена.

Обратите внимание. Для защиты передаваемых данных рекомендуется использовать режим с включенной аутентификацией и доступом по https.

Для работы через протокол https необходимо указать это в настройках базы данных, для этого зайдите в менеджер базы, справа кнопки «Добавить» нажмите на выпадающий список и выберите пункт «Настройки», далее в окне «Редактирование настроек» поставьте галочку «Использовать http» и нажмите «ОК».

Для работы в режиме с включенной аутентификацией необходимо завести пользователей, задать им логины и пароли. В панели управления Mobile SMARTS узел «Пользователи и группы» содержит данные о пользователях и группах, в которых они состоят.

Инструкция по конфигурации настроек пользователей и групп пользователей, как определить роль пользователей и список типов документов, доступных для обработки пользователям такой группы описана в одноименной статье на сайте.

Пример запроса на авторизацию приложения методом POST

1. Для начала в настройках базы Mobile SMARTS включите авторизацию/аутентификацию по пользователю и нажмите на кнопку «ОК»
2. Пример запроса на авторизацию
   http://localhost:51434/api/v1/session?username=&password=
   в ответ приходит Access_token

Если не указать Authorization, в ответ приходит статус ошибки
401 — Unauthorized

BASIC авторизация

Данный вид авторизации чаще всего используется браузером для доступа к функциям API.

При использовании данного метода необходимо в заголовке каждого запроса указывать:

Authorization: Basic :

Допускается base64 при формировании строки :

Авторизация методом GET

Еще один способ авторизации — отправить GET запрос по адресу /api/v1/session, при этом в url запросе указать параметры login и password:

Ответ сервера:

Access_token:"123123123", Token_type:"bearer", Expires_in:86400, Refresh_token:"321321321",
>

Авторизация методом POST

Авторизация по логину и паролю происходит путем отправки POST запроса на сервер, в результате которого возвращается access_token и refresh token в формате JSON.

Пример запроса:

POST /oauth/token HTTP/1.1
Host: mobilesmarts.ru/api/session
Content-Type: application/x-www-form-urlencoded

Ответ сервера:

Access_token:"123123123",
Token_type:"bearer", Expires_in:86400, Refresh_token:"321321321", >

Восстановление после окончания срока действия сессии

Восстановление после окончания срока действия сессии происходит путем отправки refresh_token на сервер, в результате приходит новый access_token и refresh_token

POST /oauth/token HTTP/1.1
Host: mobilesmarts.ru/api/session
Content-Type: application/x-www-form-urlencoded

HTTP/1.1 200 OK
Content-Type: application/json

Access_token:"99999",
Token_type:"bearer",
Expires_in:86400,
Refresh_token:"789789789",
>

Вызов функций с использованием token

Для того чтобы обратиться к функциям (если не используется Basic авторизация), для которых необходима авторизация, необходимо в заголовке Authorization передавать токен:

Иначе сервер вернет ошибку авторизации 401.

Требования аутентификации и авторизации API

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

Определяем термины

Во-первых, давайте определимся с некоторыми ключевыми терминами:

• Аутентификация: подтверждение правильности личности
• Авторизация: разрешение определенного действия

API может аутентифицировать, но не разрешит делать определенный запрос.

Последствия нехватки безопасности API

Почему даже API-интерфейсы нуждаются в аутентификации? Для API, которые предназначены только для чтения, иногда пользователям не нужны ключи. Но большинство коммерческих API требуют авторизации в виде ключей API или других методов. Если нет никакой защиты API, пользователи могут совершать неограниченное количество запросов API без какой-либо регистрации. Разрешение неограниченных запросов усложнит модель дохода для вашего API.

Вдобавок, без аутентификации не было бы простого способа связать запросы с конкретными данными пользователя. И не было бы способа защиты от запросов от злонамеренных пользователей, которые могут удалить данные другого пользователя (например, путем удаления запросов DELETE для учетной записи другого пользователя).

Наконец, не получится отследить, кто использует API или какие конечные точки используются чаще всего. Очевидно, что разработчики API должны подумать о способах аутентификации и авторизации запросов к своим API.

В целом, аутентификация и авторизация с помощью API служат следующим целям:

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

Разные виды авторизации

Существует несколько методов авторизации. Ниже рассмотрим несколько вариантов авторизации, которые встречаются чаще всего:

API ключ

Большинство API требуют авторизации ключом API, чтобы использовать API. Ключ API представляет собой длинную строку, которую обычно включают либо в URL запроса, либо в заголовок запроса. Ключ API в основном служит способом идентификации лица, выполняющего запрос API (аутентифицируя для использования API). Ключ API также может быть связан с конкретным приложением, которое регистрируется.

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

Basic Auth

Другой тип авторизации называется Basic Auth. С помощью этого метода отправитель помещает пару имя пользователя:пароль в заголовок запроса. Имя пользователя и пароль кодируются с помощью Base64, который представляет собой метод кодирования, который преобразует имя пользователя и пароль в набор из 64 символов для обеспечения безопасной передачи. Вот пример Basic Auth в заголовке запроса:

Authorization: Basic bG9sOnNlY3VyZQ== 

API, использующие Basic Auth, также будут использовать HTTPS, что означает, что содержимое сообщения будет зашифровано в транспортном протоколе HTTP. (Без HTTPS людям было бы легко расшифровать зашифрованные данные)

Когда сервер API получает сообщение, он дешифрует сообщение и проверяет заголовок. После декодирования строки и анализа имени пользователя и пароля он решает, принять или отклонить запрос.

В Postman можно настроить базовую авторизацию, щелкнув вкладку Authorization, выбрав Basic Auth в раскрывающемся списке и введя имя пользователя и пароль справа от двоеточия в каждой строке. На вкладке Заголовки будет показана пара ключ-значение, выглядящая следующим образом:

Authorization: Basic RnJlZDpteXBhc3N3b3Jk 

Postman обрабатывает кодировку Base64 автоматически, при вводе имени пользователя и пароля с выбранным Basic Auth.

HMAC (код авторизации сообщений на основе хэша)

HMAC расшифровывается как Hash-based message authorization code — код авторизации сообщений на основе хэша и является более строгим типом аутентификации, более распространенным в финансовых API. В HMAC только отправитель, и получатель знают секретный ключ, который больше неизвестен никому. Отправитель создает сообщение на основе некоторых системных свойств (например, отметка времени запроса плюс идентификатор учетной записи).

Затем сообщение кодируется секретным ключом и проходит через алгоритм безопасного хеширования (SHA — secure hashing algorithm). (Хеш — это зашифрованная строка на основе алгоритма.) Результирующее значение, называемое сигнатурой, помещается в заголовок запроса.

Сервер API (получатель), получая запрос, принимает те же системные свойства (отметка времени запроса плюс идентификатор учетной записи) и использует секретный ключ (который известен только запрашивающей стороне и серверу API) и SHA для генерации одной и той же строки. Если строка соответствует подписи в заголовке запроса, запрос принимается. Если строки не совпадают, запрос отклоняется.

Вот диаграмма, отображающая процесс авторизации HMAC:

Важным моментом является то, что секретный ключ (критический для восстановления хэша) известен только отправителю и получателю. Секретный ключ не включается в запрос. Безопасность HMAC используется, когда нужно убедиться, что запрос является подлинным и не может быть подделан.

OAuth 2.0

Одним из популярных методов аутентификации и авторизации пользователей является OAuth 2.0. Такой подход опирается на сервер аутентификации для связи с сервером API для предоставления доступа. Понять, что используется метод OAuth 2.0, можно когда предлагается войти в систему при помощи сторонних сервисов, как Twitter, Google или Facebook.

Существует несколько разновидностей OAuth, а именно «one-legged OAuth» и «three-legged OAuth». One-legged OAuth используется, когда нет конфиденциальных данных для защиты. Например, в том случае, если просто получаем общую информацию только для чтения.

Three-legged OAuth используется, когда нужно защитить конфиденциальные данные. В этом сценарии взаимодействуют три группы:

• сервер аутентификации;
• сервер API;
• пользователь или приложение.

Вот базовый процесс Oauth2.0:

Сначала пользовательское приложение отправляет ключ приложения и секретные данные на страницу входа в систему на сервере аутентификации. Если аутентификация пройдена, сервер аутентификации возвращает пользователю токен доступа (авторизации).

Токен доступа (авторизации) упакован в параметр запроса в перенаправлении ответа (302) на запрос. Перенаправление направляет запрос пользователя обратно на сервер ресурсов (сервер API).

Затем пользователь отправляет запрос на сервер ресурсов (сервер API). Токен доступа (авторизации) добавляется в заголовок запроса API со словом Bearer , за которым следует строка токена. Сервер API проверяет токен доступа (авторизации) в запросе пользователя и решает, аутентифицировать ли пользователя.

Токены доступа (авторизации) не только обеспечивают аутентификацию для запрашивающей стороны, но и определяют права пользователя на использование API. Кроме того, токены доступа (авторизации) обычно истекают через некоторое время и требуют от пользователя повторного входа в систему. Для получения дополнительной информации об OAuth 2.0 можно посмотреть ресурсы:

• Learn API Technical Writing 2: REST for Writers (Udemy), Питера Грюнбаума;
• OAuth simplified, Аарона Парецки.

Что документируется в разделе аутентификации

В документации API не нужно подробно объяснять внешним пользователям, как работает аутентификация. Отсутствие объяснений внутренних процессов аутентификации, является лучшей практикой, поскольку хакерам будет сложнее злоупотреблять API.

Тем не менее нужно объяснить необходимую информацию:

• как получить API ключ;
• как пройти аутентификацию запроса;
• сообщения об ошибках, связанных с неверной аутентификацией;
• чувствительность информации аутентификации;
• период действия токена доступа (авторизации).

Если есть открытый и закрытый ключи, нужно объяснить, где следует использовать каждый ключ, и отметить, что закрытые ключи не должны использоваться совместно. Если разные уровни лицензий предоставляют разный доступ к вызовам API, эти уровни лицензирования должны быть явно указаны в разделе авторизации или в другом месте.

Поскольку раздел API ключей важен, и нужен разработчикам до того, как они начнут использовать API, этот раздел должен быть в начале руководства.

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

Twitter

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

Amazon Web Services

Amazon использует HMAC. Процесс достаточно сложный, чтобы включить полноценную диаграмму, показать шаги, которые должны выполнить пользователи.

Dropbox

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

��‍�� Практическое занятие: Авторизация

В своем найденном опен-сорс проекте найдем информацию об авторизации для запросов к API. Ответьте на следующие вопросы:

• Какого рода авторизация требуется для отправки запросов к API?
• Существуют ли разные уровни доступа в рамках авторизации (например, платные и бесплатные), которые определяют, сколько запросов можно сделать или какие типы информации можно получить?
• Можно ли вы получить ключ API или какой-либо другой метод авторизации, необходимый для выполнения тестовых вызовов API?
• Как информация об авторизации интегрируется в раздел “Начало работы”?

Методы REST API сервиса авторизации¶

Подробно о работе с REST API можно почитать в этом разделе. Доступ к REST API сервиса авторизации осуществляется по протоколу HTTPS. Методы, закрытые авторизацией, отмечены значком .

Способы авторизации¶

В зависимости от используемого метода авторизации указываются разные значения для получения доступа к REST API ноды.

• OAuth2 Bearer (apiKey) — значение access токена.
• ApiKey or PrivacyApiKey (apiKey) — значение api-key-hash как для общего доступа к REST API ноды, так и для доступа к методам privacy .

Авторизация по api-key-hash ¶

Генерация значения api-key-hash выполняется при конфигурации ноды . Также получить значение поля rest-api.api-key-hash можно при помощи метода /utils/hash/secure REST API ноды. Для подписания запросов ключем из keystore ноды в поле password запроса POST /transaction/sign требуется указания пароля доступа к keystore.

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'X-API-Key: 1' -d '1' 'http://2.testnet-pos.com:6862/transactions/calculateFee' 

Авторизация по токену¶

Если используется сервис авторизации , для доступа к ноде и другим сервисам клиент получает пару токенов — refresh и access. Токены можно получить через REST API сервиса авторизации.

Для регистрации пользователя используется метод POST ​/v1​/user . На вход передаются следующие параметры:

• login — логин пользователя (электронный адрес пользователя). В качестве логина используется электронный адрес пользователя.
• password — пароль для доступа к аккаунту.
• locale — выбор языка, на котором пользователю будет предоставляться информация на почту. Возможные варианты en и ru.
• source — тип пользователя. Возможные варианты license и voting.

Только после регистрации пользователь получает токены авторизации.

Для получения и обновления токенов авторизации используются следующие методы:

1. POST ​/v1​/auth​/login — получение токена авторизации с использованием логина и пароля. Этот метод предназначен для авторизации пользователей.
2. POST ​/v1​/auth​/token — получение refresh и access токенов авторизации для сервисов и приложений. Метод не требует параметров и в ответ на вызов присылает значения токенов. Метод может быть использовать только администратором сервиса авторизации.
3. POST ​/v1​/auth​/refresh — обновление refresh токена. На вход передаётся значение токена.

Методы сервиса авторизации¶

GET ​/status¶

Получение статуса сервиса авторизации.

Ответ метода

 "status": "string", "version": "string", "commit": "string" > 

POST ​/v1​/user¶

Регистрация нового пользователя.

Запрос метода

 "username": "string", "password": "string", "locale": "string", "source": "string" > 

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

GET ​/v1​/user​/profile ¶

Получение данных пользователя.

Ответ метода

 "id": "string", "name": "string", "locale": "en", "addresses": [ "string" ], "roles": [ "string" ] > 

POST ​/v1​/user​/address ¶

Получение адреса пользователя.

Запрос метода

 "address": "string", "type": "string" > 

Ответ метода

 "addressId": "string" > 

GET /v1​/user​/address​/exists¶

Проверка адреса электронной почты пользователя. В качестве параметра на вход метод принимает электронный адрес пользователя.

Ответ метода

 "exist": true > 

POST ​/v1​/user​/password​/restore¶

Восстановление пароля доступа к аккаунту пользователя.

Запрос метода

 "email": "string", "source": "string" > 

Ответ метода

 "email": "string" > 

POST ​/v1​/user​/password​/reset¶

Сброс пароля пользователя.

Запрос метода

 "token": "string", "password": "string" > 

Ответ метода

 "userId": "string" > 

GET ​/v1​/user​/confirm​/¶

Ввод кода подтверждения для восстановления пароля для доступа к аккаунту пользователя. На вход методу передаётся значение кода подтверждения.

POST ​/v1​/user​/resendEmail¶

Повторная отправка кода восстановления пароля на указанный электронный адрес.

Запрос метода

 "email": "string", "source": "string" > 

Ответ метода

 "email": "string" > 

POST ​/v1​/auth​/login¶

Регистрация нового пользователя в сервисе авторизации.

Запрос метода

 "username": "string", "password": "string", "locale": "string", "source": "string" > 

Ответ метода

 "access_token": "string", "refresh_token": "string", "token_type": "string" > 

POST ​/v1​/auth​/token ¶

Регистрация внешних сервисов и приложений в сервисе авторизации. Метод не требует параметров запроса.

Ответ метода

 "access_token": "string", "refresh_token": "string", "token_type": "string" > 

POST ​/v1​/auth​/refresh¶

Получение нового refresh токена.

Запрос метода

 "token": "string" > 

Ответ метода

 "access_token": "string", "refresh_token": "string", "token_type": "string" > 

GET​ /v1​/auth​/publicKey¶

Получение публичного ключа сервиса авторизации.

Ответ метода

-----BEGIN PUBLIC KEY----- MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7d9Oj/ZQTkkjf4UuMfUu QIFDTYxYf6QBKMVJnq/wXyPYYkV8HVFYFizCaEciv3CXmBH77sXnuTlrEtvK7zHB KvV870HmZuazjIgZVSkOnOY7F8UUVNXnlzVD1dPsOGJ6orM41DnC1W65mCrP3bjn fV4RbmykN/lk7McA6EsMcLEGbKkFhmeq2Nk4hn2CQvoTkupJUnOCP1dhO4bq1lQ7 Ffj9K/FJq73wSXDoH+qqdRG9sfrtgrhtJHerruhv3456e0zyAcDO8+sJUQFKY80B SZMEndVzFS2ub9Q8e7BfcNxTmQPM4PhHO5wuTqL32qt3uJBx2OI4lu3OND44ZrDJ BbVog73oPjRYXj+kTbwUZI66SP4aLcQ8sypQyLwqKk5DtLRozSN0OIrupJJ/pwZs 9zPEggL91T0rirbEhGlf5U8/6XN8GVXX4iMk2fD8FHLFJuXCD7Oj4JC2iWfFDC6a uUkwUfqfjJB8BzIHkncoqOZbpidEE2lTWl+svuEu/wyP5rNlyMiE/e/fZQqM2+o0 cH5Qow6HH35BrloCSZciutUcd1U7YPqESJ5tryy1xn9bsMb+On1ocZTtvec/ow4M RmnJwm0j1nd+cc19OKLG5/boeA+2zqWu0jCbWR9c0oCmgbhuqZCHaHTBEAKDWcsC VRz5qD6FPpePpTQDb6ss3bkCAwEAAQ== -----END PUBLIC KEY----- 

Контроль доступа к API

Летом 2022 года Банк России начал готовить к публикации документ, получивший название «Концепция внедрения Открытых API». Публикация концепции — очередной шаг в последовательном процессе, который регулятор реализует уже несколько лет. Цель мероприятия — распространить новые технологии обслуживания при помощи API на всю банковскую отрасль России.

API. Определение и особенности применения

Открытые API (Open API) — это технология обмена данными между информационными системами разных субъектов коммерческой деятельности по стандартным протоколам взаимодействия. По данным РБК, немалое количество крупных отечественных банков уже обладают опытом успешного внедрения Открытых API в собственные бизнес-процессы.

Однако Open API — лишь частный случай применения API как таковых. Банки и другие финансовые организации уже давно используют API (интерфейсы прикладного программирования) для подключения внешних финтех-приложений и сервисов к своим внутренним программным системам. API помогают реализовать то, что мы называем «цифровыми банковскими услугами»: обработку транзакций, перевод денежных средств, работу с клиентскими счетами, подачу кредитных заявлений и проч.

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

Когда пользователь запрашивает баланс в банковском приложении, оно обращается ко внутреннему API, который, в свою очередь, формирует запрос к автоматизированной банковской системе (АБС) и возвращает ответ клиенту.

В широкой трактовке API позволяет получить доступ к различным программным инструментам, вынести в отдельное приложение функциональность, которую необходимо защитить. Благодаря API те же банки могут связывать отдельные компоненты своей системы между собой. Например, к единой экосистеме можно подключить платежный сервис, функционал обмена межбанковскими документами или настроить аутентификацию в личном кабинете пользователя через социальную сеть.

Требования аутентификации и авторизации API

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

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

Аутентификация API необходима еще и потому, что без защиты интерфейсы могли бы быть вызываемы бесчисленное количество раз, что создавало бы избыточную нагрузку на программную инфраструктуру. То есть программная система не смогла бы связывать запросы пользователей с конкретными данными, не рискуя их скомпрометировать.

Методов аутентификации API-интерфейсов довольно много, но мы остановимся на наиболее часто используемых:

• Базовая аутентификации (Basic Auth)
• С использованием API-ключа
• На основе токенов доступа
• Аутентификация сообщений на основе хэша
• Стандарты OAuth 2.0 и OpenID Connect

Базовая аутентификация — наиболее простая схема, при которой в отправленный на сервер запрос помещаются имя пользователя и пароль. Чтобы передать реквизиты через веб, они преобразуются в кодированный набор 64 символов. Когда сервер API получает сообщение, он декодирует его и сверяет заголовок с сохраненными учетными данными. Расшифровав и проанализировав содержимое строки, он принимает или отклоняет запрос.

Аутентификацию API-ключом использует большинство программных интерфейсов. Ключ — это длинная последовательность уникальных символов, используемая вместо стандартных реквизитов. Как правило, такой ключ размещается в заголовок или в URL запроса и позволяет идентифицировать запрашивающий API субъект. Помимо раздачи ключей, сервер API может также заранее ограничить клиенту доступ к части административных функций.

При построении распределенных систем Single Sign-On (когда один сервис делегирует другому функцию аутентификации пользователя) применяют аутентификацию по токенам. Примером такого способа является вход в приложение при помощи привязанного аккаунта социальной сети. Соцсеть передает достоверные сведения о пользователе в виде токена, который приложение сможет использовать для идентификации, аутентификации и авторизации.

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

Hash-based message authentication code (или HMAC) — тип аутентификации на основе хэша, который часто используется в API организаций, обслуживающих финансовые операции. При использовании этого метода сообщение пропускается через алгоритм безопасного хэширования, затем от хэша вычисляется HMAC-подпись.

В методе HMAC отправитель кодирует сообщение, предназначенное получателю, секретным ключом, который после этого пропускается через алгоритм безопасного хэширования. Значение, полученное на выходе (сигнатура или подпись) помещает в заголовок запроса. Сервер API, зная секретный ключ, принимает подпись и генерирует аналогичную строку. Запрос успешно принимается, если содержимое строки и сигнатуры совпадают.

Стандарт OAuth 2.0 относится к одним из наиболее популярных методов аутентификации и авторизации. Он описывает, каким образом стороннее приложение получает доступ к ресурсам пользователя, благодаря чему тот может «связывать» между собой «клиент» (то есть приложение, которым он пользуется) с сервером API и сервером аутентификации.

Схема работы протокола OAuth 2.0

Сперва пользователь дает «клиенту» (приложению или серверу) разрешение на доступ к своим ресурсам. Приложение отправляет данные на страницу входа в систему на сервере аутентификации. Если все успешно — сервер возвращает пользователю токен доступа. После чего пользователь отправляет на сервер API запрос, в заголовок которого добавлена строка токена. Сервер API проверяет токен и принимает решение об авторизации пользователя.

Стандарт OpenID Connect описывает слой учетных данных, накладываемых поверх OAuth. По этому стандарту сервер аутентификации предоставляет дополнительный токен с набором добавочных полей, содержащих некие сведения о пользователе.

Обеспечение безопасности API-ключей

Поскольку все больше организаций используют API для работы с разными сервисами, а количество обрабатываемых данных постоянно увеличивается, API-интерфейсы все чаще становятся объектами кибератак. Проблема с API заключается в том, что они предоставляют доступ к большим объемам информации, минуя традиционные защитные механизмы веб-браузеров. Недостаточно просто перекрыть XSS-эксплойты и подобрать защиту от встраиваний вредоносного SQL-кода — нужно побеспокоиться о злоумышленниках, которые могут авторизоваться и постранично просматривать пользовательские записи.

Выше мы говорили, что обычно программные интерфейсы защищены API-ключом или требуют аутентификации при помощи токена (например, по стандарту JSON Web Token). На практике таким образом обеспечивается естественная защита API, так как инструменты безопасности могут обнаружить аномальное поведение интерфейса и заблокировать доступ к API-ключу. Тем не менее злоумышленники могут сгенерировать колоссальный набор API¬-ключей, перебирая их подобно тому, как это делают с ID-адресами при совершении DDoS-атак.

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

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

Используя два токена вместо одного, можно дополнительно защитить API-ключ от раскрытия злоумышленником. Такая схема реализована в OAuth 2.0 — где первый токен (Access token) применяется для запроса к серверу. Как правило, он может быть использован несколько раз и имеет небольшой срок действия. Второй токен (Refresh token) — одноразовый и «живет дольше», он используется для обновления истекшего Access token’а.

Преимущество схемы с двумя токенам состоит в том, что сокращается временное окно, в течение которого злоумышленники могут провести успешную кибератаку на сервис и получить к нему доступ.

Применение API Gateway

С ростом количества пользователей и их запросов к какому-либо сервису API-трафик может замедляться. Поэтому в высоконагруженных системах информация перенаправляется в API Gateway — сервис шлюза, который является единой точкой входа для веб-приложений и API. Этот шлюз выполняет разные задачи — от получения и обработки API-запросов до контроля трафика и уровня доступа.

API Gateway устанавливается «на входе» в инфраструктуру организации и выступает в качестве прокси-буфера между пользователями и API-сервисами. Любые наружные запросы к интерфейсам прикладного программирования проходят через этот шлюз, после чего перенаправляются в один из нескольких микросервисов.

Схема работы API Gateway

Сегодня в разработке все чаще используют облачные API Gateway. Наряду со стандартными задачами, они могут реализовывать быстрое масштабирование, создание и публикацию API, отладку API внутренними средствами, мониторинг, а также интеграцию с иными облачными сервисами.

Самые известные облачные платформы по управлению трафиком API:

• Amazon API Gateway
• Azure API Management
• Oracle API Gateway
• Google API Gateway
• Yandex API Gateway и прочие.

Все они обладают схожим набором функций и позволяют предоставлять контролируемый доступ к API, использовать и тестировать различные типы интерфейсов в одном приложении, создавать API-ключи и проч.