# Demo Script
## First Implementation - Rosário

Our first idea was to have a single authentication process using the SIGARRA's credentials (username and password). Thus giving us the ability to login in our app and in Sigarra at the same time. This would ease work for other groups, as whenever they needed some resource from Sigarra they just needed to use the token returned at the time of login.

However, this implementation changed quickly. As the way we handled login was not secure, passing Sigarra credentials to the backend could lead to some problems.

The main concern is compromising Sigarra account safety if an error occurred on our side.

## JWT - Matos

**What is it?**
“A JSON Web Token is a compact way for securely transmitting information as a JSON object. This information can be verified and trusted because it is digitally signed.”

**How does it work?**
When the user successfully logs in using his credentials, a JSON Web Token, which will work as an access token, will be returned.
This token must then be sent in every subsequent request, and verified by our server, ensuring that only authenticated users can access certain resources.
The JWT is typically sent in the Authorization Header using the Bearer schema, however we decided to also support the use of cookies.

**Why JWT?**
**Advantages:**
- ~~Performance: validating and creating tokens is faster as it doesn't need to consult the database;~~
- Usability: the user doesn't have to worry about sending the email and password on every request;
- Security:
- As the JWT's are signed, only a secret key can be used to generate and validate them. This means that you can be sure that the senders are who they say they are (authenticity) and verify that the content hasn't been tampered with (integrity);
- Expire after defined time.

**Disadvantages:**
- JWTs aren’t easily revocable (logout is not possible) The token can be dropped from the browser, in case of cookies, or from storage, if Bearer schema is used. However, this token would still work if resubmitted, unless other workarounds are used to avoid that (which is the case);
- Security: if the secret key or token is compromised;
- Short Lifespan: may be incovenient for the user.

## How to logout the user - Matos

Since we can't invalidate JWTs before the end of their life, we can't implement the logout functionality. To solve this, we can store the session in a database, so it can be invalidated on the logout. A token is only valid if it is related to a session currently stored in the database. We chose to use Redis due to it's high performance, which makes up for the need to access the database with every request.

## Functionalities - Alexandre

Now we'll very quickly show the component working in the production machine:

We can see that, without being logged in we will receive this message, telling us that we need authentication to access the endpoint
- No authentication - `GET /authentication`
The same will happen if we create a random token
- Random invalid token - `GET /authentication`

- Without parameters - `POST /authentication/register`
- Invalid e-mail - `POST /authentication/register`
- Already registered e-mail - `POST /authentication/register`
- Using a strong password - `POST /authentication/register`

- E-mail not registered - `POST /authentication/login`
- Wrong password - `POST /authentication/login`
- Success - `POST /authentication/login`

- Valid authentication - `GET /authentication`
- Remove cookie and use token - `GET /authentication`

- Logout - `POST /authentication/logout`

- No more valid authentication - `GET /authentication`

- Update this new set password again - `PUT /user/update-password/:id`
There's an alternative that does the same, but without needing the user password, a token is sent to the user's email, and it can be used to update the password in another endpoint.

We also have delete account.

## Middleware - Alexandre

The middleware is equivalent to running the `GET /authentication` before the wanted controller. This allows other routes to add authentication features but not having to worry about them. If the authentication is valid, the controller is called, otherwise, the authentication error will be returned.