(Research) Compare different authorization systems and determine what approach is most suitable to the solution

Considers different authentication/authorization methods:

Role-Based authentication
Attribute-Based Access Control (ABAC)
Rule-Based Access Control (RBAC)
Claims-Based Identity
Policy-Based Access Control
Context-Based Access Control
Capability-Based Security
Mandatory Access Control (MAC)
Discretionary Access Control (DAC)

Questions:

Who the target audience of the application is?
ASP.NET Core Identity
Azure Active Directory (AD) as a starting point?

Authentication Models

There are four model options:

Simple, where you just use the [Authorize] attribute in the class or method.
Role-based, in which you may declare Roles for accessing the Controller you are developing.
Claims-based, where you can define values that must be received during the authentication to indicate that the user is authorized.
Policy-based, in which there is a policy established to define the access in that Controller .

There are many authentication options available nowadays, from ASP.NET Core Identity to external provider authentication methods, such as Facebook or Google. As a software architect, you must consider who the target audience of the application is. It would also be worth considering using Azure Active Directory (AD) as a starting point if you choose to go down this route.

You may find it useful to design authentication associated with Azure AD, a component for managing the Active Directory of the company you are working for.

Depending on the scenario of the solution you are building, you might need to implement MFA – Multi-Factor Authentication. The idea of this pattern is to ask for at least two forms of proof of identity before allowing the solution to be used. It is worth mentioning that Azure AD facilitates this for you.

You may also find it useful to implement authentication to your platform using as basis Microsoft Identity Platform. In this case, the usage of the Microsoft Authentication Library (MSAL) will facilitate your work hugely. Microsoft Docs

Do not forget that you must determine an authentication method for the APIs you provide. JSON Web Token is a pretty good pattern, and its usage is cross-platform.

You must determine the authorization model you will use in your web app. There are four model options:

Simple, where you just use the [Authorize] attribute in the class or method.
Role-based, in which you may declare Roles for accessing the Controller you are developing.
Claims-based, where you can define values that must be received during the authentication to indicate that the user is authorized.
Policy-based, in which there is a policy established to define the access in that Controller

You may also define a controller or method in a class as being fully accessible to any user by defining the [AllowAnonymous] attribute.

To finish, it is worth mentioning that security needs to be treated using the onion approach, which means that there are many layers of security to be implemented. You must have determined a policy to guarantee a process to access the data, including physical access for people who use the system you are developing. In addition, you also must develop a disaster recovery solution in case the system is attacked. The disaster recovery solution will depend on your cloud solution.

SSO Protocols

OAuth 2.0: Widely used for delegated authorization scenarios, such as allowing third-party applications to access user data without exposing credentials. OpenID Connect (OIDC): An identity layer built on top of OAuth 2.0, providing authentication services and identity token issuance. SAML (Security Assertion Markup Language): XML-based protocol for exchanging authentication and authorization data between IdPs and service providers (SPs).

GitHub

GitHub uses a combination of OAuth for authentication and role-based access control (RBAC) along with team-based and repository-based permissions for authorization.

GitHub uses OAuth 2.0 for authentication, allowing users to log in and grant third-party applications access to their GitHub account without sharing their password. This ensures a secure and standardized method for authentication.

GitHub employs RBAC to manage permissions for users at various levels, such as:

Organization Level: Within an organization, users can have different roles like owner, member, or billing manager, each with specific permissions.
Repository Level: Users can be assigned roles such as admin, maintainer, and collaborator, which dictate their level of access to the repository.

Common Roles and Permissions

Owner: Full administrative rights over the organization, including managing teams and settings. Member: Standard access to organization repositories and resources, but limited administrative capabilities. Billing Manager: Can manage billing and payments but has no access to code or repository settings.

Team-Based Permissions

Within organizations, teams can be created to group users and assign them collective permissions. This simplifies the management of access control by allowing permissions to be set at the team level rather than individually for each user.

Teams: Can be given specific access to repositories, and the permissions of a team cascade to its members. Team Roles: Teams can have maintainers and members, where maintainers have additional management capabilities within the team.

Resource Owner: The user who owns the GitHub account and grants access to their resources.
Client: The third-party application that requests access to the user's resources.
Authorization Server: GitHub's server that authenticates the user and issues access tokens.
Resource Server: GitHub's server that hosts the user's resources and accepts access tokens to grant access.

Scopes

Scopes define the specific access permissions granted to the application. GitHub supports various scopes, such as:

repo: Full control of private repositories. user: Access user profile data. gist: Access and manage gists. notifications: Access notifications. admin:org: Full control of organizations.

Dropbox

Dropbox primarily employs a role-based access control (RBAC) model for authorization, with additional features that can leverage claims-based attributes for more granular control.

Key Roles and Permissions in Dropbox

Admin Roles

Team Admin: Has full control over team settings, user management, and billing information. This role can manage team members, set policies, and access all team content.

User Management Admin: Can manage user accounts and their access to team resources but does not have access to billing information. Support Admin: Provides assistance to team members, manages passwords, and access, but has limited administrative control.

Member Roles

Standard Team Member: Regular access to team resources, can create and share folders, but has no administrative privileges.

Limited Member: Has restricted access, often used for external collaborators or contractors who need limited access to specific resources.

Claims-Based Attributes

While Dropbox's core authorization model is RBAC, it can also incorporate claims-based attributes for more detailed and dynamic access control:

Claims-Based Access Control: Attributes about users (such as department, role, location) can be used to grant or restrict access. This is particularly useful in larger organizations where access needs can vary based on more than just roles.

Integration with Identity Providers (IdPs): Dropbox integrates with enterprise identity providers like Okta, Azure AD, and others, which can provide claims (such as group membership, job title) that Dropbox uses to determine access levels.

Slack

Slack primarily uses a role-based access control (RBAC) model for authorization, with additional features that support granular access control through user roles and permissions.

Slack's RBAC model involves predefined roles that dictate user permissions within a workspace or organization. These roles control what actions users can perform and what resources they can access.

Key Roles and Permissions in Slack

Workspace Owners Primary Owner: Has the highest level of control over the workspace, including billing and workspace settings. Each workspace has one Primary Owner. Owners: Can perform most administrative functions, such as managing members, settings, and integrations.

Workspace Admins

Admins: Assist workspace owners by managing members, channels, and other administrative tasks. They have significant control but do not have access to billing and workspace deletion.

Members

Full Members: Regular users who can send messages, create channels, and access standard features of the workspace. Guests: Limited to specific channels. They can be either: Single-Channel Guests: Access to only one channel. Multi-Channel Guests: Access to multiple channels as specified by an admin.

Bot Users

Bots: Created by apps to perform automated tasks and interact with users. They have specific permissions based on their function and the scope defined during their creation

Claims-Based Attributes (Indirect Use)

While Slack’s core authorization is RBAC, it can indirectly leverage claims-based attributes through integrations with identity providers (IdPs) and single sign-on (SSO) solutions:

SSO and IdP Integration: Slack integrates with SSO providers like Okta, Azure AD, and others. These IdPs can pass claims (e.g., department, role, location) to Slack during the authentication process. Custom Profiles and User Groups: Admins can create custom profile fields and user groups based on attributes that help manage permissions and access more dynamically.

Model used

OAuth 2.0

Slack utilizes OAuth 2.0 for third-party app integrations, allowing external applications to access Slack's API on behalf of a user. This includes the following components:

Authorization Code Grant: This flow is used by apps to exchange an authorization code for an access token. Scopes: OAuth tokens are granted specific scopes that define the level of access an app has to a user's Slack data.

Single Sign-On (SSO)

Slack supports Single Sign-On (SSO) to allow users to authenticate using their organization’s existing identity provider (IdP). SSO mechanisms supported include:

SAML 2.0: Security Assertion Markup Language (SAML) is commonly used for enterprise-level SSO. OpenID Connect: An identity layer on top of OAuth 2.0, often used for both enterprise and consumer authentication.

Slack's Native Authentication

For users who do not use SSO, Slack provides its own authentication system, which includes:

Email and Password: Standard authentication using a unique email and password combination. Two-Factor Authentication (2FA): Enhances security by requiring a second form of verification, such as a code sent to a user's phone or an authentication app.

Token-Based Authentication

Slack uses token-based authentication for API requests, including:

User Tokens: Represent the authenticated user and their permissions.
Bot Tokens: Used by bots to perform actions on behalf of users within a workspace.
App Tokens: Used for inter-app communication and managing app configurations.

Session Management

Slack manages user sessions to ensure secure access, involving:

Session Tokens: Generated upon user login and maintained for the duration of the session.
Session Timeouts: Sessions are automatically timed out after a period of inactivity to prevent unauthorized access.

Granular Permissions

Slack's authorization model includes fine-grained permissions to control access at multiple levels:

User Roles: Different roles (e.g., Admin, Member, Guest) with varying levels of access and capabilities.
Channel Permissions: Access controls at the channel level to restrict who can view or post in specific channels.
App Permissions: Apps are granted specific permissions based on the OAuth scopes requested and approved by users.

Functional Requirements

An authenticated user can create a record. The user owns the record.
Only owner (and chosen by the user) may update the record.
The record may be private: only owner can view it, or public: evebody can view.
The owner can grant view, edit access to other users. Only owner may change access permissions to the record or delete the record.
The owner may transfer ownership right to other users.

Non-Functional Requirements

High security is critical for protected data. Security is not essential for public data. Core services are consumer-oriented (as opposed to business). Ease of use and convenience have a higher priority for public data.

Conslusion

Username and Password Authentication is acceptable if password-related security risks (e.g., brute force attacks, password reuse) are addressed.
OAuth 2.0 / OpenID Connect is preferred due to microservices architecture, scalability and performance being essential. Token-related risks should be addressed.
Multi-factor authentication (MFA) is preferred for some security-critical tasks. Such as private data access.
Single Sign-On (SSO) should be used due to distributed architecture.
SAML is NOT the desired authentication method due to the complexity, XML processing overhead, and maintenance effort.

Stories

As a User I can Create a resource, I become Owner of that resource. The resource could be Private or Public. Private resources visible only to me. Public resources visible to everyone.
As an Owner of the resource I can share View, Edit, or Delete permissions of the resource to other users. Only me and those who I choose can Edit, or Delete the resource.
As a User, I may suggest changes to the resource, If I have view access to the resource and the Owner allows Suggestion permission for the resource.
As a User, If I have View permission to a resource, I may have Edit, Delete, Suggest permissions. If I have Suggest permission to a resource, I Do have View permission, I may have Edit, Delete permissions. If I have Edit permission to a resource, I Do have View and Suggest permission. I may have Delete permissions. If I have Delete permission to a resource, I Do have View, Suggest, and Edit permissions.

Instagram

Instagram primarily uses Role-Based Access Control (RBAC) for managing user permissions and access within its platform. Additionally, Instagram employs Claims-Based Identity and Attribute-Based Access Control (ABAC) for certain aspects of its authentication and authorization processes.

Role-Based Access Control (RBAC)

RBAC Instagram users are typically assigned roles like regular users, content creators, advertisers, and administrators. Each role comes with specific permissions. For example, regular users can post content and follow other users, while administrators have additional capabilities to manage accounts and content.

Claims-Based Identity

OAuth 2.0 and OpenID Connect When users log in via third-party applications or social login (e.g., Facebook), claims are used to authenticate users and determine their permissions. Claims can include user profile information, roles, and other attributes provided by the identity provider.

Attribute-Based Access Control (ABAC)

Content Moderation and Access Control: Instagram might use ABAC for more granular access control, such as determining who can view certain types of content based on user attributes (e.g., age, location) and contextual information (e.g., time of day).

Discord

Discord utilizes a combination of OAuth 2.0 for authentication and Role-Based Access Control (RBAC) for authorization within its platform. These models ensure secure access and permission management for its diverse user base, including regular users, server administrators, and bots.

Authentication Model: OAuth 2.0

OAuth 2.0 is the primary authentication model used by Discord, particularly for third-party integrations and API access.

Authorization Model: Role-Based Access Control (RBAC)

Discord uses Role-Based Access Control (RBAC) for managing permissions within servers.

Role Assignment:

Users are assigned roles by server administrators or other users with the necessary permissions. A user can have multiple roles, and their effective permissions are the union of all permissions granted by their roles.

Hierarchy and Inheritance:

Roles can be hierarchical, with higher roles having the ability to override permissions of lower roles. Permissions can be inherited based on the role hierarchy, simplifying the management of complex permission sets.

LinkedIn utilizes a combination of OAuth 2.0 for authentication and Role-Based Access Control (RBAC) for authorization within its platform. These models ensure secure access, user convenience, and efficient permission management.

Authentication Model: OAuth 2.0

OAuth 2.0 is the primary authentication model used by LinkedIn, especially for third-party integrations and API access.

Authorization Model: Role-Based Access Control (RBAC)

LinkedIn uses Role-Based Access Control (RBAC) to manage permissions within its platform.

How RBAC Works in LinkedIn:

Roles and Permissions:

Roles define a set of permissions that determine what actions users can perform. For example, regular users can update their profiles and connect with others, while company administrators may have additional permissions to manage company pages and analytics.

Facebook

Authentication: OAuth 2.0 for third-party applications. Authorization: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Privacy Settings: Users can set privacy for posts, friends, and other content (public, friends, only me, custom lists).

Twitter

Authentication: OAuth 2.0 for API access. Authorization: Role-Based Access Control (RBAC) for managing access to tweets and accounts. Privacy Settings: Users can make their tweets public or protected (only approved followers can see protected tweets).

LinkedIn

Authentication: OAuth 2.0 for third-party integrations. Authorization: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) based on user roles and content types. Privacy Settings: Users control the visibility of their profile, posts, and activities.

YouTube

Authentication: OAuth 2.0 for API access. Authorization: Role-Based Access Control (RBAC) for managing videos and channel permissions. Privacy Settings: Videos can be set to public, unlisted (accessible via link), or private (restricted to specific users).

Pinterest

Authentication: OAuth 2.0 for third-party integrations. Authorization: Role-Based Access Control (RBAC) for managing boards and pins. Privacy Settings: Boards can be public or secret (only invited collaborators can see secret boards).

GitHub

Authentication: OAuth 2.0 for API access and third-party applications. Authorization: Role-Based Access Control (RBAC) for repository access and actions. Privacy Settings: Repositories can be public or private (access restricted to collaborators).

Slack

Authentication: OAuth 2.0 for API access and integrations. Authorization: Role-Based Access Control (RBAC) for managing channel access and user roles within a workspace. Privacy Settings: Channels can be public, private, or shared across workspaces.

Google Drive

Authentication: OAuth 2.0 for API access and third-party applications. Authorization: Role-Based Access Control (RBAC) for file and folder permissions. Privacy Settings: Files and folders can be shared publicly, with specific people, or kept private.

Dropbox

Authentication: OAuth 2.0 for API access and integrations. Authorization: Role-Based Access Control (RBAC) for managing file access and sharing permissions. Privacy Settings: Files and folders can be shared publicly or with specific users.

Flickr

Authentication: OAuth 2.0 for API access and integrations. Authorization: Role-Based Access Control (RBAC) for managing photo and album permissions. Privacy Settings: Photos can be set to public, private, or viewable by friends and family.

Vimeo

Authentication: OAuth 2.0 for API access and third-party applications. Authorization: Role-Based Access Control (RBAC) for managing video access and permissions. Privacy Settings: Videos can be public, private, or viewable only by specific users or via password protection.

andrii-itdev / InsightFlow