Hello there 👋 In this article, we will go through the basics of Auth, outline the pros and cons of each type, and how to decide on an Auth solution based on your system requirements.

• I- Basic Auth flow explained
• II- Authentication
  • Stateful Authentication
    • Pros
    • Cons
  • Stateless Authentication
    • Pros
    • Cons
• III- Authorization
  • Role Based Access Control (RBAC)
    • Pros
    • Cons
  • Attribute Based Access Control (ABAC)
    • Pros
    • Cons
  • Discretionary Access Control (DAC)
    • Pros
    • Cons
• IV- How to choose your Auth solution
  • Authentication
  • Authorization
• V- Conclusion

I- Basic Auth flow explained

To protect business resources in any system, there are two fundamental building layers that protect access to such resources: Authentication and Authorization. The following diagram illustrates how a basic Auth flow works:

• Authentication: this layer is responsible for checking if the requesting user is part of the system, nothing more nothing less. This can be done in endless ways, typically by providing a username and a password to verify the user's identity. If the user has been logged in previously, the authentication layer might have issued an "access token" for the user to use for subsequent requests to avoid sending the username/password with each request.

• Authorization: this layer is responsible for checking if the requesting user has access to the business resource. Authorization assumes that the user has been already authenticated and is part of the system. There are many ways to authorize the user's permissions, which we will talk about later.

Essentially, on each client request, the request has to go through both layers in order before granted access to the said resource. Let's dive deeper into how each of these layers work.

II- Authentication

In essence, authentication can be classified into two different categories: Stateful and Stateless.

Stateful Authentication

In this authentication model, once the user provides valid login credentials, the authentication layer creates a new session for the requesting user and stores the session data on the server side. Subsequently, the authentication layer returns a "Session ID" for the client to use for any subsequent request. Essentially, with each client request, the authentication layer fetches the session details for the corresponding session ID and validates it. The following diagram outlines a stateful authentication flow, assuming the user has been previously logged in:

Pros

• Server-side control: a user session is entirely managed/controlled by the backend, which gives the ability for the admins to revoke access on demand.

• Easier to mitigate security breaches: if a session ID was compromised by any means, it is easy to revoke the session from the server-side to deny access entirely.

Cons

• Database read with each request: since it is required to fetch the session data with each request, additional latency and complexity might be introduced to the system.

• Scalability: as mentioned previously, each request maps to one database read operation, which accumulates additional operational costs. Assume we have thousands of requests coming into the system each minute, it would be complex to scale this solution with reasonable costs.

Stateless Authentication

Unlike stateful authentication, stateless authentication does not store any session data on the server side, and validates the user request on the fly. This is typically done using the following methodology; once the user provides valid login credentials, the authentication layer issues a signed "access token" (using a secret key only known to the server) and returns it to the client. The client then uses this token to make subsequent requests to the system. The token signature is validated on the fly by the server on each request, eliminating the need to store additional session data. The following diagram outlines a typical stateless authentication flow, assuming the user has been previously logged in:

In essence, an access token may include the following data:

• non-confidential user information
• token expiry date/time
• token signature and signing algorithm

There are various stateless authentication implementations out there, including JSON Web Token (JWT) and Platform Agnostic Security Tokens (PASETO).

Pros

• No session data stored: an access token is validated on the fly, which saves us from storing any additional session data on the server side. This dramatically cuts the storage costs and does not introduce the database latency to our system.

• Scalability: Eliminating the need for a database read on each request allows for better scalability, and enables you to integrate with third party identity providers in your system with ease.

Cons

• No way to revoke access on demand: the server does not keep any session information to be able to keep track of the currently logged in users. As long as the client provides a valid token, there's virtually no way to revoke the user's access to the protected resources, unless you change the token signature key. This makes it hard for admins to manage and monitor the currently logged in users.

• Potential security breaches: if an access token of a certain user has been somehow leaked or compromised, there's no way you could revoke the user's access to the protected resources. One way to work around this issue is to set a short expiry date on the issued tokens, but that does not solve the problem entirely.

III- Authorization

As previously mentioned, authorization is the process of identifying the requesting user's permissions and validating whether the user has the required permissions to access the target business resource. Authorization comes in many shapes and forms, and we'll talk about a few of them in this section.

Role Based Access Control (RBAC)

Role based access control, or RBAC for short, is one of the most popular and versatile authorization frameworks that allows you to map system users to one or many organizational roles. In RBAC, you create a role, or a set of roles, that govern one or more granular permissions to guard access to resources. There are four main entities that are always present in an RBAC environment:

• User: this is the entity that describes a unique user in a given system.

• Permission: is the lowest level of access control that describes an action that can be done over a resource in a system.

• Role: is an entity that governs a collection of permissions, in addition to other meta-data.

• Role assignment: is an entity that describes the mapping between a system user and an organizational role. This may be present as a part of the issued access token, or explicitly defined in the system's database.

RBAC is a purely additive system, meaning that we assume that a user does not have any permissions to access resources unless explicitly defined in a role assignment. It is always a best practice to assign the minimum required permissions to a certain user to avoid any malicious activities in your system.

Pros

• re-usability: RBAC allows you to define a role and assign it to as many as users as you want, increasing the role's resuability and modularity. For instance, if you want to give the bare minimum permissions to the new users in your system, you can create a single "guest" role that governs the common permissions for these users and assign it to them on demand.

• Ease of auditing and management: RBAC allows admins to easily add, remove and change the users' permissions on demand by adding or removing the corresponding role assignments. It also makes it easy to tackle any security related issues, since each role assignment governs a set of well-defined roles.

• Simple computational model: RBAC is only concerned with the fact that if the requesting user has the sufficient permissions to access the target resource or not. This increases your system scalability and heavily cuts down on the computation costs.

Cons

• Role explosions: since RBAC allows you to create as many roles as you want, you can end up creating an infinite number of roles, possibly duplicates, which will inevitably clutter your system and may introduce orphan roles.

• God role: if you're not highly cautious about the granularity and modularity of your roles, you might end up creating multiple "god roles" which contain a lot of uneeded permissions, introducing more security issues to your system.

• RBAC is static: RBAC does not care about the actual content or meta data (ex: creation date, number of records, etc.) of your business resources, which makes it hard to map between your organizational needs and the implemented RBAC roles.

Attribute Based Access Control (ABAC)

rather than evaluating roles like RBAC, Attribute Based Access Control (ABAC) is a model that assesses attributes to grant access to the system resources. Attributes may include resource creation date, file owner, file ID, etc. ABAC runs a series of evaluation statements on the user's request to determine whether to allow access or not. All evaluation statements in an ABAC logic must return true in order to grant access to the target resource. There are four main entities that are present in an ABAC system:

• User: this is the entity that describes and governs a set of attributes for a unique user in a given system.

• Resource: an entity that holds the asset that the user wants to access. Resources may contain certain attributes such as creation date, owner, size, modification date, etc.

• Request/Action: an entity that describes the intention of the user in a given system. For instance, a user may want read content from a specific resource, or write some data to another resource.

• Environment: an entity that describes the setting at which the request/action is taking place. An environment may contain certain attributes such as current date/time, system uptime, current number of concurrent users, etc.

ABAC gives more control over the authorization process, and confines the auth logic in one place.

Pros

• Dynamic authorization: ABAC allows you to evaluate the user's access level at runtime, giving you more control over the authorization process.

• Encapsulated authorization logic: ABAC allows you to confine most of the authorization logic in one place, making it easier for developers to append and maintain security rules.

• Fine grained access control: since ABAC operates over attributes & characteristics, it makes it easier to map the user's access level to suit the organizational needs.

Cons

• Complex computations: ABAC logic can get complex at times, which might introduce some latency into your system, as well as increase the operational costs.

• Hard to audit: since ABAC is dynamic and encapsulates the auth logic behind a black box, it is hard for IT & admins to audit the permissions of each user in the system.

Discretionary Access Control (DAC)

Discretionary Access Control, or DAC for short, is a simple model that determines access control via policies set by the resource's owner. Essentially, each resource has an owner, usually the initial creator, that has the power to determine the access level of other users, and has the ability to transfer ownership to other users. DAC is fairly simple to implement, and does not have a lot of complexity in its core. There are four main entities that are present in a DAC system:

• User: is an entity that describes a unique user in a given system.

• Owner: is an entity that describes an owner of a specific resource.

• Resource: an entity that holds the asset that the user wants to access.

• access policies: an entity that describes the rules that determines which user has access (read, write, etc.) to the resource, which is set by the owner.

Pros

• Easy to implement: compared to RBAC and ABAC, DAC is really easy to implement and does not imply any complex computations under the hood.

• Minimizes administration activities: since access control is purely managed by resource owners, the administration workload is divided upon multiple users, making it easier to maintain the system.

Cons

• No centralized management: since each resource is managed by an owner, DAC implies a decentralized management approach by design. This might make it hard to audit and monitor the system from a security perspective.

• Less secure: since resource owners have the ability to give other users access, and as more owners are introduced to the system, data can be easily mishandled and possibly leaked outside of the organization.

IV- How to choose your Auth solution

when it comes to choosing an Auth solution for your application, it might be tricky to determine the best Auth combination based on your system's requirements. The following series of questions should help you decide on an Auth solution that best fits your needs.

Authentication

• Do you expect alot of concurrent users in your system?

  • YES: stateless
  • NO: stateful

• Does your system require low latency and high throughput?

  • YES: stateless
  • NO: stateful

• Do you want more control over the current user's sessions?

  • YES: stateful
  • NO: stateless

• Do you care about the scalability of your system?

  • YES: stateless
  • NO: stateful

• Does your system operate in an hostile environment where you need to revoke user access frequently?

  • YES: stateful
  • NO: stateless

• Do you want to easily integrate with third party identity providers?

  • YES: stateless
  • NO: stateful

• Do you care about the complexity of logic in your server?

  • YES: stateless
  • NO: stateful

Authorization

• Do you want to give your users the ability to manage their own resources?

  • YES: DAC
  • NO: ABAC or RBAC

• Does your system have complex access control requirements?

  • YES: ABAC
  • NO: RBAC or DAC

• Should your access control system have a similar hierarchy to your organizational roles?

  • YES: RBAC
  • NO: ABAC or DAC

• Do you want to be able to control access to resources based on runtime attributes?

  • YES: ABAC
  • NO: RBAC or DAC

• Do you want a simple access control solution that does not contain complex logic?

  • YES: RBAC or DAC
  • NO: ABAC

• Do you care about access control auditing and monitoring?

  • YES: RBAC
  • NO: DAC

• Do you have fixed and well defined permissions for each group of users?

  • YES: RBAC
  • NO: ABAC or DAC

V- Conclusion

In this article, We've gone through the basics of Auth, and how would one go about choosing the right Auth framework for their application. Auth is a huge topic in the security world and its concepts extend way beyond what has been mentioned in this article. Treat this article as a guide rather than a set of rules, and I encourage you to read more about these topics to further extend your knowledge. Thank you for reading thus far 😄