Authorization
We will be creating a Authorization system based on Account Types, User Types, User Roles and Capabilities. More information is outlined below:
Authorization System Documentation
Overview
This document outlines the authorization system for the application, detailing the structure and usage of account types, user types, user roles, and capabilities. This system ensures that actions such as creating users, managing user types, and other sensitive operations are restricted to authorized users only.
Base URL
Core Concepts
Account Types
Description: Account types define the high-level categories of users within the system. There are three account types: Admin, Candidate, and Employer/Company.
User Types
Description: User types are tags that signify the department or job function of a user within the system, like Founder, Marketer, Sales, Recruiter, etc.
User Roles
Description: User roles represent the permission level a user has within the system. Predefined roles are Owner, Editor, and Viewer. A role of 'Customized' is assigned when an Owner modifies the default set of capabilities for a user.
Capabilities
Description: Capabilities are specific actions a user is permitted to perform within the application, such as creating or removing users and user types.
Endpoints
List Capabilities
Endpoint: GET /capabilities
Description: Retrieves a list of all capabilities available in the system.
Response:
Assign Capability to Role
Endpoint: POST /user-roles/{roleId}/capabilities
Description: Assigns a new capability to a user role.
Payload:
Response: A successful operation will return the updated user role with the new list of capabilities.
Create User Type
Endpoint: POST /user-types
Description: Creates a new user type.
Payload:
Response: The created user type object.
User Authorization Check
Endpoint: POST /check
Description: Checks if a user has the capability to perform a certain action.
Payload:
Response: A boolean result indicating if the action is authorized.
Security and Authentication
All requests to the authorization API must include a valid authentication token. The token should be passed as an HTTP Authorization header.
Example:
Error Handling
The API will return standard HTTP status codes to indicate the success or failure of a request. For example:
200 OK
- The request was successful.400 Bad Request
- The request could not be understood or was missing required parameters.403 Forbidden
- The user does not have necessary permissions for the action.404 Not Found
- The requested resource was not found.500 Internal Server Error
- There was an error on the server and the request could not be completed.
Best Practices
Always validate the user’s permissions at the server-side before performing any action.
Use secure, HTTPS connections to protect sensitive data in transit.
Regularly audit and review your roles and capabilities to ensure they align with your security policies.
Conclusion
This document provides a blueprint for the authorization structure within the application. Proper implementation and adherence to the guidelines set forth in this document will ensure a robust and secure authorization mechanism. As final example I will add a swagger example API as a starting point to go off of:
Last updated
Was this helpful?