A Guide to Authentication and Authorization

You have used systems like these, in case you have ever used an app. However, you as a developer must peep beneath the hood. We can identify these two concepts with the help of a simple analogy: The Hotel.

1. Authentication (AuthN) - Who is you?

The procedure of establishing the identity of a user is known as authentication. When entering a hotel you present your passport or ID at the front desk in order to confirm that you are who you say you are at the front desk. In software we accomplish this with,

• Something that you are familiar with - Passwords or PINs
• Something you have - either a tangible object, such as a smartphone (to send SMSs) or an authenticator application.
• One of those - Biometrics such as fingerprints or facial recognition.

The New Standard It is time to abandon our simple passwords in favor of Multi-Factor Authentication (MFA) and Passwordless. When developing, passwords should hardly ever be handled by you. You instead rely on identity providers (IDPs) such as Google, GitHub or dedicated services such as Auth0.

2. Authorization (AuthZ) - What is allowed?

Upon establishing who you are, a key card is issued to you by the hotel desk. This card does not grant you entry to the whole hotel, it just opens your room and maybe the gym. This is Authorization.

Authorization in software is used to determine the permissions of an authenticated user.

• RBAC (Role-Based Access Control) - Roles are given to users (e.g., Admin, Editor, Viewer). The "Admin" is able to delete the posts, whereas the "Viewer" is able to read them only.
• ABAC (Attribute-Based Access Control) - More complicated. The access is granted on the basis of such attributes as Is it during office hours? or "In a particular location does the user reside?

3. The Modern Tech Stack - OAuth2 and OIDC

Within the context of current web and mobile development, the development of a secure application has taken a new form other than the mere username and password form. The modern industry best practice is based on the mighty integration of OAuth2 and OpenID Connect (OIDC). Although they are used interchangeably, they have two different though complementary functions and they are authorization and authentication.

OAuth2 serves as the base, which is meant to be used to process authorization. OAuth2 does not force a user to provide his master password to a third-party application but employs a system of limited-access Tokens. To use the example of a new application requesting permission to “Access your Google Contacts“, OAuth2 handles that handover in the background. Your login details do not get sent to the app, but rather it is given a token with limited and restricted permissions to carry out some form of action on your behalf.

OpenID Connect is a thin identity layer, yet it is built directly on that framework, and it manages the authentication aspect of the puzzle. Whereas OAuth2 is concerned with the things the app is permitted to do, OIDC is concerned with the identity of the user. It provides an "ID Token" which includes verifiable profile information, including your name and email address. The combination of these protocols allows Single Sign-On (SSO) experiences that we all use daily, with users being able to safely authenticate to dozens of diverse services with a single, trusted account.

Best Practices to Developers

1. Always keep the passwords in a strong hashing algorithm such as Argon2 or bcrypt - never keep them as plaintext.
2. Principle of Least Privilege - Do not grant a user more privileges than they have to use in order to accomplish their task.
3. Do not overuse JWTs (JSON Web Tokens) - they are excellent with stateless authorization, but you must be sure that they are properly signed and they have a limited expiration period.
4. Fail Gracefully - In case an authentication system malfunctions, the system should malfunction and fail to grant access, but not allow access.

Conclusion

The basis of software trust is identity. This separation of who is and what can be done by a user makes each user a much more secure system and also it is much easier to scale out as your project grows beyond a single user to a million.