Broken authentication is the second-highest security risk for web applications. This usually means that session management and authentication aren't handled correctly. This gives attackers several avenues to get access to data they can use maliciously.
That's why it is important to make sure you get the best practices in place as early in the development process as possible. You can do a few things to make your authentication process more secure and protect your users. We'll go over a few of those things with a quick Node.js app.
First, let's go over some of the different ways you can handle authentication.
Authentication methods
There are a few different types of authentication methods you can choose from: session-based, token-based, and passwordless. Each of these authentication methods has its pros and cons and we'll go over a few of them.
Session-based authentication
This is the most common form of authentication. It only requires a username and password that match what's in a database. If a user enters the correct set of login credentials, they will have a session initialized for them with a specific ID. A session is typically ended when a user logs out of the app.
When sessions are implemented correctly, they will automatically expire after a set amount of time. You'll see this a lot in finance apps, like banking and trading. This gives users an added layer of security in case they've logged into their bank account on a public computer and forgot about that tab.
Token-based authentication
Instead of using actual credentials to authenticate requests, token-based authentication gives users a temporary token that's stored in the browser. This token is typically a JWT (JSON Web Token) that contains all of the information an endpoint will need to validate a user.
Every request that a user makes will include that token. One of the benefits of using a token is that it can have embedded information about what roles and permissions a user might have without fetching that data from a database. This gives attackers less access to critical information, even if they are able to steal a user's token.
Passwordless authentication
This form of authentication is completely different from the others. There is no need for credentials to log in. All you need is an email address or phone number associated with an account and you will get a magic link or one-time password each time you want to log in. As soon as you click the link, you'll get redirected to the app and you'll already be logged in. After that, the magic link isn't valid so no one else can use it.
When the magic link is generated, a JWT is also generated with it. This is how the authentication happens. With this login method, it's a lot harder for attackers to hack their way into your system. There are fewer inputs for them to take advantage of and sending the JWT through the magic link makes them harder to intercept than sending them through a response.
Now that you know about these different authentication methods, let's implement a passwordless authentication model.
Implementing authentication in Node
Passwordless authentication flow
We'll start by going through the process flow of passwordless authentication.
- A user submits their email address or phone number in the web app.
- They are sent a magic link to log in with.
- The user clicks the magic link and they are redirected to the app, already logged in.
Now that we have the flow we need to implement, let's start by making a super basic front-end.
Front-end setup
We don't even need to use a JavaScript framework since the focus is mostly on the back-end. So we'll use some basic HTML and JavaScript to make the front-end.
Here's what the user interface code will be. Just a small HTML file that uses a frontend.js file.
<!DOCTYPE html>
<html>
<head>
<title>Passwordless Authentication</title>
<script src="./frontend.js"></script>
</head>
<body>
<h1>This is where you'll put your email to get a magic link.</h1>
<form>
<div>
<label for="email_address">Enter your email address</label>
<input type="email" id="email_address" />
</div>
<button type="submit" id="submit_email">Get magic link</button>
</form>
</body>
</html>
This is what the frontend.js file will look like.
window.onload = () => {
const submitButton = document.getElementById("submit_email");
const emailInput = document.getElementById("email_address")
submitButton.addEventListener("click", handleAuth);
/** This function submits the request to the server for sending the user a magic link.
* Params: email address
* Returns: message
*/
async function handleAuth() {
const message = await axios.post("http://localhost:4300/login", {
email: emailInput.value
});
return message;
}
};
The JavaScript file gets the submit button we made in the HTML file and adds a click event listener to it. So when the button is clicked, we'll make a POST request to the server we have running on http://localhost:4300 at the login endpoint with the email address entered. Then, if the POST request is successful, we will get a message back we can show to the user.
Back-end setup
Now we're going to start making our Node app. We'll start by making an express app and installing a few packages.
import cors from "cors";
import express from "express";
const PORT = process.env.PORT || 4000;
const app = express();
// Set up middleware
app.use(cors());
app.use(express.json());
app.use(express.urlencoded({ extended: false }));
// Login endpoint
app.post("/login", (req, res) => {
const email = req.body.email;
if (!email) {
res.statusCode(403);
res.send({
message: "There is no email address that matches this.",
});
}
if (email) {
res.statusCode(200);
res.send(email);
}
});
// Start up the server on the port defined in the environment
const server = app.listen(PORT, () => {
console.info("Server running on port " + PORT)
})
export default server
With this basic server in place, we can start adding more functionality. Let's go ahead and add the email service we're going to use. First, add nodemailer to your package.json and then import it.
import nodeMailer from "nodemailer";
Then below the middleware, we'll make a transporter to send emails. This code configures nodemailer and makes the email template with some simple HTML.
// Set up email
const transport = nodeMailer.createTransport({
host: process.env.EMAIL_HOST,
port: 587,
auth: {
user: process.env.EMAIL_USER,
pass: process.env.EMAIL_PASSWORD
}
});
// Make email template for magic link
const emailTemplate = ({ username, link }) => `
<h2>Hey ${username}</h2>
<p>Here's the login link you just requested:</p>
<p>${link}</p>
`
Next, we need to make our token that holds the user's info. This is just an example of some of the basic things you might include in a token. You could also include things like, user permissions, special access keys, and other information that might be used in your app.
// Generate token
const makeToken = (email) => {
const expirationDate = new Date();
expirationDate.setHours(new Date().getHours() + 1);
return jwt.sign({ email, expirationDate }, process.env.JWT_SECRET_KEY);
};
Now we can update the login endpoint to send a magic link to registered users and they'll be logged in to the app as soon as they click it.
// Login endpoint
app.post("/login", (req, res) => {
const { email } = req.body;
if (!email) {
res.status(404);
res.send({
message: "You didn't enter a valid email address.",
});
}
const token = makeToken(email);
const mailOptions = {
from: "You Know",
html: emailTemplate({
email,
link: `http://localhost:8080/account?token=${token}`,
}),
subject: "Your Magic Link",
to: email,
};
return transport.sendMail(mailOptions, (error) => {
if (error) {
res.status(404);
res.send("Can't send email.");
} else {
res.status(200);
res.send(`Magic link sent. : http://localhost:8080/account?token=${token}`);
}
});
});
There are only two more things we need to add to the code to get the server finished. Let's add an account endpoint. Then we'll add a simple authentication method.
// Get account information
app.get("/account", (req, res) => {
isAuthenticated(req, res)
});
This gets the user's token from the front-end and calls the authentication function.
const isAuthenticated = (req, res) => { const { token } = req.query
if (!token) {
res.status(403)
res.send("Can't verify user.")
return
}
let decoded
try {
decoded = jwt.verify(token, process.env.JWT_SECRET_KEY)
}
catch {
res.status(403)
res.send("Invalid auth credentials.")
return
}
if (!decoded.hasOwnProperty("email") || !decoded.hasOwnProperty("expirationDate")) {
res.status(403)
res.send("Invalid auth credentials.")
return
}
const { expirationDate } = decoded
if (expirationDate < new Date()) {
res.status(403)
res.send("Token has expired.")
return
}
res.status(200)
res.send("User has been validated.")
}
This authentication check gets the user's token from the URL query and tries to decode it with the secret that was used to create it. If that fails, it returns an error message to the front-end. If the token is successfully decoded, a few more checks occur and then the user is authenticated and has access to the app!
Best practices for existing authentication systems
Passwordless authentication might not be possible for existing systems, but there are things you can do to make your apps more secure.
- Increase the complexity requirements of passwords.
- Use two-factor authentication.
- Require passwords to be changed after a certain amount of time.
Conclusion
There are a lot of different ways you can implement an authentication system for your app and passwordless is just one of those. Token-based is another commonly used type of authentication and there are plenty of ways to handle this.
Making your own authentication system might take more work than you have time for. There are a lot of existing libraries and services that you can use to integrate authentication in your app. Some of the most commonly used ones are Passport.js and Auth0.
Top comments (37)
Sounds good on paper, but gets infuriatingly impractical very quickly:
Now I have to enter a password anyway, and deal with whatever added security my email account has. What's worse, I now have to input my email password on some random computer (compromised until proven otherwise), instead of a password for some random application I don't even care about. This isn't an improvement in any way.
A better workflow would be:
I realised this the first time I did this myself. So I send both the magic link and an OTP
So the user can enter the Pincode if he/she is in such a situation
OR
The link can just verify the login attempt. After the attempt has been verified then you log the user in on the device he/she initiated the login attempt. You can use sockets to make this happen
How do you go about implementing that last part? Where clicking the magic link on one device logs you in on another?
Not without some degree of back-end persistence, which I assume is the main reason it's not how what the article does. You'd need to create some sort of short-lived state in the back-end that gets cleared by opening a link in the email. The login-window could then just do polling, or use some more sophisticated method for waiting for the server to grant it access.
The only state is in the browser. On the server you just need to verify the token, which could be sent by the browser in the authorization header as a bearer token or in the body or in the url as a parameter or search term. (Sending in URL is an unforced error. It exposes the token, so dont do this in practice.) You should also sign with RSA keys vs secret, so you can verify the origin.
Regarding exposing the token. The magic url, which i hope there's a better term for, can point to a url on the server that returns html where the token and any user data are passed via session storage. It doesnt matter about the nonce. Sincei its now dead.
You say the state is in the browser, but there's not just one browser, but two, and they have no way of directly communicating. Or are you talking about the way it's described in the article?
I just don't open my email on some random computer. That's the whole point: if the default is having to type in the password of your some service on some random computer, suddenly having to instead type in the password to my main email account is not an improvement; it's a reason to stop using that application and look for alternatives.
Just stumped into this somewhat old post while searching one specific thingy around passwordless auth on Google, hence if I found it other users will and I think some points need to be discussed here.
While I understand the points mentioned above my question is... if you don't trust the random computer then why are you using credentials on them?
This leads to some assumptions, like you expecting Apps to trust computers that you don't trust yourself with the "user comfortability" argument.
Some common statements around cyber-security:
Following the rules above, if you had a regular email + password login and the
random computer(or your main computer) is compromised, both your email and password will be leaked in any dump file across the internet, which hackers will use as dictionary to brute-force other Apps programmatically thus generating a somewhat up-to-date map of Apps you use with this email that match the same password, plus the email address will be sold to SPAM scums (which can lead to scams and/or the annoying task of cleaning 50 emails daily).Of course you can point to the argument of "you should never use the same password twice" but this is, in my opinion, the silliest thing after
the password must contain at least 1 uppercase, 1 lowercase, 1 number and 1 special characterwhile being even worse for the UX, because no one will ever remember the exact same password used here or there.We have then few good options:
Best regards
This is almost a year old now, but I randomly stumbled upon this and figured I'd address it, because it's honestly no less relevant now than it was a year ago.
Here's the point:
As a user, one should weigh cybersecurity vs. practicality when using computers. This includes things like re-using the same password for several unimportant services where the risk of having an account stolen is minimal.
I'm not gonna have a unique super-secure password for my grocery list; what's the worst that could happen? A hacker remove orange juice from my list and I have to drink water instead? Yea, not happening.
So when you offer a service like that, you should keep in mind that a user might be okay to log in to your service on, say, a public library computer, but might not be okay with logging in to their main email account on the same computer.
Asking a user to log in to their mail account on the same computer that they want to use a service of much lower cybersecurity relevance is problematic because you're now forcing them to take a much higher risk when all they wanted was to quickly make sure they had "flour" on their shopping list while their phone battery was dead.
Trying to get users to treat each and every online service like it has the same relevance to their online security is a way to get them to be neglectful of online security on all their services, including the ones that really matter.
To update this still-relevant topic, nowadays you have plenty of 2FA solutions that you can get for free (keycloak has built-in OTP thingy, one can self-host a Hanko server and so on and so forth).
Leaving this aside, I understand your points, though the places which allow you to use a computer (library, parlour...) also happen to have USB C, lightning and/or Wireless chargers which might prove more useful than a computer to log on just to check your grocery list (seems quite an unreasonable scenario if you ask me).
Assuming that users would be savvy and aware enough to have categorised apps, each group with its own properly differentiated password... is probably assuming too much. Moreover one would need to assume as well that these users will maintain these categories adequately.
Now imagine a much more plausible scenario; you have multiple bank accounts, one of them is unused since long ago, you have less than 10 bucks there just because you need to be in positive so the bank doesn't shut the account, no movements for the past 14 months, or 35 if you will. It would fall into the "not important" category, right? What can someone do? Stole you 10 bucks? meh...
This bank now decides to launch certain campaigns that raise the interests for storing money there (3.79%) way over what your current savings account offer (2%), so you obviously decide to switch one for the other.
What would an average user do? Simply transfer the funds and call it a day.
I understand that you look at the problem from your prisma and "sigh* it's obvious" runs through your head, but we're a minority, even half of the IT people I know would probably forget or not care enough to change the password!
Luckily banks have tones of obligations and some of these are the number of steps to log in, 2FA, biometrics, session duration and so on, because cybersec, software development and legislators assumed that people will use the same password for both their bank and their 9Gag account.
Being -usually- in the project development side, it's not that I will see any project as being in the "important" category of the people and it's not people what we're trying to safeguard in the first place but the data we are storing, just as a side-effect, one ends up protect people from doing the dumbest shit possible with journeys that involve 2FA in some way or another (not necessarily email) when necessary (and specially in Fintec or anything involving people's money or sensible data).
Lastly as I said before, if one gets a pair of credentials that still work is much easier to find other passwords using different techniques and knowledge. E.g. people usually change just 1 or 2 characters when updating the password, most people's password contain their birth year and son on and so forth. Add OSINT to the equation and you got the combo.
I agree.
I agree that this is a better workflow
Nice article! Leaving about whether this method is safe or not, as already in discussion by our dev members, I want to highlight one thing here.
In
/loginAPI (snippet below), if an email is not found, then we should not tell the user that the email is not in our system. This is a security risk by which a hacker can identify valid emails in a system.Hence,
/loginAPI can just respond with something generic like,You will receive an email with the link if an account is found associated with this email.😁Excellent point to bring up! Same goes for signups. You should always say "You'll receive an email" and for existing emails, simply state that "Someone tried to sign up with us. If that was you - Log in here instead"
That way a malicious user/attacker can't enumerate the existing emails at a large scale
Yeah, I know this is the preferred "safe" response, but can be frustrating when you're "sure" that was the email (I have many) and don't get a response.
I would prefer an email be sent anyway with a message telling me that the email provided wasn't registered so at least I know the process is working.
I don't see a security problem with this approach? Though it may result in an increase of bounced emails from fat fingered entries.
The line 'const email = req.body.email' is related to what the user types in the input element.
The if statement only checks if the value of email is truthy or not. So, only checks if the user typed something on the input element.
if I was a hacker, I should know from the message that my details is not, hence no email with some link.
so to me it's still the same.
I was so hoping this would talk about how to easily integrate WebAuthN, but instead unfortunately, it's sharing more about the bad suggestion of legacy passwordless.
SMS is unsafe, email is vulnerable and provides bad UX. There's way more problems than this, but they've been listed many times before
It is no longer a best practice to force a password change after a period of time. This according to NIST, Microsoft, and the man who suggested the idea in the first place.
See Best practices for existing authentication systems, the paragraph before the conclusion.
The described solution actually introduces attack vectors; what if someone (else) has access to email / phone? They will be able to login.
Someone said "There is a barrier to access a mailbox.".. there is not! If I already have your mailbox then I can get the app "access" if an email is sent for the access... This is a main reason for 2fa and such. (the same goes for phone number).
The only real solution for passwordless (sic) authentication is either an app or a (usb)key. See for example the auth0 implementation for details. (or the MS Authenticator).
The idea of implementing an own authentication layer is outdated anyway.
Why? You do not want a crappy/outdated implementation, that you need to keep updated and secure, to expose your credential data.
Whilst the idea of implementing your own authentication may seem outdated to you, it's
1) always good to understand how the services/libraries you use work behind the scenes
2) important to understand that often you'll require custom solutions and services like Auth0 are very rigid in certain regards
Dangerous.
The attacker steals the mailbox and gets access to all applications/websites.
I think the best way is a custom stateless JWT that contains encrypted userID and timestamp and included in the request as both Cookie and a part of the request body (JSON). The server then compares JWT from Cookie and JSON and if they match -- keeps the user logged in and retrieves needed info from DB with userID.
A fine article, for a topic that is only becoming more popular.
This concept is true for the phone number, but I don't think so with email.
There is a barrier to access a mailbox.
Just a fyi, you're not actually creating the JWT with an expiration date. You're simply encoding the expiration in the payload.
You actually shouldn't be putting any sensitive data in the payload as that data can be publicly seen.
Great article 👍