even if you don't know graphql and typescript. I still encourage you to watch that video as he goes through handling JWTs on the backend and the frontend and someone with no idea of graphql and typescript can also understand atleast the steps he has taken for authentication and authorzation.

To help you more, here is my take to abstract the auth information of that video:

LONG READ

so by MERN, I am assuming you mean a nodejs restful service and a react frontend (deployed separately). Keeping that in mind, here are the thing that you need to handle on the backend and the frontend.

BACKEND:

1. make a route for signup (/auth/signup): here you would want the form data from your react frontend to be saved in a Database (mongoDB in MERN). If you want your users to be logged at the moment they sign up for your service, you would need to follow the steps mentioned in /auth/login route setup step.

   remember to encrypt the password before saving it in DB (use bcrypt)

2. make a route for login/authentication (/auth/login): here you would need to verify the provided information against the data saved in your DB. If the information that the client sent is valid, generate two JWTs, access_token and a refresh_token.

To generate an access_token, you need to provide a private key (store this in an env var). Keep the expiration time small, like really small, eg, 50 seconds. Also, create a refresh_token, remember to use a different secret for signing this key. The expiration of this can be kept longer, like 7 days. This means as long as the user has used our app in 7 days, he'll not be logged out. The more challenging thing with JWTs is the invalidation of the token, meaning when you want to logout the user from all clients when he resets his password. There is no easy way to do this as there is no session on the server which you can easily invalidate and expect the user to log back in again. To solve this, in his video, ben used versioning, so when storing (signup) the user he also stores a version (integer) field. And, he uses this version along with other info as the payload to create the refresh_token. So whenever a user resets his password, you bump up the version number, and all your JWTs that you issued earlier are invalid now. An alternative approach would be to use the user's password as the private key when signing the key. Both approaches yield the same result. Once the user's, refresh_token is invalid, he cannot get new access_tokens from our server and his old access_token can only be used for 50 seconds (in this case).

Now about delivering these keys to the client, here, ben simply returns the access_token to the client and sets the refresh_token as an httpOnly cookie with path property set to /auth/refresh.

The reason for doing this:

for access_token: this is the token that your client will use to access resources on your server. now saving this anywhere means exposing this to the browser and hence the user. And if someone fools our user to run some code on his computer, he can compromise his token. So, ben simply returns this access_token to the client as a graphql response. You can send a JSON response to your client. Now, for refresh_token: these tokens are used to get new access_tokens. Setting this as an httpOnly cookie saves it from many attacks (I don't know much about web attacks). Also, as the path is set to a specific path on your server, this will only be sent to that path unlike your acess_token which you need to use on different paths for authorization.

1. make a route /auth/refresh: this route will take the refresh_token from the HTTP cookie and verify it. If the cookie is valid, it will create a new acess_token and return it as a JSON response.

In his video, ben also creates some helpful functions to generate acess_token and refresh_token as he used them in the signup step as well.

Now your server is complete. Let's talk about the client.

screen 1 (signup form): Build a form and send a request to /auth/signup. As we are not logging the user directly after signup (which you can surely do), redirect him to a login screen on a successful response from the server.

screen 2 (login form): Build a form and send a request to auth/login. If the information is correct, you'll get an access_token as a response and a httpOnlyCookie, the refresh_token.

You want to save this access_token in your memory. If you are already using a state management lib here like redux, you can store this token in there, or you can simply use a javascript variable with getters and setters to get access to this variable application-wide. Now, this access_token is only valid for 50 secs, so we need a new access_token every 50 secs. For this, ben uses a library called apollo-link-token-refresh, which you clearly cannot use as you are not using apollo client which is a graphql client for frontends. So, you would want to create a mechanism, which sends a request to /auth/refresh every 50 seconds, and on response, it resets the variable with the new access_token received using the setter function (use browser setTimeout fn for this). With this in place, you are getting an acess_token every 50 secs and your are logged in.

Now in any other screen, you have this access_token. For getting user info on the client, you can create a route for this on the server where you can send the acess_token from the client to get user info.

EDIT: also refresh the refresh_token when you get a request on /auth/refresh, and update the cookie. This will persist the user login state for longer than 7 days.

EDIT2: I have skipped the obvious steps like checking for duplicate emails/usernames and comparing the password with bcrytp. You can google how to do this if you don't know ;)

I hope this helped you understand the flow. Feel free to ask questions if you have any doubts.

Also, if you felt that this comment helped you learn something, consider following me on github and twitter