Всем привет! Поделюсь с вами знаниями по OAuth для интеграции систем через API. Расскажу вам, как это можно сделать на Python с бэкенд-системами, использующими REST и HL7 FHIR.

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

В этом случае OAuth может стать хорошим выбором. В этой статье показано, как его можно применять в Python при работе с бэкенд-системами, используя REST и HL7 FHIR.

Что бы нам хотелось получить

Допустим, у нас есть типичный вариант интеграции, как показано на схеме ниже:

• Внешние системы и приложения отправляют запрос к интеграционному слоую (Zato), которая, как ожидается, далее запрашивает несколько бэкенд-систем (например, через REST или HL7 FHIR), чтобы затем собрать из полученных данных финальный ответ . Не имеет значения, какую технологию используют клиентские системы, т.е. являются они REST-системами или нет.

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

• Сервер OAuth выдает токены доступа, основанные на времени, которые, подобно куки веб-браузера, являются простыми строками, подтверждающими, что предъявитель токена имеет право делать определенные запросы. Обратите внимание, что токены имеют конкретное время истечения срока действия; например, они становятся недействительными через один час. Также обратите внимание, что Zato хранит токены в неизменном виде, так как они являтся для него непрозрачными строками.

• Когда клиентская система обращается к интеграционному слою, Zatop получает токен от сервера OAuth и сохраняет его во внутреннем кэше. Затем Zato обращается к бэкенд-системам, передавая токен вместе с другими HTTP-заголовками. Каждая вызываемая бэкенд-система будет извлекать токен из входящего запроса и проверять его.

• Zato не имеет никакого представления о том, как именно осуществляется эта проверка, поскольку для него токен – это просто строка. Однако на практике, если токен является самодостаточным (например,  JWT), система может проверить его самостоятельно, а если он не является таковым, система может запросить эндпойнт проверки на сервере OAuth для проверки токена доступа от Zato.

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

• При последующих запросах тот же токен доступа будет повторно использоваться Zato. Однако если срок действия кэшированного токена истечет, Zato запросит новый токен у сервера OAuth — это произойдет незаметно для вызывающего приложения - и обмен сообщениями возобновится.

В терминологии OAuth то, что описано выше, имеет конкретные названия: так, поток сообщений между Zato и сервером OAuth называется «Поток учетных данных клиента», а Zato считается «клиентом» с точки зрения сервера OAuth.

Как это сделать

Настройка OAuth

Сначала нам нужно создать определение безопасности OAuth, которое содержит данные для подключении к серверу OAuth. В данном случае сервером является Okta. Обратите внимание на поле scopes: это список разрешенных действий («scopes»), которые Zato сможет осуществлять.

Список разрешений нужно согласовать с теми, кто отвечает за конфигурацию OAuth-сервера. Если это делаете лично вы, просто убедитесь, что данные на сервере OAuth и в настройках Zato соответствуют друг другу.

Вызов REST

Для вызова служб REST заполните форму, как показано ниже, указав в поле «Security» только что созданное определение OAuth. Этого достаточно, чтобы Zato понял, когда и как получать новые токены от соответствующего OAuth-сервера.

Вот пример кода для вызова бэкенд-системы, использующей REST. Обратите внимание, что мы просто обозначаем соединение по его имени, не заботясь о безопасности. Zato знает, как получать и использовать OAuth-токены по мере необходимости.

Вызов HL7 FHIR

Аналогично REST-эндпойнтам, для вызова серверов по протоколу HL7 FHIR заполните форму, как показано ниже, и в поле "Security" укажите только что созданное значение OAuth. Этого будет достаточно, чтобы Zato знал, когда и как использовать токены, полученные от базового OAuth-сервера.

Вот пример кода для вызова FHIR-сервера. Как и в случае с REST-серверами, обратите внимание, что мы обозначаем соединение только его именем, а Zato позаботится об OAuth.

Что насчет потребителей API?

Один из аспектов, который не был рассмотрен выше, - это взаимодействие с конечными потребителями API. Это было сделано намеренно. Способ обращения к Zato, использование протоколов, механизмов безопасности и формирование ответов на основе входных данных совершенно не зависит от того, как Zato использует OAuth в своем взаимодействии с бэкенд-системами.

Одного от другого никак не зависит: например, клиенты будут использовать Basic Auth, а не OAuth. Или, возможно, клиенты будут использовать AMQP, Odoo, SAP или IBM MQ, без какого-либо HTTP, или, может быть, не будет прямых вызовов API, и то, что мы называем «клиентами», будет на самом деле CSV-файлами в общем каталоге, которые ваши сервисы будут по расписанию периодически собирать. Это неважно, поскольку в любом случае механизм OAuth на бэкенде будет работать автономно.