How do you implement authentication, buddy?

Everyone knows about standard user authentication in an application. This is an old-school registration procedure — the user enters a mail address, a password, etc., —and then, upon entering, we compare mail and / or password with the stored data. If matches, give access. But times have changed, and today there are many other authentication methods. If you want to remain a sought-after programmer / developer in this changing, like a kaleidoscope, world of software development, then you should know about all these new methods.

It cannot be denied that in any application and OS authentication is an extremely important element in ensuring the safety of user data and regulating access to information. To understand which authentication method is better for you, you need to understand the advantages and disadvantages of all methods, as well as a good idea of ​​how they work.

Here I will try to talk about the most common authentication methods today. This is not a detailed technical guide, but only a way to introduce you to them. Although the methods are described taking into account the use of the web, these ideas can be implemented in other conditions.

We assume you already know that most of the web / internet is built on the HTTP protocol. You also need to know how web applications work, what user authentication means in an application, and what a client-server architecture is.

Ready? Go.

Session Based Authentication

The HTTP protocol does not track states , and if we authenticate the user with a name and password, our application will not know if this is the same person as in the previous request. We will have to authenticate again. With each HTTP request, it doesn’t know anything about what happened before, it just sends the request. So, if you need personal data, you will have to log in again so that the application knows that this is exactly you. It can be very annoying.

To get rid of this inconvenience, they invented session-based authentication, which they implemented stateful tracking . This means that the authentication record or session must be stored both on the server and on the client. The server must track active sessions in a database or memory, and a cookie is created on the frontend in which the session identifier is stored. This is cookie-based authentication, the most common and widely known method used for a long time.

Session-based authentication procedure:

1. The user enters his name and password in the browser, after which the client application sends a request to the server.
2. The server checks the user, authenticates it, sends a unique user token to the application (storing it in memory or a database).
3. The client application saves tokens in cookies and sends them on every subsequent request.
4. The server receives each request requiring authentication, using a token, authenticates the user and returns the requested data to the client application.
5. When a user logs out, the client application deletes his token, so all subsequent requests from this client become unauthenticated.

This method has several drawbacks.

• Each time a user is authenticated, the server must create an entry. Usually it is stored in memory, and with a large number of users there is a probability of too high load on the server.
• Since sessions are stored in memory, scaling is not so easy. If you repeatedly replicate a server, then all new user sessions will have to be replicated to all new servers. This makes scaling difficult. (I thought this could be avoided if you have a dedicated server for managing sessions, but this is difficult to implement, and it is not always possible.)

Token-based authentication

Token-based authentication has become very popular in recent years due to the proliferation of single-page applications, web APIs and the Internet of things. Most often Json Web Tokens (JWT) are used as tokens. Although implementations are different, JWT tokens have become de facto standard.

Authentication based on tokens does not track state . We will not store user information on the server or in a session, and we will not even store JWT used for clients.

Token-based authentication procedure:

1. User enters name and password.
2. The server checks them and returns a token (JWT), which may contain metadata like user_id, permissions, etc.
3. The token is stored on the client side, most often in the local storage, but it can also be stored in the session or cookie storage.
4. Subsequent requests to the server usually contain this token as an additional authorization header in the form of Bearer {JWT} . Another token can be sent in the body of a POST request, and even as a request parameter.
5. The server decrypts JWT, if the token is valid, the server processes the request.
6. When the user logs out, the token on the client side is destroyed, no need to interact with the server.

More detailed description .

The method has several advantages:

• The main advantage: since the method does not handle states in any way, the server does not need to keep records with user tokens or sessions. Each token is self-sufficient, contains all the data necessary for verification, and also transfers the requested user information. Therefore, tokens do not complicate scaling.
• In cookies, you simply store user session IDs, and JWT allows you to store any type of metadata, if it is valid JSON.
• When using cookies, the backend must perform a search on a traditional SQL database or a NoSQL alternative, and the data exchange probably lasts longer than the decoding of the token. In addition, since you can store additional data such as user permissions inside JWT, you can save additional requests for retrieving and processing data.
  
  Suppose you have an API resource / api / orders, which returns the last orders created by the application, but only users of the admin category can view them. If you use cookies, then by making a request, you generate one call to the database to check the session, another call to get user data and check whether the user is admins, and the third call to get data.
  
  And if you use JWT, you can store the user category already in a token. When the server requests and decrypts it, you can make a single call to the database to get the necessary orders.
• Using cookies on mobile platforms has many limitations and features. And tokens are much easier to implement on iOS and Android. In addition, tokens are easier to implement for applications and services of the Internet of things, which do not provide storage of cookies.

Thanks to all this, token-based authentication is gaining popularity today.

Passwordless authentication

The first reaction to the term “passwordless authentication” can be “How to authenticate someone without a password? Is that possible?"

Our belief is embedded in our heads that passwords are the absolute source of protection for our accounts. But if we look into the matter more deeply, it will become clear that passwordless authentication can be not only secure, but also safer than traditional login by name and password. You may even have heard that passwords are outdated.

Passwordless authentication is a way of configuring the login and authentication of users without entering passwords. The idea is this:

Instead of entering mail / name and password, users enter only their mail. Your application sends a one-time link to this address, the user clicks on it and automatically enters your website / application. For passwordless authentication, the application assumes that a letter has arrived in your inbox with a link if you wrote your own address and not someone else’s address.

There is a similar method in which, instead of a one-time link, a code or a one-time password is sent via SMS. But then you have to combine your application with an SMS service like twilio (and the service is not free). Code or one-time password can also be sent by mail.

And one more, less (so far) popular (and only available on Apple devices) method of passwordless authentication: use Touch ID for fingerprint authentication. Read more about the technology .

If you are using Slack , you might already be faced with passwordless authentication.

Medium provides access to your site only by mail . I recently discovered that Auth0 , or Facebook AccountKit , is a great option for implementing a password-free system for your application.

What can go wrong?

If someone gets access to user mail, he will get access to applications and sites. But it is not your headache - to worry about the security of user email accounts. In addition, if someone gets access to someone else's mail, you can intercept accounts in applications with passwordless authentication using the password recovery function. But we can do nothing with the mail of our users. Let's go further.

What are the advantages?

How often do you use the “forgot password” link to reset the damn password, which you could not remember after several unsuccessful attempts to enter the site / application? We are all in such a situation. You don’t remember all the passwords, especially if you care about security and make a separate password for each site (observing all these “must consist of at least eight characters, contain at least one number, lower case letter and special character”). Password-free authentication will save you from all this. I know you are thinking now: "I use a password manager, idiot." Respect. But do not forget that the vast majority of users are not such technogs as you. This must be taken into account.

Passwordless authentication is good not only for users, but also for you as a developer. You do not need to implement a password recovery mechanism. All win.

If you think that some users prefer an old-fashioned username / password, then give them both options so that they can choose.

Today, passwordless authentication is rapidly gaining popularity.

Single Entry Point (Single Sign On, SSO)

Notice that when you log in to the browser in some Google-service, for example Gmail, and then go to Youtube or another Google-service, do not you have to log in there? You automatically get access to all the services of the company. Impressive, right? After all, although Gmail and Youtube are Google services, they are still separate products. How do they authenticate the user in all products after a single login?

This method is called Single Sign On (SSO).

You can implement it in different ways. For example, use a central service to orchestrate single sign-on between multiple clients. In the case of Google, this service is called Google Accounts . When a user logs in, Google Accounts creates a cookie, which is saved by the user when he walks through the services of the company. How it works:

1. User is a member of one of the Google services.
2. The user gets generated in Google Accounts cuck.
3. The user goes to another Google product.
4. The user is again redirected to Google Accounts.
5. Google Accounts sees that the cookie has already been assigned to the user, and redirects the user to the requested product.

A very simple description of a single entry point: a user logs in once and gets access to all systems without having to log into each of them. This procedure uses three entities that trust a friend directly and indirectly. The user enters a password (or authenticates otherwise) with the identity provider (IDP) to access the service provider (SP). The user trusts the IDP, and the SP trusts the IDP, so the SP can trust the user.

It looks very simple, but specific implementations are very complex. Read more about this authentication method .

Social Network Authentication

I am sure this picture is familiar to everyone:

This is often called social sign-in authentication or social login (Social Login). You can authenticate users by their accounts in social networks. Then users will not have to register separately in your application.

Formally, a social login is not a separate authentication method. This is a kind of single entry point that simplifies the process of user registration / entry into your application.

The best of both worlds

Users can log in to your application with one click, if they have an account in one of the social networks. They do not need to remember logins and passwords. This greatly improves the experience of using your application. As a developer, you do not need to worry about the security of user data and think about checking email addresses - they are already checked by social networks. In addition, social networks already have password recovery mechanisms.

How to use

As a developer, you must understand how this authentication method works. Most social networks use authentication via OAuth2 as the authentication mechanism (some use OAuth1, such as Twitter). Let's understand what OAuth is. A social network is a resource server , your application is a client , and the user trying to enter your application is the owner of the resource . A resource is a user profile / authentication information. When a user wants to log into your application, it redirects the user to the social network for authentication (usually this is a pop-up window with the social network URL). After successful authentication, the user must give your application permission to access their profile from the social network. Then the social network returns the user back to your application, but with an access token. Next time, the application will take this token and request information from the user profile from the social network. This is how OAuth works (for the sake of simplicity, I omitted technical details).

To implement such a mechanism, you may need to register your application in different social networks. You will be given app_id and other keys for configuring connections to social networks. There are also several popular libraries / packages (like Passport , Laravel Socialite , etc.) that will help simplify the procedure and eliminate unnecessary fuss.

Two-factor authentication (2FA)

Two-factor authentication (2FA) improves access security by using two methods (also called factors) of verifying the user's identity. This is a form of multi-factor authentication . Probably, it did not occur to you, but at the ATMs you pass two-factor authentication: the correct information must be recorded on your bank card, and in addition to this you enter the PIN. If someone steals your card, then without a code he will not be able to use it. (Not a fact! - Note. Trans.) That is, in a two-factor authentication system, a user gets access only after providing several separate pieces of information.

Another familiar example is the two-factor authentication of Mail.Ru, Google, Facebook, etc. If this login method is enabled, you first need to enter a login and password, and then a one-time password (verification code) sent via SMS. If your regular password has been compromised, the account will remain protected, because in the second step of the login, the attacker will not be able to enter the required verification code.

Instead of a one-time password, fingerprints or retinal imagery can be used as the second factor.

With two-factor authentication, the user must provide two of the three:

• What you know: password or PIN.
• What you have: a physical device (smartphone) or an application that generates one-time passwords.
• Part of you: a biologically unique property like your fingerprint, voice, or retinal snapshot.

Most hackers hunt for passwords and PIN codes. It is much harder to get access to the token generator or biological properties, so today two-factor provides high security accounts.

So this is a universal solution? Perhaps not .

And yet, two-factor will help strengthen the security of authentication in your application. How to implement? Perhaps you should not ride, but use existing solutions like Auth0 or Duo .

Authentication or authorization?

Some confuse the terms "authentication" and "authorization". These are different things.

• Authentication is the verification of your identity. When you log in to the application with a username and password, you are authenticated.
• Authorization is a check that you have access to something. This may be a set of permissions for some actions. For example, if you created a resource in an application, then you may be the only person allowed to delete this resource (because you are the owner), and other users are not "authorized" for that.

Still here?

Congratulations, you have successfully read a long, tedious and boring article.