Skip to main content

Authentication & Authorization

Qarion employs a robust security model designed for enterprise environments, combining JWT-based authentication with a granular permission system.

Authentication (AuthN)​

JWT Strategy​

We use JSON Web Tokens (JWT) for stateless authentication.

  • Access Tokens: Short-lived, signed with a secure secret. Carries user identity (sub) and scopes.
  • Refresh Tokens: Long-lived, stored securely (HttpOnly cookies or secure storage), used to obtain new access tokens.

Identity Providers​

The system is designed to support multiple identity providers (IdP) via a plugin architecture, though the core implementation provides a default email/password mechanism and OAuth2 support.

Authorization (AuthZ)​

We implement a hybrid RBAC (Role-Based) and ABAC (Attribute-Based) model.

1. Space-Based RBAC​

Users are assigned roles within a Space (e.g., Viewer, Editor, Admin).

  • Viewer: Read-only access to datasets and checks.
  • Editor: Can modify configurations and run checks.
  • Admin: Full control over space settings and user management.

2. Organization Roles​

Higher-level roles (e.g., OrgAdmin, SuperAdmin) exist for cross-space management.

3. Policy Engine (@authorize)​

We use a declarative decorator @authorize on API endpoints to enforce permissions.

@router.post("/checks")
@authorize(permissions=["check:create"])
async def create_check(check: CheckCreate, user: User = Depends(get_current_user)):
    ...

The policy engine evaluates:

  1. User Roles: Does the user have a role with this permission?
  2. Context: Is the user acting within a Space they have access to?
  3. Attributes: (For ABAC) Does the resource belong to the user?

Security Hardening​

Standard #330-SL: Service Layer Hardening​

All security-critical services are instantiated per-request to prevent state leakage between users.

Context Isolation​

Middleware ensures that SpaceID header is validated against the user's permissions before the request reaches the business logic.