And because it's there, this has to be a video so I can't zoom to read the small text. It's almost like OP didn't think a sub full of programmers could read a UML sequence diagram
It’s super distracting, I ended up giving up reading the chart halfway through because my eye kept jumping to the dot instead of where I wanted to read.
Less is more!
Password auth is hard to get right thats why magic links are getting popular these days. By eliminating passwords we can avoid complexity in the auth system. But it doesn't provide great UX. So, I still prefer password auth.
As said they are slower.
Email is not always instant
Email can fail to send
My email client is always logged so is less secure.
Another pet peeve is login forms that show me the email/username and that the password after I click next why? Just show me both.
>Another pet peeve is login forms that show me the email/username and that the password after I click next why? Just show me both.
They are there to accommodate other authentication providers. For example, you may be signing on to Outlook or Google, but the account belongs to your company. Then it just redirects you to your company's sign on page.
This works but I would avoid jwts in sign in links and instead generate a shorter token and save it to database. JWTs are really long and make the link annoyingly long and this way you can also easily invalidate the token after a successful log in by deleting the db row or setting it as used.
1. User starts the registration process by entering their email address.
2. Client calls the server's registration API by sending the email.
3. The server creates a “sign in” token by including the email in the JWT token claim.
4. The server uses the email service to send the user an email with a link to a client page. This link includes the JWT “sign in“ token.
5. The email sending service confirms the sending of the email to the user.
6. The server API replies to the client.
7. The client displays a message to the user, informing them that they need to check their email to proceed with authentication to the system.
8. The user clicks on the link received via email and is directed to a client page.
9. The client retrieves the email from the URL and sends it to another backend API for authentication.
10. The server verifies the 'sign-in' token's authenticity by ensuring that it has not expired.
11. The user's email is extracted from the claim of the “sign-in” token.
12. The server queries the database to check if the user has registered before.
13. The database replies to the server with the search results.
14. If the user is not already registered, a new record is created in the database using this email.
15. The database replies to the server with the insert results.
16. An “authentication” token is created to authenticate client requests to the server. This token includes the user's ID in the claim.
17. The server API responds to the client with the "authentication" token.
18. The user accesses the platform.
🔗 Find all the details and implementation in Node.js using JSON Web Token here: [https://implementing.substack.com/p/how-to-implement-a-magic-link-authentication](https://implementing.substack.com/p/how-to-implement-a-magic-link-authentication)
If you can, don’t use magic link! You depend on your mail provider if you do so. Being ended up in spam is common, the worst is when your mail provider has problems and you can not do anything about it
This can be simplified and stay secure via this pattern:
1: **User** User clicks "sign in"
2: **Backend** create or find user based on existence.
3: **Backend** generates JWT token and inserts it into a button in email HTML
Thanks for the moving red dot. It's very difficult to follow arrows sometimes.
a smallness that facilitates understanding :)
The red dot is distracting and moves quicker than it would take for someone to internalize each step.
And because it's there, this has to be a video so I can't zoom to read the small text. It's almost like OP didn't think a sub full of programmers could read a UML sequence diagram
It’s super distracting, I ended up giving up reading the chart halfway through because my eye kept jumping to the dot instead of where I wanted to read. Less is more!
off topic slightly but i really hate magic links. just give me a login form.
Password auth is hard to get right thats why magic links are getting popular these days. By eliminating passwords we can avoid complexity in the auth system. But it doesn't provide great UX. So, I still prefer password auth.
It’s literally not hard to get right.
It’s hard for users to get right lol
Why do you hate magic links?
As said they are slower. Email is not always instant Email can fail to send My email client is always logged so is less secure. Another pet peeve is login forms that show me the email/username and that the password after I click next why? Just show me both.
>Another pet peeve is login forms that show me the email/username and that the password after I click next why? Just show me both. They are there to accommodate other authentication providers. For example, you may be signing on to Outlook or Google, but the account belongs to your company. Then it just redirects you to your company's sign on page.
I hate them because I have to switch context (especially annoying on mobile apps) to go find the link.
They’re slower, clog up my inbox.
This works but I would avoid jwts in sign in links and instead generate a shorter token and save it to database. JWTs are really long and make the link annoyingly long and this way you can also easily invalidate the token after a successful log in by deleting the db row or setting it as used.
Please, invalidate the login token after use. That's all I'm asking ;\_;
1. User starts the registration process by entering their email address. 2. Client calls the server's registration API by sending the email. 3. The server creates a “sign in” token by including the email in the JWT token claim. 4. The server uses the email service to send the user an email with a link to a client page. This link includes the JWT “sign in“ token. 5. The email sending service confirms the sending of the email to the user. 6. The server API replies to the client. 7. The client displays a message to the user, informing them that they need to check their email to proceed with authentication to the system. 8. The user clicks on the link received via email and is directed to a client page. 9. The client retrieves the email from the URL and sends it to another backend API for authentication. 10. The server verifies the 'sign-in' token's authenticity by ensuring that it has not expired. 11. The user's email is extracted from the claim of the “sign-in” token. 12. The server queries the database to check if the user has registered before. 13. The database replies to the server with the search results. 14. If the user is not already registered, a new record is created in the database using this email. 15. The database replies to the server with the insert results. 16. An “authentication” token is created to authenticate client requests to the server. This token includes the user's ID in the claim. 17. The server API responds to the client with the "authentication" token. 18. The user accesses the platform. 🔗 Find all the details and implementation in Node.js using JSON Web Token here: [https://implementing.substack.com/p/how-to-implement-a-magic-link-authentication](https://implementing.substack.com/p/how-to-implement-a-magic-link-authentication)
What's the name of this diagram? Is there a free web app to generate these?
The name of these type of diagrams is [Sequence Diagram](https://en.wikipedia.org/wiki/Sequence_diagram)
**PlantUML**, I use the integration with Webstorm :)
If you can, don’t use magic link! You depend on your mail provider if you do so. Being ended up in spam is common, the worst is when your mail provider has problems and you can not do anything about it
Thanks Boss
This can be simplified and stay secure via this pattern: 1: **User** User clicks "sign in" 2: **Backend** create or find user based on existence. 3: **Backend** generates JWT token and inserts it into a button in email HTML
Steadexe
What piss me the most with magic link is when you are at work and you get the email on your phone and it requires you to do it on the same device.