Призначення та вимоги

1. Генерація токенів доступу у форматі JWT реалізована для зменшення навантаження на службу mithril, яка існує під час будь-якого виклику API eHealth, який використовує заголовок авторизації з токеном доступу.

2. У форматі JWT можна використовувати лише токени доступу, які використовуються для отримання доступу до кінцевих точок електронної охорони здоров’я (наприклад, створення/оновлення запиту особи, створення запиту на декларацію, отримання відомостей про підтвердження особи тощо). Будь-які інші токени, які використовуються в потоці OAuth (тобто авторизаційний_код, refresh_token, session_token), усе ще генеруються в існуючому форматі.

3. Формат створення токену доступу контролюється параметром конфігурації - ACCESS_TOKEN_JWT.

4. Перевірка існуючого формату генерації токену доступу має бути активною та робочою.

5. Токен доступу у форматі JWT містить лише дані, пов’язані з користувачами та клієнтами, дані брокера все ще перевіряються за допомогою перевірки API-ключа через службу Mithril за допомогою існуючого процесу, описаного тут MIS authorization

6. Маркери доступу у форматі JWT не зберігаються в базі даних mithril, оскільки вони перевіряються лише на стороні служби Kong.

Впровадження

Генерація токену доступу в форматі JWT

Наступні методи використовуються для генерації токену доступу для користувача:

https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17599400812

https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17599398735

https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17599398762

https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17599398806

https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17599398851

Методи перевіряють значення конфігураційного параметру ACCESS_TOKEN_JWT:

• true - маркери доступу для користувачів генеруються у форматі JWT;

• false - маркери доступу для користувачів генеруються в непрозорому форматі (захешований рядок запису в базі даних mithril, таблиця tokens).

Відповіді методів для згенерованого токену не змінено, токен усе ще повертається в полі value .

Структура JWT

Токен доступу в форматі JWT складається з трьох закодованих base64 рядків, які розділені символом dot:

• Header

• Payload

• Signature

Хедер

Хедер JWT містить наступні поля:

Сервіс Mithril використовує RS512 JWT алгоритм підпису з типом токену JWT.

Пейлоад

Пейлоад JWT містить наступні поля:

Сервіс Mithril формує поле пейлоад на основі даних, що використовуються для генерації токену (user_id, client_id, перелік запитаних скоупів, токен сессії, etc).

Підпис

Підпис JWT містить підпис вмісту токену з використанням алгоритму, описаного в полі alg із заголовка.

Служба Mithril використовує асиметричний алгоритм підпису – вміст маркера підписується за допомогою закритого ключа, який зберігається в параметрі JWT_PRIVATE_KEY.

Перевірка токену доступу в форматі JWT

Токен доступу у форматі JWT потрібно надіслати в той самий заголовок авторизації для будь-якого методу, який вимагає токен доступу.

Токени доступу у форматі JWT перевіряються лише службою Kong, якщо пройдено всі перевірки токенів – список скоупів з поля scope використовується для перевірки доступу до запитуваного методу.

JWT перевіряється згідно наступних кроків:

1. Перевірити формат заголовку авторизації

   1. якщо токен передається в JWT – перевірити, що це JWT

   2. в іншому випадку – перевірте його за допомогою перевірки існуючого формату токену (згідно перевірки токену методом mithril)

2. Перевірити підпис JWT з публічним ключем, який зберігається в параметрах JWT_PUBLIC_KEY та JWT_PUBLIC_KEY_OLD

   1. в разі, якщо підпис JWT не перевірено по збереженому публічному ключу - повернути 401 ('access_denied')

3. Перевірити строк дії токену по полю exp, що значення більше ніж now()

   1. в разі, якщо поле exp не існує або дата закінчення строку в минулому - повернути 401 ('access_denied')

4. Перевірити, що емітент в полі iss рівний значенню ‘EHeath’

   1. в разі, якщо поле iss не існує або містить будь-які інші дані - повернути 401 ('access_denied')

5. Перевірити, що audience токену з поля aud рівне значенню ‘EHealth’

   1. в разі, якщо поле aud не існує або містить будь-які інші дані - повернути 401 ('access_denied')

6. Перевірити, що токен не входить до чорного списку в базі даних кешу Redis за значеннями полів із пейлоад (jti, sub, client_id):

   1. перевірити, що ключ blacklist_jti_<<jti>> не існує (наприклад, blacklist_jti_481aa86b-7bfa-462c-8bcb-1a9e9edff192);

   2. перевірити, що ключ blacklist_user_id_<<sub>> не існує (наприклад, blacklist_user_id_481aa86b-7bfa-462c-8bcb-1a9e9edff192);

   3. перевірити, що ключ blacklist_client_id_<<client_id>> не існує (наприклад, blacklist_client_id_8a99ffdf-314e-4419-931d-a76f41f8c456);

   4. перевірити, що ключ blacklist_user_id_client_id_<<sub>>_<<client_id>> не існує (напраклад, blacklist_user_id_client_id_481aa86b-7bfa-462c-8bcb-1a9e9edff192_8a99ffdf-314e-4419-931d-a76f41f8c456);

      1. якщо будь-який із ключів існує в базі даних кешу Redis - повернути 401 ('access_denied')

   5. перевірити, що ключ blacklist_app_id_<<app_id>> не існує (для прикладу, blacklist_app_id_ce21628e-317b-4edb-bda6-0de661f24666);

      1. якщо будь-який із ключів існує в базі даних кешу Redis - повернути 401 ('access_denied')