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

medlinx.online работает по стандарту OAuth2 и поддерживает несколько способов авторизации:

• Authorization Code Flow
• Resource Owner Password Flow

Основным способом является Authorization Code Flow.

Для получения каталога исследований используется scope - catalog_service Для доступа к заказам и результатом scope - mis Refresh token приходит в ответ на запрос токена, если один из scope - offline_access

Authorization Code Flow

Основная идея в том, что клиент (клиника) обращается к хранилищу данных (нашему серверу) так, что софт (мис) не имеет информации об учетных данных клиента. Клиент начинает взаимодействие с МИС, далее все происходит ровно так же, как и в Postman - 1. GET запрос к auth endpoint от лица МИС - с указанием данных МИС, после чего возвращается iframe в котором клиент вводит свои данные, потом клиент подтверждает, что этому приложению можно доверять, и в итоге приложение получает токен и рефреш токен. Используя эти два токена, осуществляет взаимодействие без ввода данных клиента.

Можно ли передавать в iframe данные запросом? В webflow - нельзя, но можно использовать refresh_token и один раз получив токен работать с ним практически всегда.

Refresh token приходит в ответ на запрос токена, если один из scope - offline_access.

Работа с двумя токенами хорошо объяснена в статье https://habrahabr.ru/company/Voximplant/blog/323160/ В кратце - запрашиваете access token + refresh token, все запросы выполняете с использованием access. Когда access token заканчивается вы можете получить новый, не указывая данные для авторизации, а указывая refresh token.

Пример

Обратившись к https://auth.medlinx.online/connect/authorize?client_id=***&response_type=code&scope=mis+catalog_service+offline_access&redirect_uri=https://www.getpostman.com/oauth2/callback вы передаете client ID, client secret (данные МИС), в ответ приходит iframe авторизации, куда клиент указывает свои данные для входа, далее происходит подтверждение клиентом что это авторизованное ПО запрашивает токен, а именно известная МИС и МИС получает токены для всех дальнейших взаимодействий.

Тестирование

Для тестирования данные client_id и client_secret приложения (МИС) совпадают с данными клиента (мед. организация), но на прод зоне в рамках взаимодействия по authorization code workflow для OAuth2 для безопасности не рекомендуется (и на данный момент, не поддерживается) хранение данных клиента на стороне МИС. Код из себя не представляет никакой ценности для пользователя, т.к. с его помощью нельзя совершать запросы API и он нужен для одной цели — получения Токена.

Resource Owner Password Flow

Некоторые контрагенты используют Authorization code flow в десктопных приложениях, что не очень удобно для контрагентов, т.к. в десктопных приложениях обычно нет endpoint для callback. Так или иначе, использовать полноценно Authorization code flow не получается.

Для упрощения работы с Identity Server предлагается использовать Resource Owner Password Credentials Grant, хотя это и плохая практика. При использовании данного типа grant для получения access_token достаточно одного POST запроса к Identity Server.