Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • TF_Legit.Health_Plus
    • Legit.Health Plus TF index
    • Legit.Health Plus STED
    • Legit.Health Plus description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File (DHF)
      • Version 1.0.0.0
        • Requirements
          • REQ_001 The user receives quantifiable data on the intensity of clinical signs
          • REQ_002 The user receives quantifiable data on the count of clinical signs
          • REQ_003 The user receives quantifiable data on the extent of clinical signs
          • REQ_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
          • REQ_005 The user can send requests and get back the output of the device as a response in a secure, efficient and versatile manner
          • REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard
          • REQ_007 If something does not work, the API returns meaningful information about the error
          • REQ_008 Notify the user if the image does not represent a skin structure
          • REQ_009 Notify the user if the quality of the image is insufficient
          • REQ_010 The device detects if the image is of clinical or dermatoscopic modality
          • REQ_011 The user specifies the body site of the skin structure
          • REQ_012 Users can easily integrate the device into their system
          • REQ_013 The user receives the pixel coordinates of possible ICD categories
          • ignore-this
            • SWR-001- Users of the REST API can log in and receive an access token
            • SWR-002- The REST API enforces HTTPS for all communications to ensure data security
            • SWR-003- The REST API implements rate limiting to prevent abuse
            • SWR-004- The REST API verifies the access token for every request to secure endpoints
            • SWR-005- Data exchanged with clinical endpoints of the API adhere to the FHIR standard
            • SWR-006- The REST API only accepts and outputs images in Base64 format
            • SWR-007- The diagnosis support service accepts multiple images to deliver more accurate results
            • SWR-008- The user's password is stored in the database as a hashed password
            • SWR-009- New users of the device are only created by an internal user registration service
        • Test plans
        • Test runs
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.0.0.0
  • Requirements
  • ignore-this
  • SWR-004- The REST API verifies the access token for every request to secure endpoints

SWR-004- The REST API verifies the access token for every request to secure endpoints

Internal IDSWR_004
TitleThe REST API verifies the access token for every request to secure endpoints
CategorySECURITY REGULATORY
ImportanceCRITICAL
SystemUser management (API backend)
Editor(s)Alejandro Carmena Magro , JD-017
SupervisorAlfonso Medela , JD-005
Approval
Created at20 Jun 2024

Description​

The REST API must verify the access token for every request made to protected endpoints to ensure that only authenticated and authorized users can access these resources.

Access tokens are generated upon successful authentication and must be included in the header of each request to secure endpoints. The token contains encoded information that allows the server to verify the identity of the requester and their permissions. The verification process involves decoding the token, validating its signature, and checking its expiration date and associated permissions. If the token is missing, invalid, or expired, the API should deny access to the requested resource and return an appropriate error response.

The implementation should follow industry best practices for token-based authentication. This includes using secure algorithms for creating and validating tokens, keeping token lifespans short to minimize misuse, and ensuring strong error handling to prevent information leaks during verification.

Activities generated​

  • Implementation of token verification middleware.
  • Integration with the authentication service to validate tokens.

Implements user needs​

Guarantees the security of user data and operations by permitting access to sensitive endpoints only for authenticated and authorized users.

Regulatory requirements​

4.1: The device shall be compliant with MDR 2017/745, Annex I, point 17.2, 17.4, 18.8, 23.4(ab).

Causes failure modes​

  • Fails to reject expired tokens, allowing users to access resources beyond their allowed time frame.
  • Revoked or blacklisted tokens are still accepted, enabling previously authorized users to keep access even after their permissions have been revoked.
  • An attacker forces the system to use a less secure algorithm for token verification, making it easier to forge tokens. If the API accepts tokens signed with weak algorithms, it becomes vulnerable to forgery.

Tested by software tests​

Implements risk control measures​

  • Unauthorized use of services leading to higher operational costs, as heavy use of cloud resources or frequent API calls can result in substantial charges.

Acceptance criteria​

  • The API denies access to any request with an invalid or missing access token.
  • The API grants access to requests with a valid access token.

Constraints​

  • The system should support various token formats as required by the authentication service.

Dependencies​

  • Integration with the authentication service (e.g., OAuth 2.0 provider).
  • Secure storage of secret keys used for token generation and verification.

Performance considerations​

Token verification should be optimized to ensure minimal impact on response times. Implement caching strategies where appropriate to reduce verification overhead.

Additional notes​

No additional information is required.

Revision history​

VersionDateAuthorDescription
Previous
SWR-003- The REST API implements rate limiting to prevent abuse
Next
SWR-005- Data exchanged with clinical endpoints of the API adhere to the FHIR standard
  • Description
  • Activities generated
  • Implements user needs
  • Regulatory requirements
  • Causes failure modes
  • Tested by software tests
  • Implements risk control measures
  • Acceptance criteria
  • Constraints
  • Dependencies
  • Performance considerations
  • Additional notes
  • Revision history
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)