[Track 3/7] Login mutation

[taki-tiler-server[bot]]

In this track, you will implement a login mutation fully integrated with the database. There are many ways of implementing an authentication. The way we're doing it is: the user sends a password to prove that he is who he claims, and then the server provides a token that allows him to access some data on future requests. This token generally have an expiration, after which the user has to login again to get a new one.

Step 1/4 - The mutation setup

Estimated time: 1 hour

Let's start with baby steps, by creating the mutation prototype, with no integration with the dabatase (yet).

Let's call the mutation Login. It should receive an e-mail and a password as parameters and return the following structure on body:

{
  "data": {
    "Login": {
      "user": {
        "id": "12",
        "name": "User Name",
        "email": "User e-mail",
        "birthDate": "04-25-1990",
        "cpf": "XXXXXXXXXXX",
      },
      "token": "the_token"
    }
  } 
}

Your User can have other information if you want, but these fields above should be enough.

Note: Did you notice that there is a data object wrapping the Login response? Don't worry, it's the GraphQL response format. It wraps all the successful response data inside the data object and all the errors in an errors array of objects. You can read more about it here.

For now, you can return the above structure populated with some mock data.

[hmartinsc]

next

[taki-tiler-server[bot]]

Step 2/4 - Integrating with the database

Estimated time: 3 hours

Now you're going to fully integrate the Login mutation with the database. Since we don't have a mutation to create users (yet), we should create one directly on the database, so we have the conditions to test it properly.

NOTE: One of the required data to create a user is the password. You should have read or heard already that storing users password as plain text in the database is a bad idea. If not, you're reading now: it is a bad idea 🤦‍. The minimum security we should have on this case is to use a hash algorithm to store the password. This is not a 100% secure method, but it helps already. Interested in this security matter? Check this post for additional details. Since this is only an onboard server, you don't need to have a ultra-master-blaster security method. Our main goal here is to show you some levels of security and prevent you from beginning your projects with an ultra-master-blaster insecure method.

After creating a user, you should implement your mutation as follows:

1. Get the input e-mail received on the mutation and try to find one on database.
2. Check if the given password is correct. Remember that, in order to comapre them properly, the input password should be submitted to the same process of transformation that the ones stored on Database.
3. If everything is right, return the user info and a token. For now, the token can be only an empty string. You're going to implement it on next step.

On each of these steps, some error may occur. It's important in these cases to provide a good description to the client of what went wrong. For example, if the password is wrong, you could return an error message like Invalid credentials, please check your e-mail and password.

[hmartinsc]

next

[taki-tiler-server[bot]]

Step 3/4 - The token

Estimated time: 2 hours

Now you're going to finish your Login mutation returning a proper token instead of an empty string. Take a look at an example of the token you're going to implement:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

This may look like a random string, but this token has a lot of power, because there are some information encoded on it. The server can know only with a token, for example:

1. When it was created
2. When it expires
3. Which user is sending

This is an example of the famous JWT token. You're going to build these tokens and return on your mutation. This link has some information about token based authentication, jwt tokens and an example of how to implement it on code.

Your task now is to implement a model of JWT tokens for your server and return them on your Login mutation.

[hmartinsc]

next

[taki-tiler-server[bot]]

Step 4/4 - Challenge: the token duration

Estimated time: 2 hours

NOTE: some steps on this onboard are classified as "challenges". They are meant to be some additional tasks that add some bonus features, but are not necessarily core of the server. Try not to loose too much time on them 🙃

After implementing the login, you must have noticed that one of the possible parameters for creating a JWT token is the expiration. This parameter allows us set an expiration timestamp coded on the token. The challenge consists of:

1. Adding an aditional optional parameter on the Login mutation called rememberMe. It's a boolean.
2. If rememberMe was sent and its value is true, you should increase the expiration of the returned token. 1 week is good for the context.

[hmartinsc]

next

[taki-tiler-server[bot]]

Click here for your next track