Authentication in Software Systems

As we know that, the concept of Authentication is simply identifying an entity (user). So, in a software system how do we manage the process?

There are mainly two strategies and their combination when it comes to authentication

  1. Username and Password (Knowledge-based strategy)
  2. Passwordless (OTP, Login URL) (Possession-based strategy)
  3. Multi-factor (Combination of both, has to provide a password and also OTP)

Authentication can be simplified into 4 parts

  1. Registration or signup
  2. Login or sign in
  3. Manage Session
  4. Logout or signout

1. Registering a user

An authentication service always has to store the Identity. Usually, the user will have a user-id and an internal id saved in the database. During “registration” this data will be obtained from the user and saved in the database.

The user-id can be a username, phone number or email, this identification is always necessary.

1.1 Password based

In password-based systems, the user will be asked to set a password for themselves. Here are the steps behind registration.

  1. Userid and password are obtained from the user via some input interface. (eg: Signup form in websites)
  2. Authentication service receives info and Password is hashed and the hash is saved in databases. Passwords are never to be stored as plain texts nor encrypted but hashed (sort of mixing up with characters in an unrecognizable but reproducible way) and the hash can be saved.
    • If the user enters password secret1234, the Authentication service hashes it using an algorithm and it would look like this $2a$05$b…mHZFpe.
    • These hashes are non-reversible, we can’t compute the value secret1234 from $2a$05$b…mHZFpe (Technically, it’s very hard but not impossible).
    • Also whenever we hash secret1234 it will always result in the same hash $2a$05$b…mHZFpe.
  3. The registration process is technically done, this information will be used to verify the upon logging in later.

1.2 Passwordless

In passwordless systems, the only essential information is an email or phone where the system can send a login URL or OTP (let’s call them token) later. Here, the identity of the user is email or phone number

Only the identity will be stored in the authentication service and the service will send a token that can be used only once. The validation will work as follows,

  1. An identity is given to the system via some input interface.
  2. authentication service stores the identity

That’s all… In addition to that, in password-based systems. it’s also essential to store some kind of contact info (email or phone) to send a password reset token.

Seems like passwordless is a simple and safer solution, right?

2. Login

We have to identify a registered user based on the information we have, Let’s see how it’s done

2.1 Password-based

  1. Combination of identity and password is asked from the user
  2. Authentication service looks up for the corresponding entry of identity and fetches identity and hashed password
  3. The input password(plain text) is hashed using the same algorithm to get the hash string.
  4. The stored hash and the hashed input password will be matched, to see if they are the same.
  5. since the same password will generate an identical hash string, the authentication service can confirm it’s the same password entered by the user as the stored one.

2.2 Passwordless

Identity will be asked from the user, which usually is an email or phone to which the server can send a message which contains OTP or token which would act like a temporary password set by the server for the user.

2.2.3 OTP

  1. The authentication service will generate an OTP, save them along with the user’s identity and sends it to the user’s phone or email and waits for them to enter it back.
  2. Once the user enters the OTP, the service will look up the saved OTP and if it matches, the server will allow access.

2.2.4 Token

  1. Authentication service will generate a token (can say a random text for simplicity) and store it relating it to the user (token would represent the user), and the token will be sent in the form of a login URL mostly via email or SMS. Which might look like this www.example.com/login?token=4AeWnIiPHPOnpoinph.
  2. The token can be used to determine the user in the system, once the user clicks on the login URL the service will identify the user based on the token present on the URL.

The Login process usually opens a session so that users don’t have to identify whenever they access something.

3. Session Management

Once a user has been identified, the system usually establishes a session to indicate that the identity has been verified.

A user’s identity has to be verified upon each action performed to access anything from the system. and it is inconvenient to perform the Login process before every action.

Therefore, a session is established which is generally a token stored at the client (stored in the cookie in web browser systems). There are stateful and stateless (DB Session and JWT) strategies to achieve this.

Which I’ll write about in a separate article

Generally, The server generates a session token which will be validated upon each access attempt from the user instead of asking for login every single time.

4. Logout

Logout is to invalidate a session created after login, it has no effect on the user identity but, the ongoing session after login will be terminated and the user will be asked to log in again once they are logged out to enter the system