23-29-LS-PRD-1-A

Bay Valley Tech API

Product Requirements Document

Part I
Problem We Are Trying to Solve
Authentication remains to be a cornerstone of digital security, yet many applications and
organizations struggle with the complexities of implementing and managing a secure
authentication platform. Ensuring compatibility across multiple applications and platforms
poses a significant challenge. There is a pressing need for a comprehensive authentication
backend solution that streamlines the authentication process, offering a seamless, secure, and
adaptable solution for applications.

Value Proposition and Marketing Statements

Streamline user authentication across multiple applications with a unified API, providing
seamless, secure access for users while simplifying development and enhancing security
protocols for our entire Bay Valley Tech application ecosystem.

Solution Summary
Create an incredibly simple BaaS offering with a focus on authentication to integrate with all
other Bay Valley Tech projects.
23-29-LS-PRD-1-A

Part II
Functional Requirements
1. This API must accept REST web requests.
2. This API must be hosted on AWS EC2.

Technical Requirements and Constraints

1. Create a database schema.
a. The database engine must be MySQL, running version 5.7.40 (or a later patch
version).
2. Create an `audit` table, with the following columns:
a. `audit_type`
i. The type of audit record, with the following options:
1. `login_failed`
2. `login_successful`
3. `password_reset_requested`
4. `password_reset_requested_user_account_not_found`
5. `password_reset_confirmation_failed`
6. `password_reset_confirmation_successful`
b. `ip_address`
i. The client IP address that initiated the audit.
c. `user_id`
i. Nullable.
3. Create a `user` table, with the following columns:
a. `first_name`
i. The first name of the user.
b. `last_name`
i. The last name of the user.
c. `email_address`
i. The email address of the user, used for authentication.
d. `password`
i. The hashed password of the user, used for authentication.
ii. Do not, under any circumstances, store or log the password in plain text.
e. `mobile_phone_number`
i. The mobile phone number of the user.
f. `mfa_method`
i. The multi-factor authentication method, with the following options:
1. Null
2. SMS
a. This will utilize Twilio’s API / SDK.
3. Email
a. This will utilize Sendgrid’s API / SDK.
23-29-LS-PRD-1-A

g. `staff_flag`
i. A boolean value.
1. `true` if the user is Bay Valley Tech staff.
h. `disable_login_flag`
4. Create a `mfa_code` table, with the following columns:
a. `user_id`
b. `mfa_code`
i. The code sent to the user for MFA.
c. `used_flag`
i. A boolean value.
1. `true` if the MFA code has been consumed by the API.
d. `expiration_date`
i. A datetime value, used to determine if the MFA code has expired.
5. Create `refresh_token` table, with the following columns:
a. `user_id`
b. `token`
i. The refresh token itself.
c. `expiration_date`
i. A datetime value, used to determine if the refresh token has expired.
6. The web API must run on Node, version 18 or greater.
7. Each table should have an `id` column as the primary key of the table.
8. Each table should have an `insert_date` that stores the date and time that a record was
inserted.
9. Each table should have an `insert_user_id` that stores what user inserted a record.
10. Each table should have an `update_date` that stores the date and time that a record
was updated.
11. Each table should have an `update_user_id` that stores what user updated a record.
12. All table and column names should use snake case, i.e., `insert_date`, `insert_user_id`,
etc.
13. All columns must have a comment describing what data that column will store.
14. Create a login API endpoint.
a. URL: /api/auth/login
b. Method: POST
c. Request body:
i. `emailAddress`
1. Required
ii. `password`
1. Required
d. Response payload:
i. If the user does not have MFA enabled:
1. `jwt`
2. `refreshToken`
ii. If the user has MFA enabled, then send an MFA code.
e. Notes:
23-29-LS-PRD-1-A

i. The JWT should be signed with the HS256 algorithm.

ii. The JWT should contain the `iat` and `exp` fields (as part of the JWT
specification).
iii. The JWT should contain a `userId` field.
iv. Ensure that any applicable audit records are logged.
f. Security considerations:
i. The JWT should have an expiration of 1 hour.
ii. The refresh token should have an expiration of 90 days.
iii. Only one refresh token per user can exist.
15. Create an MFA code verification API endpoint.
a. URL: /api/auth/login/mfa
b. Method: POST
c. Request body:
i. `mfaCode`
d. Response payload:
i. `jwt`
ii. `refreshToken`
e. Notes:
i. The JWT should be signed with the HS256 algorithm.
ii. The JWT should contain the `iat` and `exp` fields (as part of the JWT
specification).
iii. The JWT should contain a `userId` field.
iv. Ensure that any applicable audit records are logged.
f. Security considerations:
i. The JWT should have an expiration of 1 hour.
ii. The refresh token should have an expiration of 90 days.
iii. Only one refresh token per user can exist.
iv. MFA codes should not be re-used.
16. Create a password reset request API endpoint.
a. URL: /api/auth/reset-password/request
b. Method: POST
c. Request body:
i. `emailAddress`
d. Response payload:
i. None
e. Notes:
i. Ensure that any applicable audit records are logged.
ii. Send an email to the user with the reset password token.
f. Security considerations:
i. An email will be sent only if a user account exists with that given email
address.
ii. The reset password token must be 255 characters in length.
17. Create a password reset confirmation API endpoint.
a. URL: /api/auth/reset-password/confirm
23-29-LS-PRD-1-A

b. Method: POST
c. Request body:
i. `emailAddress`
ii. `token`
d. Response payload:
i. None
e. Notes:
i. Ensure that any applicable audit records are logged.
f. Security considerations:
i. Ensure that the user is notified that the password associated with their
account has been reset.
18. Create an API endpoint that fetches the logged-in user.
a. This is a protected endpoint; a JWT is required to determine who the user is.
b. URL: /api/auth/self
c. Method: GET
d. Request body:
i. None
e. Response payload:
i. `first_name`
ii. `last_name`
iii. `email_address`
iv. `mobile_phone_number`
v. `mfa_method`
vi. `staff_flag`
vii. `disable_login_flag`
f. Notes:
i. Ensure that any applicable audit records are logged.
g. Security considerations:
i. None
19. Create an API endpoint that updates the logged-in user.
a. This is a protected endpoint; a JWT is required to determine who the user is.
b. URL: /api/auth/self
c. Method: PUT
d. Request body:
i. `first_name`
ii. `last_name`
iii. `email_address`
iv. `mobile_phone_number`
v. `mfa_method`
vi. `staff_flag`
vii. `disable_login_flag`
e. Response payload:
i. None
f. Notes:
23-29-LS-PRD-1-A

i. Ensure that any applicable audit records are logged.

g. Security considerations:
i. Ensure that the user is notified that the password associated with their
account has been reset.
20. Deploy the API to AWS EC2.
a. Use an Ubuntu 20.04 image.
b. Use nginx as the web server engine.
c. Use PM2 to manage the API process.
i. Ensure that the API process automatically restarts if the web server shuts
down or restarts for any reason.

Key Assumptions
• Deploying the API to AWS EC2 assumes that Taylor will be available to help with that
process.
23-29-LS-PRD-1-A

Scope Prioritization
Item MVP MCP Future Constraint/Description

JavaScript / Node SDK Assumed that the implementation is

x
identical for both JavaScript and Node.

.NET SDK x

Rust SDK x

Prevent multiple active If multiple JWTs are generated for a

JWTs for a single user single, revoke all previously-generated
x
JWTs for a single user. Only one JWT
may be active at any given time.

RBAC x

Masquerade feature for Bay

x
Valley Tech staff users

Audit trail search x

Advanced monitoring and

x
performance metrics

Multitenancy and customer All users stored in the database for this
isolation project are assumed to be users of a Bay
x Valley Tech tenant. Multitenancy will
allow multiple applications to integrate
with this API.
23-29-LS-PRD-1-A

Wireframes
None.