ЕСОЗ - публічна документація

RC_warranty_Renew access token using refresh token

Owned by Dmytro Omelchenko (SoE eHealth)
Dec 18, 2024
2 min read

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 patient legal capacity or relationship between patient and confidant person (optional)

This additional validations must be done only for patients token - if person_id exists in token details and is not empty.

Get applicant_person_id from token details, compare it to person_id from token:

  • if equal - check whether person corresponds to following rules:

    • persons age < no_self_registration_age global parameter;

    • persons age between no_self_registration_age and person_full_legal_capacity_age global parameters and person does not have document with type from PIS_PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter;

    • persons age > person_full_legal_capacity_age global parameter and exists at least one active and approved confidant person relationship for person (using following process https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17415995422 with person_id = person_id from token details - expected :ok, :approved response)

      • if person does not correspond to rules - skip validation

      • if person corresponds to rules - check that requested scopes from approval exist in PIS_READ_ONLY_SCOPES_ALLOWED config parameter

        • in case of error - return 422 ('Requested scopes do not match with allowed scopes for the user.')

  • if not equal - get confidant person relationship status using following process https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17415995422 with person_id = person_id and confidant_person_id = applicant_person_id from token details:

    • if process returns :error, :not_found - return 401 ('Can’t confirm relationship')

    • if process returns :ok, :approved - skip validation

    • if process returns :ok, :not_approved - check that requested scopes from approval exist in PIS_NOT_VERIFIED_RELATIONSHIP_SCOPES_ALLOWED config parameter

      • in case of error - return 422 ('Requested scopes do not match with allowed scopes for the user.')

Service logic

  1. Generate new access_token according to the logic, described here https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17599400812

ЕСОЗ - публічна документація