Authentication flows

The backend has implemented authentication via OAuth 2, per the backend framework docs.

Flow

The endpoint at /token takes an HTTP form of username & password, checks the combination against what's stored in the database, and returns a JWT if the login was successful. If it wasn't (due to the user not existing or the username+password combo not matching anything), then an HTTP 400 response is generated with an error message.

Once the JWT is received by the client, it should be included in all future calls to authenticated backend endpoints in the Authorization header in the form of Authorization: Bearer <token>. If the client makes a call to an authenticated endpoint and no token is present in the header OR there is a token present but it's invalid, then an HTTP 401 or 403 will be returned by the server.

Password storage

Passwords are stored in a salted and hashed form via the bcrypt library, making knowing what the user originally submitted for their password impossible. This adheres to industry security standards. When a login is attempted, the password from the login form is ran through the same cryptographic functions as the password from signup was, and then checked against the salted+hashed password from the database to check for a match. The password from the database cannot be un-hashed.

Password Reset

Since passwords cannot be known to the server, all password reset forms should require the user to submit a new password. Once the new password has been verified, the password should be sent to the proper user update endpoint to be added to the database. A new password MUST be created and updated to that specific user as it's impossible to retrieve the user's existing password.