UA_Renew access token using refresh token

Мета

Цей WS призначений для оновлення токену доступу за допомогою токену оновлення. Токен доступу можна оновлювати стільки разів, скільки потрібно протягом терміну дії токену оновлення.

Ключові положення

1. Токен оновлення має бути дійсним і не відкликаним

2. Користувач має бути активним та не міститись в “чорному списку“

3. Для довіреної особи необхідно підтверджувати взаємозв'язок під час кожного оновлення

Специфікація

Apiary

Перевірки

Авторизація

• Перевірити валідність токену доступу

  • в разі помилки - повернути 401 (“Invalid access token”)

• Перевірити, що токен дійсний

  • в разі помилки - повернути 401 (“Token expired.”)

Перевірити клієнта

• Перевірити, що client_id вказано

  • в разі помилки - повернути 422 ('can't be blank')

• Перевірити, що client_id існує в базі даних mithril

  • в разі помилки - повернути 401 ('Invalid client id.')

• Перевірити, що client_secret вказано

  • в разі помилки - повернути 422 ('can't be blank')

• Перевірити, що client_secret валідний у відповідності до client_id

  • в разі помилки - повернути 401 ('Invalid client id or secret.')

Перевірити токен оновлення

• Перевірити, що refresh_tokenпов'язаний з переданим client_id

  • в разі помилки - повернути 401 ('Token not found or expired.')

Перевірити існуючий апрувал

• Перевірити, що апрувал існує та валідний для існуючого користувача та користувача з запиту

  • в разі помилки - повернути 401 ('Resource owner revoked access for the client.')

Перевірити взаємозв'язок між пацієнтом та довіреною особою (опційно)

Цю перевірку потрібно виконувати лише у випадку, якщо user_id і apply_user_id відрізняються, оскільки це означає, що це частина процесу довіреної особи. У такому випадку ми повинні переконатися, що взаємозв'язок між обома цими особами залишаються дійсними

Отримати person_id з user_id та applicant_person_id з applicant_user_id

Перевірити взаємозв'язок між Relationship between Confidant Patient and Related Patient validation algorithm та наданими person_id та applicant_person_id

1. якщо перелік скоупів в існуючому доступі містить тільки скоупи з env PIS_NOT_VERIFIED_RELATIONSHIP_SCOPES_ALLOWED - перевірити статус взаємозв'язку, що він рівний {:ok, {:approved, "Relationship is approved"}} або {:ok, {:not_approved, "Relationship is not approved yet"}}

2. якщо перелік скоупів в існуючому доступі містить більше скоупів ніж для env PIS_NOT_VERIFIED_RELATIONSHIP_SCOPES_ALLOWED перевірити статус взаємозв'язку, що він рівний {:ok, {:approved, "Relationship is approved"}}

   1. якщо статус взаємозв'язку не погоджений - повернути 401 ('Can’t confirm relationship')

Сервісна логіка

1. Згенерувати новий access_token у відповідності до логіки, описаної тут UA_Exchange oAuth Code Grant to Access Token