The Scrummage API

A new API has been developed for Scrummage (Effective Version 2) which currently allows users to read information. The API doesn't currently permit write functionality. This API currently uses JSON Web Tokens (JWTs) for authorisation for the API.

The endpoints are as follows:

• /api/v1/auth (Used to retrieve either an existing or new JSON Web Token.) To authenticate to this the following data needs to be supplied in the body of the POST request:

{
  "Username": "YOUR USERNAME GOES HERE",
  "Password": "YOUR PASSWORD GOES HERE"
}

You can also get your JWT by logging into Scrummage, going to the Account page, and selecting the copy to clipboard icon at the top of the screen, next to "Your API Key".
Following the /api/v1/auth endpoint method, if the authentication is successful, you will receive a JWT in a format similar to below:

{
  "API Key": "YOUR.JWT.TOKEN", 
  "Message": "Registration successful. Welcome [YOUR USERNAME]."
}

For the rest of the endpoints, you will need to supply your JWT using the "Authorization" header in the request as per the following:

Authorization: Bearer YOUR.JWT.TOKEN

• /api/v1/dashboard
• /api/v1/verify_output (Admin users only.)
• /api/v1/task_details
• /api/v1/event_details
• /api/v1/result_details
• /api/v1/account_details (Admin users only.)

Security:
API Security is a fairly young field; however, a few measures have been implemented by design.

JWTs can easily be decoded online without the verification signature (Or API Secret used in the config.json file). Therefore if the information in the JWT is easily exposed this present two issues:
a. If sensitive data is stored in the JWT this can be easily stolen. i.e. Passwords
b. If nothing is added to stop enumeration, i.e. a random and unique field, fields such as user_id could be enumerated allowing end users to enumerate other JWTs simply by changing their user_id.

Therefore all JWT payloads have been structured in the following way.

{'id': 1, 'name': 'admin', 'admin': True, 'time-created': 'Timestamp', 'nonce': 'RANDOM STRING'}

Both the timestamps and the nonce provide randomness to these tokens. Only the encoded JWT is stored in the database. The program finds the user based on the user_id in the JWT (If it can be decoded to begin with), and yes validation rules apply to verify the 'id' field is an integer. Then the JWT stored in the database is retrieved and checked against the supplied JWT. Only if they match will the API permit you the content you requested. Additionally the only information in the JWT that is trusted is the "id" field. The rest simply assist in creating a long and unique JWT. Lastly, the nonce is generated using the secrets python3 library which is considered to be securely random.