PLAN-001 Users submit their credentials to receive an access token

Description

This test verifies that users can successfully log in and receive an access token with valid credentials, while failing to log in when using invalid credentials.

Minimum equipment

No special hardware or software is required to run this test.

Preconditions

• The entire system (including the reverse proxy, REST API, and all upstream services) is deployed, operational, and accessible online.
• All communications with the REST API are conducted over HTTPS, either through a reverse proxy server or directly with the hosting server.

Input data

Use the following authentication credentials for this test:

• Username: testuser@legit.api
• Password: @634&lMjH52#ipK@

To log in, please send your credentials to the authentication endpoint as Form-data. Use the keys username and password to submit your information. Here’s how you can format your request:

{
    "username": *Your username*,
    "password": *Your password*,
}

Make sure to select Form-data as the type of request body when sending your credentials. This format ensures that your login information is properly received and processed by the endpoint.

Steps

1. Send a POST request to the /login endpoint with the user credentials provided in the test data.
2. Examine the access_token key in the content of the response.
3. Send a POST request to the /login endpoint with invalid user credentials.

Expected outcome

• The REST API returns an access token for valid credentials. A JSON Web Token (JWT) typically appears as a long string composed of three parts separated by dots. For example, a JWT might look like this:

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Impkb2UiLCJleHAiOjE2MzA3OTUwMDAsImlhdCI6MTYzMDc5MTQwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

  The first part is the header, which typically contains the type of token and the signing algorithm. The second part is the payload, which includes the token's claims, such as the user information and expiration time. The third part is the signature, which is used to verify the token's integrity and authenticity.

• The REST API rejects the login attempt with an appropriate error message.

Verifies software requirements

• REQ_005

Risk control for

• 16. An organisation that is not a licensed care provider gets access to the device
• 17. Users outside the inteded user definition use the medical device
• 26. Data breach or unauthorized access

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Tester: JD-017, JD-009, JD-004
• Approver: JD-005