Authentication
Our Learn website’s authentication functionality works like a highly secured Government office building.
Imagine the main entrance to the building, which is the only way to get inside, is guarded by a security person who checks your ID to verify some information about you, such as:
- Are you on the list of Government contractors who can access this building?
- What specific parts of the building (floors/rooms) do you have access to?
In this scenario, the security person must communicate with a backroom colleague to verify this information.
If you are on the list, the security person will give you a badge to represent that:
- You are allowed inside this building; i.e. you are authorized
- The type of contractor that you are; i.e. which parts do you need to access
#2 is very important because not all contractors are the same, so they need to access different parts of the building depending on their job function, and should be restricted from all other parts.
Also, you must return your badge when you leave for the day; you can't take it home with you.
Now let’s translate this idea to our website!!
Our users enter through the “main entrance”, the Login screen.
Here, the AuthResolver is the security person and will request the user’s Email and Password as their ID, which the user provides through the login form.
The backroom colleague is the AuthService who will perform the actual work of verifying the users information and determining what type of user they are.
Ok, so the website can authorize a user and determine where in the website they may access.
How does the website give the user a “badge” to represent this?
The badge in this case is a JSON Web Token (JWT) which is stored in the user’s web browser’s Local Storage; see below example in Firefox:
The user is now authorized to enter the website and roam around wherever they want.
Well not quite, thinking back to the Government office analogy,
the contractor is authorized to enter the building but they must present their badge when requesting access to specific parts of the building where another security person will verify that they have access.
Our website users will do this too.
When requesting to access or use certain parts of the website, they must present their JWT to the appropriate Resolver, which will again communicate with the appropriate Service.
Finally, the JWT is automatically removed from local storage when the user signs out, and they will need to authenticate again to get back in.
This has just been a basic introduction to Authentication, for deeper knowledge you can look into:
- https://docs.nestjs.com/techniques/authentication
- https://docs.nestjs.com/graphql/quick-start
- https://medium.com/ag-grid/a-plain-english-introduction-to-json-web-tokens-jwt-what-it-is-and-what-it-isnt-8076ca679843
This project is built and maintained by the community of Code Mentoring.
Built by the people, for the people