Conversation
|
|
||
| ### Exercise (15–20 min) | ||
|
|
||
| - Add a `users` table to the Snippets DB and seed at least one user with a hashed password. |
There was a problem hiding this comment.
Since we are adding users, should we also focus on distinction of authentication and authorization to show that you can log in with one user and not receive information about the other?
|
|
||
| ### Lecture & live coding (≈10 min) | ||
|
|
||
| - Concept: why plaintext passwords are insecure. |
There was a problem hiding this comment.
Should we mention rules for creating strong passwords? Even if the password is hashed, it still can be cracked with the rainbow tables, so maybe it is worth demonstrating why writing "admin" is a bad idea. Perhaps we can show it with a small brute-force script that uses rockyou.txt as an example
| ### Lecture & live coding (≈10 min) | ||
|
|
||
| - Concept: why plaintext passwords are insecure. | ||
| - Introduce hashing and salting with bcrypt. |
There was a problem hiding this comment.
Should we mention different types of hashing and what hashing function is, or it would be a bit too overwhelming?
| ### Lecture & live coding (≈10 min) | ||
|
|
||
| - Concept: server-side sessions, session IDs in cookies, and typical use cases. | ||
| - Contrast with JWT: stateful vs stateless, revocation, and infrastructure needs. |
There was a problem hiding this comment.
Should we probably move session-based before JWT? And also, should we consider showing usage of third-party as a final implementation? (like Firebase or Supabase), showing that we can mitigate so much overhead listed in this module, as they also provide with internal hashing, MFAs, 2-factors etc.
There was a problem hiding this comment.
Regarding third party auth services, we discussed this a lot recently since we are planning projects in all the courses and considering what trainees could/should use.
Currently, in the project we plan for them to do over the same time as this module, they will be implementing auth themselves. We haven't decided yet, but maybe in their final project (at the end of this course) they have the opportunity to use third party services (we have spoken specifically about firebase).
I think it could be a good idea here to introduce the concept of third party auth services, so they know it is possible and exists and what they help with, but i would say very lightly. More so they recognise e.g what firebase is and does for them on a surface level, and something they can go practice/learn more about themselves.
That's my current take, but open to other ideas.
| - JWT-based stateless auth. | ||
| - Session-based auth. | ||
| - Introduce **database-stored tokens**: | ||
| - Tokens stored in a `tokens` table, lookup on each request. |
There was a problem hiding this comment.
If we will be storing tokens in the DB, should we show that they also should be stored in a specific format? Maybe it would be a cool opportunity to show that even tokens should be treated carefully by storing them in simple base64 and perform a token forgery to bypass the route for a specific user (then it will also demonstrate why JWT signed tokes are better format-wise and how 3rd party reduces additional overhead)
| ### Final wrap-up | ||
|
|
||
| - Reiterate best practices: | ||
| - Always use HTTPS. //TODO: WHY and how it's connected |
There was a problem hiding this comment.
Do we explain how https is formed in any of the weeks? Do we need to show that there is a certificate signing going on, or do we simply show that TLS-encrypted traffic is good?
There was a problem hiding this comment.
We touch on https in foundation:
Preparation under "HTTP and everything you need to know about it"
and in the session plan "HTTPS listen, handle request"
3 participants
Closes #276
Initial materials for the node week 3 focusing on authentication of APIs. There is still a bunch of todos and everything needs to be reviewed, also by me, as I used agent to write examples according to my scenarios. There is also a bunch of references to material from week 1 and 2 which is going to be worked on in a separate PR. For detailed information please read the issue linked.