Renew access token using refresh token

Purpose

This WS is designed to renew access token using refresh token. It is available to renew access token as many time as needed during the lifetime of refresh token

Key points

1. Refresh token must be valid and not revoked

2. User must be active and not black-listed

3. For confidant person it is needed to validate relationship on each refresh

Specification

https://uaehealthapi.docs.apiary.io/#reference/public.-medical-service-provider-integration-layer/oauth/use-refresh-token-for-access-token-extension

Validations

Authorization

• Verify the validity of the refresh token

  • in case of error - return 401 (“Invalid access token”)

• Verify that token is not expired

  • in case of error - return 401 (“Token expired.”)

Validate client

• Check client_id is submitted

  • in case of error - return 422 ('can't be blank')

• Check client_id exists in mithril database

  • in case of error - return 401 ('Invalid client id.')

• Check client_secret is submitted

  • in case of error - return 422 ('can't be blank')

• Check client_secret is valid in accordance to client_id

  • in case of error - return 401 ('Invalid client id or secret.')

Validate refresh token

• Check refresh_token is associated with requested client_id

  • in case of error - return 401 ('Token not found or expired.')

Validate existing approval

• Check that approval exists and is valid for this user and requested client

  • in case of error - return 401 ('Resource owner revoked access for the client.')

Check relationship between patient and confidant person (optional)

This validation must be done only in case when user_id and applicant_user_id are different as it means it is a part of confidant person process. In such case we must ensure that relationship between both this persons still valid

Get person_id from user_id and applicant_person_id from applicant_user_id

Check relationship using Relationship between Confidant Patient and Related Patient validation algorithm and having person_id and applicant_person_id

If scope list in existing approval contains only scopes from env PIS_NOT_VERIFIED_RELATIONSHIP_SCOPES_ALLOWED - check relationship status equals to {:ok, {:approved, "Relationship is approved"}} or {:ok, {:not_approved, "Relationship is not approved yet"}}

If scope list in existing approval contains more scopes than in env PIS_NOT_VERIFIED_RELATIONSHIP_SCOPES_ALLOWED check relationship status equals to {:ok, {:approved, "Relationship is approved"}}

1. If relationship status not confirmed - return 401 ('Can’t confirm relationship')

Service logic

1. Generate new access_token according to the logic, described here Exchange oAuth Code Grant to Access Token