What is an Authentication Server

What is an Authentication Server

An authentication server is used to verify credentials when a person or another server needs to prove who they are to an application.

To better understand what an authentication server is, let's look at what it does by taking a peek into what happens when an authentication request is made.

Day in the Life of an Authentication Server

Authentication, in short, is the process of identifying a person or computer to make sure they are who they say they are.

An application or device may ask for several different identifiers to verify this. Each identifier generally falls in one of these three categories:

• Something you know — Usually something like a username and password or PIN. It is the most common identification method.

• Something you have — This covers physical things that you possess, such as a smartphone, key, etc.

• Something you are — This category involves verifying through biometric methods, such as a fingerprint or retinal scan.

There are several different types of authentication, but for brevity, we'll go through what happens in two scenarios: single-factor authentication and multi-factor authentication.

Single-factor authentication

Single-factor authentication is the process of verifying an identity using only one factor. The different factors generally fall into one of the categories above: something you know, something you have, or something you are. The most common form of single-factor authentication is simply a username and password.

Let's look at what happens when a user authenticates with a username and password.

User:Navigates to a website and types in username and password

Authentication Server:

Whoa, what's this? Who are you??

Authentication Server:puts on glasses

Authentication Server:

Ahh yes, bobbysmith3. Let me verify that your secret password is correct. 🧐

User:Waiting

Authentication Server:

I have run my checks, and I can confirm you are indeed bobbysmith3! Welcome!

In this scenario, what was the authentication server checking for when the user entered their username and password? Here's the more in depth flow about what happened behind the scenes while the user was waiting to be authenticated:

• The username and hashed password are sent to the server.
• The server accesses its database of users that holds the username and hashed/salted password.
• It checks the provided username and hashed password against the one in the database.
• If the credentials match, the user's identity is verified, and the application decides what's next.
• If not, a generic error message is returned.

Note: The error message should not reveal too much information about why the request failed. For example, messages such as "This username does not exist" can also be used by an attacker to determine if a username does exist, as they would get a different error message if they try a valid username.

While this may seem like a foolproof method of verifying a user's identity, there's a lot left to be desired. What happens if someone figures out your password?

Over the years, there has been a huge increase in the number of credential stuffing attacks. When a data breach occurs, and usernames/passwords are leaked, they're compiled into huge lists that attackers can use to try to sign into several different websites. Since password reuse is so common, there's a decent chance that some of the usernames and passwords leaked from one application may be valid for another.

“Single-factor authentication just doesn't cut it anymore.”

Tweet This

This is where multi-factor authentication comes into play. Unlike single-factor, which relies on just one form of identification, multi-factor authentication requires more than one identifier to verify a user.

Multi-factor authentication

Let's look at what happens when an authentication request is made using two identification factors.

User:Navigates to a website and types in username and password

Authentication Server:

Ahh, it's you again, bobbysmith3! Let me check that your password matches the one I have on file.

Authentication Server:

Well, it checks out. But I'm still skeptical. I'm sending a code to the phone number I have on file. Please type in the code once you receive it.

User's phone:DING!

User:Receives a text message and types in the code

Authentication Server:

The code matches! Since you have bobbysmith3's password and phone on hand, I'm confident that you are indeed bobbysmith3! Welcome!

One of the most common forms of multi-factor authentication is a username and password combined with something sent to a device or account you own.

For example, you have probably signed into an application with your username and password, and then received a text message or email with a code that you have to provide back to the application to be authenticated. This code is called a one-time password (OTP).

The process for authenticating a user with username/password and an OTP is the same as above, but there's an additional step — the authentication server must send the OTP to the user's registered device and verify that the code is correct.

To do this, the authentication server must perform the following actions:

• Generate the OTP.
• Send it to the application where the user is attempting to sign in.
• Once the application sends the OTP back that the user submitted, verify that it's correct.
• If so, the user is authenticated.
• If not, return an error and allow them to regenerate another OTP. To prevent brute force attacks, there should be a limit to how many times a new OTP can be requested before the user is blocked.

With this additional requirement, an attacker's attempt to fake their identity is greatly stunted! Let's revisit the question that was posed with single-factor username/password authentication.

What happens if someone figures out your password?

In this case, simply having someone's password isn't enough. The attacker must also gain access to the real user's OTP to verify the identity.

As you can see, multi-factor authentication greatly reduces the chances of an attacker impersonating a user.

What an Authentication Server Doesn't Do

An authentication server does a lot of work in the background, but it's also important to understand what it's not responsible for doing.

Authentication vs. authorization

In the examples so far, the authentication server has taken steps to verify a user's identity and return it to the requesting application. What happens next is up to the application.

Once the application knows who the user is, it usually has to decide what the user can access. This is known as authorization.

Authorization — Authorization refers to the process of verifying what a user has access to.

Authentication — Authentication refers to the process of confirming identity.

It's easy to confuse authentication and authorization, but it's important to understand the difference. The authentication process does not determine what a user can access.

“The authentication process does not determine what a user can access.”

Tweet This

The authentication server simply verifies the identity of the user and then passes that information back to the application. The application then uses this identity information to determine what the current user can access.

To manage access control, an authorization server will issue access tokens to the client that lists what permissions the current user has. If you'd like to learn more about access tokens, please check out the free ebook below. It goes in-depth about a popular web token standard, JSON Web Token (JWT).

Interested in getting up-to-speed with JWTs as soon as possible?

Download the free ebook

So even though these two terms have entirely different meanings, the authorization process depends on authentication. Authorization cannot be granted unless the identity of the user is verified.

Because these two processes go hand-in-hand, it's common to see a solution that can handle both ends: authentication and authorization. Auth0, for example, is an all-in-one solution that serves as both an authentication server and an authorization server.

Conclusion

Although the authentication process may seem simple to an end-user, what goes on behind the scenes is very complex. Every time you sign in to a website, there's a lot happening behind the scenes to verify that you are who you say you are.

Hopefully, this article was able to shed a little bit of light on some of the major tasks an authentication server performs, as well as tasks that it isn't responsible for performing.

Thank you for reading and reach out below if you have any questions or if you'd like to learn more about using Auth0 as your authorization and authentication service!