Authentication and Authorization

Authentication and authorization are the two most important concepts for designing a secure application. To set up a solid knowledge foundation, let's first clarify what they mean respectively in the context of ZenStack.

Authentication

Authentication is the process of verifying the identity of a user. It can be a simple email and password verification or an OAuth workflow that interacts with a third-party identity provider.

ZenStack is not an authentication solution, but it usually depends on one to work. In a real-world application, access control rules usually need to leverage the information of the requesting user. An authentication solution provides the user information.

ZenStack is agnostic to the authentication solution you use. The authentication system only needs to be able to provide an object that represents the current user. ZenStack uses it to create a user-scoped enhanced Prisma Client that enforces access policies.

We'll cover this topic in more detail in the next chapter.

Popular Authentication Solutions

Here are some popular authentication solutions in the Javascript/Typescript ecosystem:

• Auth.js (formerly NextAuth)
• Clerk
• Supabase Auth
• Auth0
• Firebase Authentication
• Lucia

You can find how to integrate some of these solutions in the Integration With Authentication guides.

Authorization

Authorization is the process of determining whether a user has permission to perform a specific action. ZenStack's core part is an authorization solution that directly couples with the database. It controls what CRUD actions a user can perform on a table or a field.

Some commonly used patterns for modeling authorization are listed below (with increasing flexibility and complexity):

1. Access Control List (ACL)

   Users are directly assigned with permissions. For example, a user can be given read permission on the Post table.

2. Role-Based Access Control (RBAC)

   Users are assigned roles, and roles are configured with permissions. For example, a user can be assigned an admin role, which is granted with full permission on the Post table.

3. Attribute-Based Access Control (ABAC)

   Permissions are defined over attributes of the user and the resource. For example, a user can be assigned with 'read' permission to a Post row if the Post is published and the user is a subscribed member.

4. Relation-Based Access Control (ReBAC)

   Permissions are defined by the presence of relationships between the subjects and resources. For example, a user can edit a Post if the user has an "edit" relationship with the Post.

A complex application often needs to use a combination of these patterns. ZenStack's access policy system is designed to be easy to use yet have excellent flexibility to tackle these challenges.